Не начинать на PHP? А на чем тогда?

scheme.

а если серьезно, то mod_perl+mason - самое то

на петоне, по количеству быдлокодеров он скоро обгонит пхп :)
или на перле, кодеришек под нево тоже полно.

На жабе ты задолбаешся писать: там даже нормальных регулярных выражений нет, python, ruby - это все фуфло. .NET - это бабло требуется. PHP, Perl - наше все. Насчет "секурности": если будешь придерживаться элементарных правил - все там будет секурно ....

mod_perl, mod_php для повышения производительности ... Mason - мне он не нравится проще какой нить движок шаблонный простейший взять.

> Призыв встретил живой отклик в сердцах учасников флейма.

Ну дык тож ЛОР! Тут любой призыв втоптать что-нить в дерьмо всегда находит живой отклик в наших сердцах ;)

На жабе ты задолбаешся писать: там даже нормальных регулярных выражений нет, PHP, Perl- это все фуфло. .NET - это бабло требуется. python, ruby - наше все. Насчет "секурности": если будешь придерживаться элементарных правил - все там будет секурно, в отличии от PHP.

http://www.linux.org.ru/jump-message.jsp?msgid=1624721

>если будешь придерживаться элементарных правил -

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

там все свелось на производительность.

mod_perl стоит попробовать.

>mod_perl стоит попробовать

а какие плюсы по сравнению с mod_php?

жаба, Spring IoС, Spring MVC, jdbc без ormов всяких.

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

а сопровождать жабу сможет ли какой-нить "програмист 1с"?

"программист 1с", это тот, который не может найти собственный член, даже если ему дать карту и фонарик?

На БОЯНЕ!

> Так что народ советует/практикует для "новых проектов"?

Все очень просто. Для простых проектов - пхп наше все. Особенно если есть наработки.

Для сложных проектов я выбрал Руби и рельсы. На данный момент это самая сильная связка в Вебе из обычных языков. Тоесть я не рассматриваю Лисп/Смаллтолк и другое.

Сильные стороны технологии: простота работы с базой данных(джанго еще расти и расти), универсальность и гибкость Руби, ясный продуманный фреймворк, который позволяет максимально сосредоточиться на логике приложения.

Слабые стороны: пока что мало хостингов(они есть даже в России, но мало) по сравнению с пыхом.

Поэтому если проект достаточно средний - бери рельсы и Руби. Если небольшой - пых.

ога. особенно, если "тот" - девушка.))

Например - начинающий програмист, студент, без опыта в серьезных проектах. С подходом "неправильно, но проще и быстрее".

>Слабые стороны:

и скорость, скорость низкая.

тагда уж перл, он хоть побыстрее.

если английский знает и у нее есть пол года , то в жабке разберётся.

А если WEB приложение LCMS (Learning Content Managment System). Причем требования приличные например одно из требований это кол-во одновременно работающих пользователей равное 500-1000 человекам. Потом поддержка основных баз данных (MSSQL, Oracle, PostgreSQL и.т.д). Желательно кроссплатформенность, поддержка создания собственных Workflow. То есть такая достаточно навороченная СДО (система дистанционного обучения). Вопрос, на каких технологиях имеет смысл создавать такую систему. Пока был рассмотрен ASP.NET 2.0 и .NET 3.0 + ORM. В принципе подходит, но хотелось бы иметь альтернативы например Zope или что нить-будь на Java. Может кто с опытом подскажет?

>тагда уж перл,

его молодежь не сильно-то жалует...:/ А мож - пока проект готов будет - все перловщики на пенсию выйдут! )))

Я жалую! :)

жабка, Spring + Hibernate (если без ORM никак) + Clustred Cache типа Tangosol Coherence http://www.tangosol.com/html/coherence-overview.shtml

еще есть opencms и уже готовая LCMS от американских универов, но не помню как называется.

> его молодежь не сильно-то жалует...:/ А мож - пока проект готов будет - все перловщики на пенсию выйдут! )))

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

>Дык на кого ты ориентируешься? Моложежь скоро

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

>Бабло получишь - дальше не твои проблемы.

А тут ты не прав в корне.

Во-первых, с "выходом в свет" как правило и начинаются настоящие проблемы.

А во-вторых - еще не известно, получу я бабло, или нет, т.к. весьма вероятно, что проект будет открыт, => коммерческие перспективы весьма туманны.

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

Для этого, а также - прикрытия с воздуха, есть профессионалы.

Ну, как говориться - дай Бог.

>там все свелось на производительность.

Впрочем, как и здесь. Нужна производительность, бессонные ночи и в итоге геморрой - выбирай C. Хочешь больше времени гулять с девушкой и тратить на неё заработанные деньги - выбирай удобный фреймворк(избавит от создания благоприятной среды) и удобный язык, где меньше синтаксического сахара.

А вообще, выбирай PHP, а я буду гулять с твоей девушкой.

То есть ты - за жабу?

Ну, а чем PHP менее _удобный_?

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

s/меньше/больше/g ? или нет?

>А вообще, выбирай PHP, а я буду гулять с твоей девушкой.

