Посоветуйте ЯП для написания сайтов

[Devider]

[Стоит обратить внимание на C++. Я так понимаю, что нужен не язык для быстрого решения какой-то задачи, а язык для секса. Со связкой C++/web - будет отменный и запоминающийся секс, без быдлокода.

И тут тоже секса нет. )
http://code.google.com/p/madfish-webtoolkit/

Сами сайты на Perl не знаю, а вот мощные frameworks для веб приложений есть. Хотя Django и GWT тоже для веб приложений.

А какой смысл во фреймворках если ими никто не пользуется?..

[eddy]

А какой смысл во фреймворках если ими никто не пользуется?..

Ну не скажите. Есть люди, которые фреймворками пользуются (хотя, честно говоря, я таких не знаю)...

[Crazy]

А какой смысл во фреймворках если ими никто не пользуется?..

На них удобно делать web-приложение. С тем же gwt можно не думать о html и javascript.

[serzh-z]

А какой смысл во фреймворках если ими никто не пользуется?..

"Никто"?

[KiWi]

Инструмент должен выбираться правильно изначально, тогда никуда не упретесь. Я имел ввиду что домашнюю страничку соседу Васе можно набросать впринципе на чем угодно и особых проблем с производительностью на такого уровня проектах не бывает.

Упретесь куда?
Вы в любом случае не будете хранить 100TB в одном месте. Также, как и не будете хранить базу в 500GB в одном месте.
А имея масштабируемую систему -- будет уже всё равно какой ЯП.

ИМХО
Когда выбирал ЯП чтобы подтянуть знания в данном направление выбрал Python. По причинам:
1) Ruby показался мало распространенным, меньше информационных ресурсов чем у конкурентов, меньше готовых решений и библиотек.

Для веб-приложений у Ruby есть рельсы, которые заруливают больше, чем django и всевозможные phpные "cms".

По моим наблюдениям там где php уже упирается в быстродействие, лучше уже на C чем на джаве.

Там где что-то начинает упираться в приложение -- надо заниматься разделением функций на части(и, как следствие, на разные серверы).
Это будет гораздо легче, чем переписывать приложение.

А какой смысл во фреймворках если ими никто не пользуется?..

Django.

[KiWi]

[Стоит обратить внимание на C++. Я так понимаю, что нужен не язык для быстрого решения какой-то задачи, а язык для секса. Со связкой C++/web - будет отменный и запоминающийся секс, без быдлокода.

И тут тоже секса нет. )
http://code.google.com/p/madfish-webtoolkit/

Сами сайты на Perl не знаю, а вот мощные frameworks для веб приложений есть. Хотя Django и GWT тоже для веб приложений.

А какой смысл во фреймворках если ими никто не пользуется?..

Секс в С/С++(через fastcgi, естественно) есть по определению -- организовать утечку памяти легче всего.

[KiWi]

Код PHP 4 достаточно хорошо работает в PHP 5.

Вы пропустили "не" перед "работает".
У меня был опыт перевода одного проекта с 4 на 5. Мучались мы тогда больше недели, пока все более менее заработало.

Смена мажорной версии в любом случае предполагает какую-то несовместимость.
Более того, PHP4 поддерживался достаточно долго после выхода PHP5, чтобы все заинтересованные лица могли спокойно смигрировать приложения. Если в это время кто-то щелкал клювом, то ССЗБ.

[Devider]

А какой смысл во фреймворках если ими никто не пользуется?..

"Никто"?

Не так понял.

Сами сайты на Perl не знаю, а вот мощные frameworks для веб приложений есть. Хотя Django и GWT тоже для веб приложений.

воспринял как "сайтов на перле не знаю, а фреймворки на нем есть."

Для веб-приложений у Ruby есть рельсы, которые заруливают больше, чем django и всевозможные phpные "cms".

А чем рельсы так рулят?

[diesel]

Для веб-приложений у Ruby есть рельсы, которые заруливают больше, чем django и всевозможные phpные "cms".

