Чем заменить PHP

Perl? Python?

P.S. Ruby On Rails - не язык

JSP - тоже.

uncommonweb

Лучше бери в сторону JSP - за одно Jav'у выучиш.

Прямой аналог РНР - Python/Ruby/Perl.

HAppS, HSP, WSH

>А что лучше?

для кого? вообще лучше выучить все (или многое), а потом решать.

Тот кто говорит что php ужасен - знает его на уровне школьника старших классов. Perl , Ruby , Python - те же грабли, только ручка немного по-другому приделана. Скриптовые языки хороши для фриланса, ктогда работаешь один или вдвоем. Но когда девелоперов набирается хотябы с десяток тут уж тока жава или дотнет. скрипты нервно курят в сторонке.

> Но когда девелоперов набирается хотябы с десяток тут уж тока жава или дотнет. скрипты нервно курят в сторонке.

ты видимо тоже не дотянул, вминяемые люди используют Си (%

>ты видимо тоже не дотянул, вминяемые люди используют Си (%

ты либо аргументы приводи, либо молчи. А то детский лепет какой-то ей-богу. Каджый вмеру своих возможностей хвалит то что получилось выучить.

> ты либо аргументы приводи, либо молчи. А то детский лепет какой-то ей-богу. Каджый вмеру своих возможностей хвалит то что получилось выучить.

аргументы ?) т.е. ты хочешь сказать, что бооольшое веб приложение на Java/точконете будет показывать лучшую производительность, нежели Си. Если нужно _быстро_ разработать что-то, то ессесно Java/точконет подайдет, если нужно что-то, что бы выдерживало нагрузки уровня какого-нить вконтакта без увеличения производительности за счет ресурсов машин, то ессесно тут они тихо покуривают и вообще не дергаются (%

> Каджый вмеру своих возможностей хвалит то что получилось выучить.

т.е. мне нужно тут нахваливать брейнфак как лучшее средство реализации идей в виде веб приложений ?)

Для функциональщины мозги ломать надо, к ней не привыкшие. И не говори, что лисп не функциональщина, ибо таки в ту сторону сильно перетягивает.

> Тот кто говорит что php ужасен - знает его на уровне школьника старших классов.

Тот, кто говорит, что php не ужасен - знает его на уровне школьника младших классов.

> т.е. ты хочешь сказать, что бооольшое веб приложение на Java/точконете будет показывать лучшую производительность, нежели Си.

Интересно, где это сказано выше? Я не нашёл. Но это правда, так как приложение на C просто никогда не будет разработано, а потому его производительность будет равна примерно нулю.

Так что уж Си.. на ассемблере пишите...Может вы квартиру еще зубной щеткой убирате, в то врмя когда можно пылесос заюзать. Не в ту сторону думаете, господа. Основной затык в веб-приложении которое работает под большой нагрузкой - это база данных. Разбежка нагрузок между апп сервером и бд может достигать нескольких порядков. Оптимизируйте запросы и будет вам счастье :)) Кстати тот же вконтакте кажысь на PHP написан.%)) Я очень уважаю Си, но кричать что это на нем круто писать веб приложения со сложной бизнес-логикой - это полный бред. jit компиляторы нонче знаенте какие шустрые пошли ? сплошная крутизна и оптимизация. Проигрывают нативным приложениям в среднем процентов на 10. Так тут уж лучше чуточку железа доставить, чем потратить лишних пару лет на разработку.

> Тот, кто говорит, что php не ужасен - знает его на уровне школьника младших классов.

Тогда это самый лучший язык! :)) Я знаю его на уровне школьника младших классов, и могу писать весьма грамотные прилаги, тратя не больше пары часов вечером имея при этом очень неплохой дополнительный доход :))

> Я знаю его на уровне школьника младших классов

Это мы поняли.

> и могу писать весьма грамотные прилаги

Нет, не можешь. Грамотные - не можешь.

> имея при этом очень неплохой дополнительный доход

А, эту фразу я знаю. Её часто произносят рабы из МакДональдса.

> тратя не больше пары часов вечером имея при этом очень неплохой дополнительный доход :))

это $100 в месяц?

> Не в ту сторону думаете, господа. Основной затык в веб-приложении которое работает под большой нагрузкой - это база данных.

это отдельный разговор, да и проблема работы с БД решается за счет снижения запросов к ней и оптимизацией запросов ...

> Так тут уж лучше чуточку железа доставить, чем потратить лишних пару лет на разработку.

человек, не знающий Си и ниразу не разрабатывавший с помощью него приложения, естественно будет так думать, на самом деле при нормальном опыте, затраты по времени на разработку приблизительно равны, и Java, и точконету ...

> Кстати тот же вконтакте кажысь на PHP написан.

вроде да, и одноглазники на Java, только вот чет они падаааают, а на одноглазниках там так вообще хз как они новые функции запускают )

> это $100 в месяц?

Ну почти так. только ты нолик пропустил...

>> и могу писать весьма грамотные прилаги

>Нет, не можешь. Грамотные - не можешь.

Ты же их не видел, а пытаешься что-то доказать. И как с тобой вести разговор ?

На ЛОРе все пытаются что-то доказать, не обращай внимания.

> Ну почти так. только ты нолик пропустил...

$10.00?

В данной заметке излагаю исключительно свой опыт и наблюдения.