Антоха, хочешь погулять с моей? В зоопарк там или в Баскин-Робинс - это она тебя сводит без проблем..

Я за RoR и Python+Django(который не пробовал, к сожалению).

>Ну, а чем PHP менее _удобный_?

PHP4 - крайне неудобен. Нет исключительных ситуаций(приходится тянуть if-портянки по 100 строчек), нет нормальной объектной модели

PHP в целом - постоянно во всех проектах приходится учитывать посторонние вещи, как magic_quotes, register_globals.

PHP5 ещё ничего, но если ты считаешь, что "мало хостингов - это минус", то PHP5 ты не будешь использовать. На тех хостах, где PHP5 есть, почти везде отключены важный козыри PHP5, как PDO, не говоря уже о memcache. А отключены потому, что большинство php-кодеров не пользуются всеми бонусами php. До сих пор все поголовно используют mysql_-функции, API которых уже давно устарел. Почему-то mysqli и PDO не использется программистами на public-хостах.

В RoR всё поставляется из коробки. Хостинги ко всему прочему поддерживают gems (аналог pear-extensions) только потому, что у RoR хороший community.

CakePHP попробуй недельку-две. Может понравится.

Перл вообще не вижу в данный момент смысла поднимать с нуля...

Уже есть пагс-интерпретатор 6-го (даже в браузере можно поганять). Думаю в 2007 увидим уже и на парроте. Языки разные, старый будет загибаться, так зачем учить то, что скоро умрет?

нет. в пхп - больше. это меня и смущает - код может быть настолько "сладким" - жопа слипница :/

меньше
В смысле меньше лишних закорючек, длинных имён и т.д.

Perl, mod_perl, Template Toolkit, Apache::Template

Ror как раз весь перезасахарился от syntactic sugar

> То есть такая достаточно навороченная СДО (система дистанционного обучения)

При такой нагрузке все равно на чем писать. Дело в том, что без кеширования/балансирования нагрузки не обойдешься в любом случае. Про .net говорить не буду, не знаю. Зачем тебе зопа понять не могу. Работал с LCMS (moodle, ilias, atutor) - все на пыхе. Если они на пыхе нормально(точнее кое-как :) ) пишутся, то на рельсах повеселее будет.

Кеширование в рельсах есть с коробки + АОП(для гибкого кеширования). Балансировка нагрузки тоже нормально поднимается. Юникод уже в эдже есть, с версии 1.2 будет с коробки.

ЗЫ: не знаю где ОРМ лучше в .net или rails, но точно знаю что джанговский орм очень сильно уступает рельсам.

Selecter, спасибо.

> ...козыри PHP5, как PDO, не говоря уже о memcache ... все поголовно используют mysql_-функции ... Почему-то mysqli и PDO не использется...

Понял: надо покурить это все.) А проблемы "хостингов" - не существует. )

Однако, видимо действительно - "пых-пых наше фсио"... В "нашем ауле" я не знаю никого, кто использует Ruby/Python..

> Ror как раз весь перезасахарился от syntactic sugar

Я немного не понимаю соль прикола о синтаксическом сахаре. Может кто объяснить, чем плохо вместо херищи кода, написать пол-херищи? Да, в Руби можно строку задать где-то пятью способами, но в каждом случае это дает __удобство__.

Например: str = %(<a href="http://zlaya.com/scylko.html">Zloy's home</a>) - не приходится мудохаться со слешированием.

Чем плохо, то что одну и ту же вещь можно в зависимости от ситуации сделать удобнее?

>Ror как раз весь перезасахарился от syntactic sugar

Что за чушь несёшь?

>Например: str = %(<a href="http://zlaya.com/scylko.html">Zloy's home</a>) - не приходится мудохаться со слешированием.

Плохой пример. Зачем ссылку пихать в переменную, когда есть helpers? <%= link_to "Zloy's", { :action => "home" } %>

если ты считаешь что syntactic sugar не является отличительной особенностью Ruby, хорошо, я спорить не буду.

>На жабе ты задолбаешся писать: там даже нормальных регулярных выражений нет, PHP, Perl- это все фуфло. .NET - это бабло требуется. python, ruby - наше все. Насчет "секурности": если будешь придерживаться элементарных правил - все там будет секурно, в отличии от PHP.

Серьезно? Нет нормалных рег. выражений? Это не считая стандартных и опенсорсных, кот. перловые копирует один в один? Ну тогда может...

http://www.linux.org.ru/jump-message.jsp?msgid=1628191#1628272

> если ты считаешь что syntactic sugar не является отличительной особенностью Ruby

я не понимаю этого buzz'а вокруг syntactic sugar... Чем плохо? Пример выше привел. Удобно. Насколько я понял эти песни любят в среде функциональный языков. Но Руби все таки не функциональный язык. Поясни, может я чего-то не понимаю.

нет никокого buzz. Просто селектер ратует за "меньше синтаксического сахара." одновременно с RoRом. Вот я и хотел поинтересоваться как это в нем уживается. против сахара ничего не имею ;)

>Просто селектер ратует за "меньше синтаксического сахара." одновременно с RoRом.

Как раз наоборот :-)