А чем рельсы так рулят?

на рельсах, на самом деле, в принципе достаточно просто писать. Для каких-то не очень сложных вещей, есть такое ощущение что даже знаний руби, как языка, особых не требуется(правда, тут недавно слышал утверждение что для генерации кода на php, знания php тоже не обязательны). правда, в том месте, где заканчивается разработка, и начинается введение в експлуатацию, с рельсами как-то мрачновато становится.

[watashiwa_daredeska]

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

Ну, не только. Для PHP много шума, т.е. кучи дерьма, среди которых нужно долго искать жемчужину. Можно и не искать, но жемчужину из дерьма сделать не получится, только очередную кучу дерьма. В Python с этим как-то попроще, мне кажется. Хотя, опыт в Python у меня несравнимо больше, чем в PHP, да и давно этот PHP был, поэтому могу, конечно, ошибаться, но что-то мне подсказывает, что не зря /dev/random кроет IPB на чём свет стоит, который ещё и за деньги продаётся :)

5) Читал, что в ООП в PHP реализовано довольно криво, Python вроде таким не славится

В Python тоже криво. В Python 3, вроде, обещали подчистить, но я еще не глядел.

[watashiwa_daredeska]

А имея масштабируемую систему -- будет уже всё равно какой ЯП.

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

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

[Crazy]

А какой смысл во фреймворках если ими никто не пользуется?..

"Никто"?

Не так понял.

Сами сайты на Perl не знаю, а вот мощные frameworks для веб приложений есть. Хотя Django и GWT тоже для веб приложений.

воспринял как "сайтов на перле не знаю, а фреймворки на нем есть."

Для веб-приложений у Ruby есть рельсы, которые заруливают больше, чем django и всевозможные phpные "cms".

А чем рельсы так рулят?

Вот и сайты http://www.twl.ru/portfolio

[KiWi]

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

Ну, не только. Для PHP много шума, т.е. кучи дерьма, среди которых нужно долго искать жемчужину. Можно и не искать, но жемчужину из дерьма сделать не получится, только очередную кучу дерьма. В Python с этим как-то попроще, мне кажется. Хотя, опыт в Python у меня несравнимо больше, чем в PHP, да и давно этот PHP был, поэтому могу, конечно, ошибаться, но что-то мне подсказывает, что не зря /dev/random кроет IPB на чём свет стоит, который ещё и за деньги продаётся

IPB -- УГ. ibresource.ru -- идиоты. Это по опыту 2годичного общения и с тем, и с другим.

А так -- да, в PHP ужасно много быдлокода, который тянут из версии в версию, когда нужно его давно переписать(у phpbb, например, есть функции перевода IP в int и обратно).

[KiWi]

А имея масштабируемую систему -- будет уже всё равно какой ЯП.

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

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

С этим никто не спорит.

А по поводу масштабируемости -- всё зависит от того, что принято в компании. У нас изначально существуют провязки между сервисами(банально -- авторизация). А в связке frontend(xscript)+backend(через CORBA) минимально(проект стал популярным и внезапно появилась большая нагрузка, а переписать моментально невозможно) масштабировать легче -- нужно всего лишь добавить машин в SLB.

[serzh-z]

Можно и не искать, но жемчужину из дерьма сделать не получится, только очередную кучу дерьма. В Python с этим как-то попроще, мне кажется.

Это неконструктивная критика. Аргументы, плз. Кроме поднадоевших наездов на медлительность (то же самое говорили лет 10 назад про Perl).

В Python тоже криво.

Что значит "некривой ООП"? Это "ООП, как в моём любимом языке Х"?

[fergios]

php,
т.к. язык развивается,
мощности серверов растут,
если и дойдешь до максимальной нагрузки сервера, то сделаешь масшабируемую систему (несколько серверов).

[DaemonTux]