Все разработки ведутся в основном на PHP, причина этому довольно простая - учить его не надо, знающих PHP сверх достаточно, даже сложные вещи делаются быстро. А для избежания проблем - есть разработанный компанией внутренний "Свод законов писания на PHP" + "Набор общего функционала", зачем изобретать велосипед если для одного проекта он уже изобретен. Все лежит в SVN.

Проблемы ужаса PHP - они есть они будут, ну и фиг с ними. При работе на время для нас главным есть скорость, а не академические вершины программирования. Классы - только базовый функционал.

Так вот PHP предоставляет простоту легкость и скорость.

Чего бы хотелось?

Очень хочется Python! По сравнению с PHP, но при условии грамотного писания, он немного быстрее, а самый большой плюс это более эффективное использование памяти. Python использует меньше памяти и производит меньше операций выделения памяти чего не скажешь о PHP, а Ruby в этом плане совсем отдыхает.

Python это конечно хорошо но намного дороже.

Присоединяюсь к neurons ! Он прав сто раз на счет узкого места - база данных. Для того чтобы увидеть это достаточно заюзать профилировщик, и громадную часть времени выполнения скрипта будет занимать обращения к базе. Так, что и следует оптимизировать, дык это механизм работы с БД и саму БД.

А за Си могу сказать что люди пишут и очень успешно пример этому OnDemand ВЕБ бизнес приложения с ядром написанным на Си.

По поводу "стоит ли все того чтобы так заморочивать себе мозги, проще взять и докупить мозгов или сервак помощнее поставить" могу сказать что стоит и докупить мозги это не копейки, 32гига это очень дорого, а сервер поставить новый это на порядок дороже мозгов.

Мое заключение для меня самого простое - надо писать на том что знаешь лучше всего или выучить очень легко, что позволяет написать быстро, а значит и дешево, не тратит много памяти, имеет средства профилирования и дебугинга.

Нравится Python но приходится пользоваться PHP.

Удивлён, что никто не дал единственно правильного ответа. PHP - это глобально и надёжно, не надо его ни на что менять. %)

Опыт показывает, что проблемы производительности большинства сайтов дешевле всего решаются следующими способами:
1. Кеширование.
2. Оптимизация БД, запросов.
3. Увеличение вычислительных ресурсов.

При грамотной реализации языком может быть даже ruby. Поэтому язык стоит выбирать исходя из таких факторов:
* Наличие и цена разработчиков с опытом работы на этом языке (в компании или на рынке труда).
* Наличие и цена хороших инструментов, увеличивающих производительность разработчиков.
* Использование известных, апробированных технологий для снижения рисков.

Могут быть редкие случаи, при которых производительность кода на C выше производительности кода, например, на Java, и оптимизация этого участка кода позволит значительно повысить суммарную производительность серверной части. В этом случае правильнее всего реализовать критический участок на C и вызывать его из основного приложения с помощью механизма IPC или с помощью механизма интероперабельности.

1000USD? Ну, для школьника, да в порядке подработки неплохо. Я, подрабатывая на хаскеле, получаю примерно 2500.

> Ты же их не видел, а пытаешься что-то доказать.

А мне не надо. На самом деле, достаточно уже того, что ты употребил слово "прилаги". Приложения или программы могут быть грамотными (хотя и не на похапэ), но прилаги - не могут.

> Опыт показывает, что проблемы производительности большинства сайтов дешевле всего решаются следующими способами:

> 1. Кеширование.

никто не спорит ... кэши самой СУБД + какой-нить memcached сильно снизит нагрузку, файловый кэш конечно не супер, очень сильно ограничевает, столкнулся с этим и приходится городить грабли, что ппц просто )))

> 2. Оптимизация БД, запросов.

ну это понятно и не обсуждается )))

> 3. Увеличение вычислительных ресурсов.

ну не всегда, скажем был движек N ресурса, для I ресурса пришлось его переписать немного, потом еще там доделать пару мелочей ... протестил apache benchmark на одном и том же локалхосте, в два раза увеличилась производительность I, сейчас для N переписываю заново плюс там сделал рамочки, которые мне нравяться ))) посмотрим, сравню со старыми результатами, т.к. ничего не обновлял )

насчет Java не могу ничего возразить, т.к. не писал на ней, тут ели людей раскачал, что бы переписать все на Python (%

>файловый кэш конечно не супер, очень сильно ограничевает, столкнулся с этим и приходится городить грабли, что ппц просто )))

Я тут, снижая нагрузку на SQL, перевёл было у себя кеш на FS. Мало того, что как только объём кеша приблизился к нескольким сотням тысяч записей (естественно, не в одном каталоге всё лежало, а по сотне-другой файлов в каталоге), начало сильно тормозить (машина в почти постоянном io-wait), так ещё пришлось запускать непрерывный круглосуточный процесс по чистке этого кеша. Чистка по mtime (стояло в будущее, expired, т.е. тупо стирались find+rm'ом все файлы, что mtime < now), хранение на отдельном разделе, SCSI - ничего не помогло...

В итоге кеш опять вернулся в mysql-базу :) Только индексы сменил со строковых (md5 от ключей) на численные (младшие байты того же md5).

гыгы, а у нас где-то на НГ на 3D News никто не чистил кэш и в итоге сервер просто упал из-за слишком большого объема, место кончилось на дисках )