Переход с PHP

Ruby on Rails, Struts (Spring, который здесь советовали, не совсем веб), Django (очень спорно). Остальное не востребовано.

> Ничто не предвещало беды, но тут до меня дошло, что язык имеет свои недостатки.

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

Обосновать сможете? Я не особо крупным проектом занимаюсь в сущности, но тут используется пара собственных утилит на си, AMQP очереди для отложенной обработки задач, миграции и пара демонов.
И я совокуплялся, делать заново авторизацию, если она давно протестирована и работает. Или те же картинки для предпросмотра. Зачем делать их заново, если они нормально работают? Есть гораздо более важные задачи типа того, как их распределять между серверами, чем 3 строки на imagemagick. Ну или админка. Зачем её с нуля писать, если есть приличный CRUD, который можно кастомизировать? А валидация форм? Зачем ее описывать каждый раз, если можно один раз задать нужные вещи в классе формы? Правда у php есть стандартные фильтры url/email/ip/regexp, куда можно прикручивать свои функции для обработки. Но в yaml пару строк чиркнуть проще. Или вы каждый раз фильтрацию по типу файла пишете заново?

> Нужна удобная обертка над HTTP и все нужное к ней прикрутить. Ничего больше не нужно. Веб-это просто.

Обёртка над HTTP + _всё_нужное_ = Rails :)

Больше всего меня раздражают эти:
- Тупые имена функций
- Каждый раз скрипт исполняется заново, даже в режиме fastcgi
- Отсутствие нормальной многопоточности
Поэтому на php я пишу обычно только фронтенд, то есть использую его в виде продвинутого шаблонизатора. А сама функциональность, в виде API, лучше на питоне идет.

http://ru.wikipedia.org/wiki/PHP#.D0.9A.D1.80.D0.B8.D1.82.D0.B8.D0.BA.D0.B0
http://lurkmore.ru/PHP#.D0.9D.D0.B5.D0.B4.D0.BE.D1.81.D1.82.D0.B0.D1.82.D0.BA...

незачто

зачем использовать php, если логика и так уже на питоне?

Во-первых удобнее на symfony мне некоторые вещи делать. Во-вторых легче найти программиста для поддержки. В-третьих совокуплялся я делать фронтенд на Twisted, а прикручивать джангу в виде фронтенда смысла не вижу.

Напишите пожалуйста статью о своей связке, очень интересна эта тема.

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

Я использую симфони не только как шаблонизатор. Там и кэширование и всякие тамбы для картинок и всякие мелкие штуки типа показывать-ли хелп, и интеграция с фейсбуком. Зачем мне это переписывать на twisted я не знаю.

>PHP

но тут до меня дошло, что язык имеет свои недостатки.

Мыши давились, но продолжали жрать кактус.

Интерфейс поиска кстати тоже на php, там просто фронтенд к сфинксу.

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

Зачем делать их заново, если они нормально работают

Я не занимаюсь проектами-однодневками. В сложных проектах многие стандартные вещи рано или поздно не работают как надо. К примеру авторизация - это крупный такой кусок бизнес логики.

Не нужно сразу все на свете. Нужна модульность и гибкость. В Rails как раз все гвоздями прибито. И да, не надо меня на него агитировать, я где-то пол года профессионально на нем писал.

ASP.NET же.

Для меня тоже не проблема сделать авторизацию. Но зачем Каждый раз делать её заново? Все эти подтверждения регистрации через email, «запомнить меня», сброс пароля, группы, acl? Зачем на это тратить ресурсы? Если стандартная вещь не работает, как надо, её можно дописать, чай не закрытые же сырцы.
Да и в некоторых проектах мне стандартная реализация вполне подходит. Шаблоны к ней свои можно привинтить и нужные вещи дописать, а oauth привинтить поверх.
Через некоторое время жизни проекта стандартные вещи иногда приходится выкидывать и писать свои решения. Но пока подходят стандартные, зачем писать свои велосипеды?
П.С.

К примеру авторизация - это крупный такой кусок бизнес логики.