php,
т.к. язык развивается,
мощности серверов растут,
если и дойдешь до максимальной нагрузки сервера, то сделаешь масшабируемую систему (несколько серверов).

Если судить по вашим вопросам на форуме, то ваш совет смотрится не кошерно.

[Crazy]

если и дойдешь до максимальной нагрузки сервера, то сделаешь масшабируемую систему (несколько серверов).

С FastCGI и memchached можно из разных ЯП использовать.

[watashiwa_daredeska]

Это неконструктивная критика. Аргументы, плз. Кроме поднадоевших наездов на медлительность

Причем тут медлительность? Я говорю о существующей code base. В Python, если мне что надо, я довольно быстро нахожу библиотеку/скрипт, которые написаны достаточно хорошо, чтобы их можно было читать, понимать (не целиком, а кусками, где нужно), исправлять, дополнять и использовать. А для PHP я в своё время одно говно находил. Кажется, что всего много, тех же форумов, а как ни копнёшь -- одно говно, которое страшно в production пускать, ибо вскройся какой глюк -- будешь месяц волосы на заднице рвать и половину кода переписывать, чтобы исправить, при этом ещё сотню глюков родишь, ибо всё криво, косо и где-то не срослось. Вот об этом я и говорю: ИМХО (т.е. субъективно) объем качественной кодовой базы для Python больше, чем для PHP.

Что значит "некривой ООП"?

Некривой -- это консистентый и без костылей. В Python одно деление на old-style и new-style классы чего стоит, полный ахтунг. О числовом выражении степени кривости судить не берусь :)

[watashiwa_daredeska]

в связке frontend(xscript)+backend(через CORBA) минимально(проект стал популярным и внезапно появилась большая нагрузка, а переписать моментально невозможно) масштабировать легче -- нужно всего лишь добавить машин в SLB.

Ну, мне сложно судить о вашей архитектуре. У нас так: есть "супер frontend" -- для всех. У каждого "продукта" есть frontend -- отдельный сервис, количество запущенных экземпляров может увеличивться, super-frontend ходит к нему через load-balancer. Есть куча всяких backend'ов, которые выполняют разные задачи, которые нужны frontend'у, каждый backend -- такой же сервис, как и frontend, который может запускаться в нескольких экземплярах, и к которому все ходят через load-balancer.

Так вот, разбить целое на эти самые backend'ы (unix-style: каждый делает одно, но хорошо), каждый написать в расчете на масштабируемость и т.д. -- это в корне меняет архитектуру и увеличивает объем работы на начальном этапе. На этапе "startup" можно без этого обойтись, чтобы быть оперативнее в плане удовлетворения потребностей пользователей. Когда 80% удовлетворены, можно считать прототип готовым и приступать к написанию релизной версии с масштабированием, потом реклама, привлечение пользователей и т.д. А у прототипа как-нить ограничить приток пользователей -- инвайтами или еще как.

[sash-kan]

Посоветуйте ЯП для написания сайтов

btw

[KiWi]

Так вот, разбить целое на эти самые backend'ы (unix-style: каждый делает одно, но хорошо), каждый написать в расчете на масштабируемость и т.д. -- это в корне меняет архитектуру и увеличивает объем работы на начальном этапе. На этапе "startup" можно без этого обойтись, чтобы быть оперативнее в плане удовлетворения потребностей пользователей. Когда 80% удовлетворены, можно считать прототип готовым и приступать к написанию релизной версии с масштабированием, потом реклама, привлечение пользователей и т.д. А у прототипа как-нить ограничить приток пользователей -- инвайтами или еще как.

Опять-таки -- всё зависит от компании.

У нас frontend -- это вёрстка, которая собирает страницу с разных backend'ов(как своего сервиса, так и соседей). Перед ними, естественно, свои SLB.

Соответственно, проверка -- авторизован ли пользователь -- это уже необходимость сходить в backend паспорта.

[Devider]

Посоветуйте ЯП для написания сайтов

btw

Занятно, спасибо.