Если авторизация - крупный, то средним куском бизнес логики является как я понимаю конструкция if?
П.П.С.
Буду весьма благодарен, если вы приведете мне примерное описание вашей сложной кастомной авторизации.

>я где-то пол года профессионально на нем писал.

Я не занимаюсь проектами-однодневками.

Диссонанс.

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

И как продвигается?

// сам пилю авторизацию, CGI уже работают, а вот с веб-мордами подзатянулось - хочется нормального функционала, с iframe'ами...

>В Rails как раз все гвоздями прибито.
В третьих кстати гораздо меньше гвоздей.

iframe нихрена не нормальное решение

html + C++

А зачем для авторизации iframe?

Python , Django vs Pylons vs Pyramid vs CherryPy

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

AJAX

И таки как ваш «аякс» мне на сервере поможет? Я что, в свои CGI javascript встраивать буду? =)

Чтобы не передавать в нешифрованном виде пароль.

Если запрос идет на https, то аякс отправит его в шифрованном виде. Ну или если не используется https, то можно просто отправить хэш пароля.

И таки как ваш «аякс» мне на сервере поможет?

Это просто HTTP(POST/GET/etc.) запрос из яваскрипта, на сервере ничем не отличается от обычного запроса к странице.

http://docs.jquery.com/Getjson http://json.org/json-ru.html и в бой

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

Не сказал бы, что чтобы отправить AJAX запрос нужны тонны кода. Да и если клиент общается посредством javascript, то вероятно аякс там уже есть.
Хотя ваш проект, вам решать что вам удобнее.

Страшновато...

если клиент общается посредством javascript, то вероятно аякс там уже есть

Естественно, нет. Зачем я из-за одной функции отправки xmlhttprequest'ов буду уйму лишнего кода тянуть?

xmlhttprequest - это и есть аякс. Не путайте с jQuery.
Кстати к слову, если вы используете формат JSON на Си, то какую либой парсите? Я http://fossil.wanderinghorse.net/repos/nosjob использую, но всё-равно кривовато выглядит.

Она на Си++, не на Си, если что.

если вы используете формат JSON на Си, то какую либой парсите?

Своей. Ее и заканчиваю.

http://code.google.com/intl/ru/appengine/

Открыть сырцы не планируете?

Выложу, как только допилю до более-менее приличного вида и придумаю, как make install по-человечески завернуть.

их и так немало http://json.org/json-ru.html

Я смотрел, там у большинства интерфейс кривой. Из чисто под С мне jansson понравился только.

Только мне JSON нафиг не нужен: у меня обычные POST-запросы вида параметр=значение, разделенные чем-нибудь из набора «\n &;\t», а также обработка файлов.

Но я же создал эту тему и ищу пути к искуплению своих грехов.

ЛОР, что с тобой? Где твои ответы?

То есть ты, флауэрс, хочешь сказать, что про все предложенные тебе языки и фреймворки уже почитал и все их по каким-то причинам считаешь для себя неподходящими?

думаешь ТС клоун/фловерс/итп?

Просветите, кто есть «флауэрс»?
Все ответы можно разделить на три типа:
1) Тролли, которые предлагают те языки, которые ну никак не востребованы в нашей стране.
2) Сторонники Питона
3) Сторонники Руби
Может еще кого забыл, не суть.
Но ничего не было сказано про преимущества и недостатки предпочитаемого ими инструмента, причины выбора, про то сложно ли найти работу в нашей стране.
Хотелось бы более развернутых ответов.

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

Она реализована в виде REST-сервиса так как используется в системе с SOA архитектурой. Логин происходит через запись в memcache. Собственно авторизация осуществляется через запрос пермишнов текущего пользователя через сервис.

Фичей всяких куча, вроде централизованного per-request immutable снимка текущей сессии, уведомление системы об изменениях пользовательского аккаунта через очередь сообщений, авторизационные домены, регистрационные домены и т.д.

Угу, родился и сразу начал пилить серьезные проекты.

Начинал со всякого говна, увы.