Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 95
Решили попробовать написать проект на питоне… Причину выбрали довольно банальную — Яндекс хвалит питон. Так же нашли пару статей про использование Django в Яндексе. Отзывы больше положительные
Как-то не объективно совсем.
Было бы очень интересно услышать сравнение питоновского Django с какими-нибудь развитыми фреймфорками php.
Ненависть тоже бывает по разному поводу: синтаксис, библиотеки, поведение и т.д.
Я пришел к такому же выводу как автор топика после одного мелкого синтаксического недоразумения:
mysql_query(query, resource)
и
sqlite_query (resource, query)
sqlite_query (query, resource)
И когда вы переводите проект с sqlite на mysql, а там используются ДВА РАЗНЫХ ТИПА записи одного и того же, причем в основном первый, который не такой, как mysql, это просто бесит.
И да, это просто стало последней каплей среди всего того синтаксического бреда, что присутствует в пхп.
mysql_query(query, resource)
и
sqlite_query (resource, query)
sqlite_query (query, resource)
И когда вы переводите проект с sqlite на mysql, а там используются ДВА РАЗНЫХ ТИПА записи одного и того же, причем в основном первый, который не такой, как mysql, это просто бесит.
И да, это просто стало последней каплей среди всего того синтаксического бреда, что присутствует в пхп.
Есть такое дело.
Но в пхп есть одна интересная фишка. Все эти функции можно привести к одному виду, в принципе. Так как внутри они все регистрируются в специальных структурах, то параметры функций можно переставлять по своему усмотрению. Кто бы только написал такое расширение? :)
Но в пхп есть одна интересная фишка. Все эти функции можно привести к одному виду, в принципе. Так как внутри они все регистрируются в специальных структурах, то параметры функций можно переставлять по своему усмотрению. Кто бы только написал такое расширение? :)
Я писал для себя обёртки для них прямо на пхп, который инклудил в каждый проект.
Ну по сути обертки я и использую, в частности doctrine, хотя можно было бы обойтись и просто PDO. То, что мне приходится работать с проектами в которых используются… мм… странные решения — это отдельная тема)
Понятное дело, что для пхп написано уже уйма всего, которое пытается устранить эти врожденные недостатки, но это костыли…
К тому же это только один пример из множества… А наличие ~10+ функций для сортировки? Да и практически для любого действия такое. И еще уйма, уйма мелких, но раздражающих «особенностей».
Понятное дело, что для пхп написано уже уйма всего, которое пытается устранить эти врожденные недостатки, но это костыли…
К тому же это только один пример из множества… А наличие ~10+ функций для сортировки? Да и практически для любого действия такое. И еще уйма, уйма мелких, но раздражающих «особенностей».
Согласен. Можно использовать обертки и костыли, и для старого проекта на PHP, где уже написано куча кода, конечно это выход из ситуации. Поэтому я тут и настаиваю, что скорее выбор чисто субъективен, и нет четких 100% критериев, по которым можно с уверенностью сказать да точно стоит переходить на Python, Rails и прочее. Нет таких критериев. Просто накипело. Кстати не факт что и в Pyhton нет таки «бесящих» мелочей. Кстати вот она уже наклевывается — это необходимость перезапускать дев сервер каждый раз, чтобы изменения, сделанные в коде вступили в силу.
Точно не помню, но как-то это обходится. То ли не для любого изменения кода надо перезапускать, то ли есть тулза, чтобы не перезапускать. Надеюсь под дев-сервером вы имеете в виду встроенный сервер, а не полную имитацию продакшена?
Да, я имел ввиду встроенный сервер. Я заметил что, если править шаблоны то вроде сразу изменения отображаются, если править код отображений и моделей, то надо перезапускать. Еще непонятно зачем в Django отошли от общепринятой нотации MVC, Модель у них так и есть модель, контроллер почему то отображение (view), а view — у них называется шаблон. Немного путаница возникает.
Именно это и имел в виду. Где-то в доках есть точное описание, что ловится автоматом, а для чего нужен перезапуск.
Там есть идеологические тонкости. Тоже тема для большого холивара :)
Там есть идеологические тонкости. Тоже тема для большого холивара :)
Тут-то как раз тонкостей мало.
Шаблоны перечитываются каждый раз (даже на продакшне, если не включить в настройках их кеширование).
Код — на дев-сервере перечитывается каждый раз (исключая внешние библиотеки). Бесящая мелочь — при ошибке в модели dev-сервер может упасть.
На продакшне код перечитывается при touch project.wsgi
Как-то так
> Еще непонятно зачем в Django отошли от общепринятой нотации MVC,
Холиварный вопрос. Отошли от классики в пользу прагматики (все равно во view редко бывает больше десятка строк).
Бесящие мелочи вылезут позже. Тормозные шаблоны, своеобразный ORM, dependency hell, неумение дропать констрейнты в InnoDB и описывать индексы в модели, допиливание админки бензопилой (особенно русские падежи доставляют)… Продолжать, наверное, не буду )
Но даже при этом django для большей части задач остается… Не серебрянной пулей, но, наверное, самым вменяемым фреймворком для шаблонных задач
Шаблоны перечитываются каждый раз (даже на продакшне, если не включить в настройках их кеширование).
Код — на дев-сервере перечитывается каждый раз (исключая внешние библиотеки). Бесящая мелочь — при ошибке в модели dev-сервер может упасть.
На продакшне код перечитывается при touch project.wsgi
Как-то так
> Еще непонятно зачем в Django отошли от общепринятой нотации MVC,
Холиварный вопрос. Отошли от классики в пользу прагматики (все равно во view редко бывает больше десятка строк).
Бесящие мелочи вылезут позже. Тормозные шаблоны, своеобразный ORM, dependency hell, неумение дропать констрейнты в InnoDB и описывать индексы в модели, допиливание админки бензопилой (особенно русские падежи доставляют)… Продолжать, наверное, не буду )
Но даже при этом django для большей части задач остается… Не серебрянной пулей, но, наверное, самым вменяемым фреймворком для шаблонных задач
По поводу своеобразного ORM. Тут согласен. Надо постоянно мониторить какие запросы SQL создаются к базе, особенно при обращении к связанным таблицам, а то может получится так, что при, вроде бы безобидной выборке 100 строк с обращением к полям дочерней таблицы (обычный по сути JOIN), ORM генерирует101 запрос к базе, 1 основной и по одному запросу к дочерней таблице. Правда стоит отметить, что об этой особенности, и как ее обойти есть упоминание в документации по Djanjo.
Суть не во фреймворках (их архитектуре, функциональности и т. п.), а в синтаксисе языка прежде всего и в стандартных типах и либах. Слабая типизация, да ещё с неочевидными приведениями типов, доллары, ->, {}, array() (пофикшено в 5.4), да банальное function (в python — def), да ещё без именованных параметров. То есть один и тот же алгоритм, мысль если угодно, выражается на python короче (это бог с ним), а главное понятнее, без лишнего мусора, не несущего семантической нагрузки.
Я думал выбор состоит в том, какой инструмент лучше для задачи, а не какой красивее или где круче синтаксис.
Про роль синтаксиса в языке неплохо сказано в этом треде (прошу не воспринимать как оскорбление — это не моя манера выражаться, но тред клёвый)
Объективного сравнения фреймворков в принципе не существует, я по крайней мере не встречал. По большей части выбор фреймворка, несмотря на все технические сравнения и прочее все таки скорее субъективен. А то иначе давно бы нашли «самый лучший» фреймворк в мире и писали бы только на нем. Так же я отметил что проекты на PHP довольно зрелые, а на Django довольно молодой — поэтому опять же качественного сравнения привести не получится, надо сначала на Django тоже шишки понабивать, а потом уже и сравнения писать. Хотя я встречал уже сотню таких сравнений, и все они сводятся к обычному «холивару», а не хотелось бы
Сравнить не в ваакуме, а конкретно под вашу задачу. Что и как решает питон, а что пхп. Потому что действительно холивары и пиписькометры надоели.
Как можно объективно сравнивать такие параметры как «красота», «понятность» или «легкость деплоя». Максимум rps и количество строк вручную написанного кода может что-то сказать.
Можно. Как читать код
Но это особого смысла не несёт. Но например по Задаче в django это делается так-то, а в пхп так-то. Я считаю в джанго круче, потому его и использую.
if(condition&&condition2&&condition3){doSomethingHere();if(a)AndDoMore();}if ( condition && condition2 && condition3 )
{
do_something_here();
if ( a )
and_do_more();
}Но это особого смысла не несёт. Но например по Задаче в django это делается так-то, а в пхп так-то. Я считаю в джанго круче, потому его и использую.
Объективно нельзя это сравнивать. Кто-то скажет первый вариант круче — меньше строк и символов, а кто-то второй (кстати не идеальный, по многим стайл гайдам if без {} не пройдёт даже автоматическую проверку) — сущности визуально отделены.
Кто-то скажет первый круче, если он обоснует, что в угоду уменьшения строк жертвует читабельностью, а не просто прихоть, что он так привык. Это, мне кажется, и есть объективность. Если он уверен, что его код только для него. Я к этому веду.
В угоду повышения производительности труда — меньше клавиш нажимать — это объективная оценка. Читабельность — субъективная.
Читабельность тоже объективная: поиск необходимого в большом коде, любой пропуск команд и повторный поиск — это трата времени. А если кто-то другой изучает код, то тем более трата времени.
Короче, давайте не спорить на эту тему. Я такой код если вижу, то даже не читаю его, а заставляю переделывать. Лишь в случае, когда разбирается проект в поддержке. Но там можно какой-нибудь beautifier натравить.
Короче, давайте не спорить на эту тему. Я такой код если вижу, то даже не читаю его, а заставляю переделывать. Лишь в случае, когда разбирается проект в поддержке. Но там можно какой-нибудь beautifier натравить.
Трата времени — это объективно, да, в любом случае оно тратится. Но конкретная трата субъективна. Разве что статистику можно собрать.
Я бы вас и второй ваш вариант заставил переделывать — есть потенциальное место для ошибок при расширении действией, необходимых если a истинно. Да и просто: «считай, что человек, которому придётся изменять твой код знает где ты живёшь и является маньяком, склонным к насилию» или как там говорится — ему придётся две скобочки фигурных ставить…
Я бы вас и второй ваш вариант заставил переделывать — есть потенциальное место для ошибок при расширении действией, необходимых если a истинно. Да и просто: «считай, что человек, которому придётся изменять твой код знает где ты живёшь и является маньяком, склонным к насилию» или как там говорится — ему придётся две скобочки фигурных ставить…
В моем опыте набор кода значительно менее затратен чем придумывание. Кроме того IDE позволяет авто-дополнениями сильно сократить количество печати.
Вообще конкретика на данный этап уже начала вырисовываться, но пока фактов не хватает для полноценной и адекватной статьи, еще нет уверенности что вот тут действительно лучше у одного языка чем у другого. Но попозже конкретика будет, я обещаю.
Скажем так, можно объективно сравнивать, что языки, что фреймворки по какому-то одному параметру (и то не по всем). Но если сравнивать по нескольким, то явного победителя скорее всего не будет, а вот весовые коэффициенты каждого параметра уже точно субъективны, холивары это подтверждают. Для кого-то важен синтаксис и целостность, для кого-то простота деплоя и куча продуктов на любой вкус.
О чем статья-то? Где конкретика? Или вы просто ждете, что «процесс разработки полностью стабилизируется»? «Что не нравилось в PHP как раз удовлетворяло в питоне»? Где практический пример, как было плохо на php, как стало хорошо на питоне.
Скоро люди вообще не будут писать на Хабр.
Я написал что проект молодой и конкретика особо не сформировалась. Вдобавок так же я писал что на любой конкретный довод в пользу того или иного языка найдется парочку утверждений в обратном. В статье я по большей части хотел отразить то, что на самом деле выбор технологии гораздо более субъективен и нет абсолютно истинных четких критерием выбора той или иной технологии.
Ну вот почему последние несколько статей — ведро воды и ничего более?
Давайте тогда уж все хабраюзеры напишут каждый по статье, как они тем или иным образом перешли с одного языка на другой, описывая только: Нам не понравилось, а вот в нем вроде как всё нормально, поэтому и решили писать отныне на нём.
Где подробности? Где тривиальные решения и сравнение двух языков?
Ну и наконец, извиняюсь, но у меня назревает один единственный вопрос:
Зачем эта статья и какая у нее польза для людей, читающих один из разделов, которые Вы указали?
Давайте тогда уж все хабраюзеры напишут каждый по статье, как они тем или иным образом перешли с одного языка на другой, описывая только: Нам не понравилось, а вот в нем вроде как всё нормально, поэтому и решили писать отныне на нём.
Где подробности? Где тривиальные решения и сравнение двух языков?
Ну и наконец, извиняюсь, но у меня назревает один единственный вопрос:
Зачем эта статья и какая у нее польза для людей, читающих один из разделов, которые Вы указали?
Есть у него и своя очень приличная ниша в мелких, и может быть, средних проектах.
Посмотрите ещё на Flask — может и ниши для PHP не найдёте :)
А если серьезно, то имхо, большой (если не единственный остался) плюс PHP — развитые CMS и прочие «коробочные» продукты, с установкой которых на хостинге справится любой «обычный пользователь». Если продукт пишется с нуля (с фреймворком конечно же) и с учетом его поддержки, то выбирать PHP можно только если нет людей, знающих другие языки или способных их быстро освоить.
Посмотрите ещё на Flask — может и ниши для PHP не найдёте :)
А если серьезно, то имхо, большой (если не единственный остался) плюс PHP — развитые CMS и прочие «коробочные» продукты, с установкой которых на хостинге справится любой «обычный пользователь». Если продукт пишется с нуля (с фреймворком конечно же) и с учетом его поддержки, то выбирать PHP можно только если нет людей, знающих другие языки или способных их быстро освоить.
Я не то, чтобы против Django, просто хочу поделиться опытом про переписывание — проект, который я делал месяца на 2 PHP ( без фреймворков ), был переведен за 1 неделю на Rails, при этом сопровождать его стало гораааздо легче.
Пытался пройти 10 километров, поджав одну ногу, на костылях. Шел неделю. Потом бросил костыли, одел кроссовки и не напрягаясь дошел за 2 часа. Идти стало гораааздо легче.Уже много раз говорили, что фремворки нельзя сравнивать с чистым языком.
Вы извините, но это чушь. Когда вы писали проект — вы придумывали архитектурные решения, придумывали схему базы, рассматривали алгоритмы, разрабатывали логику приложения. А во втором случае тупо переписывали. Вам не кажется. что сравнение времени вообще в данном случае не в кассу? Ведь вы просто повторили первый проект, выбросив ЛЬВИНУЮ часть разработки. Какой смысл сравнивать изначальную разработку с тупым переписыванием кода?
Немного непонятна позиция руководства в организации, о которой идет речь. Вы заставили разработчиков учить новый язык, начали поиск новых разработчиков (видимо взамен тех, что не захотели переучиваться), только потому, что вам «подсознательно» перестал нравиться php? Для таких радикальных мер, я бы, на месте вашего руководства, потребовал доводы по серьезней, чем нечто подсознательное и необъяснимое.
Может автор сам руководство?
Я являюсь руководством. И моей задачей в частности является снизить скорость разработки проекта. Читая форумы, на которых приводятся технические сравнение языков и фреймворков, понял, что большая часть — это переводы статей. А реалии разработки ПО за рубежом, несколько отличаются от наших. Читая статьи — сравнения «местного» производства, создавалось ощущение их однобокости. Можно найти статьи где рассказывается о абсолютном лидировании PHP над Python или наоборот. Да, в этих статьях конкретики вроде побольше чем в моей, но пользы наверное столько же. Каждый хвалит свое. На самом деле пока у меня лично нет однозначного решения что же все таки лучше, поэтому и сравнений нет никаких. На счет разработчиков. Большая часть разработчиков — фрилансеры, и на новые проекты все равно приходилось бы нанимать новых людей, так что никого не увольняли и насильно переучивать язык не заставляли. Учить новый язык по большей части из всей команды пришлось только мне. Просто появилась возможность начать новый проект с новой командой.
И моей задачей в частности является снизить скорость разработки проекта.
ОМГ!!! Обычно все стараются повысить скорость разработки, хотя бы чтобы на хабре было время пообщаться. А вы скорость снижаете. Зачем?!
P.S. Понимаю, что неудачно выразились. :)
ОМГ!!! Обычно все стараются повысить скорость разработки, хотя бы чтобы на хабре было время пообщаться. А вы скорость снижаете. Зачем?!
P.S. Понимаю, что неудачно выразились. :)
Я воспринимал статью как переход целой организации от одной технологии к другому, это было интересно и рискованно. Переход одного человека, на другой язык — совершенно неинтересен. Статья потеряла смысл.
Во первых, о полном переходе от одной технологии к другой речи не велось изначально. Просто пробуем писать новый проект на новой технологии и окончательное решение будет приниматься только после того, как станет понятно, что одна технология имеет ощутимые преимущества над другой. Но даже после этого старые проекты на PHP останутся, и никто переводить их на другую технологию не собирается. Пока по крайней мере. Во вторых, с чего вы взяли что статья — это переход одного человека на другой язык. Если вас смутили в комментарии мои слова
Учить новый язык по большей части из всей команды пришлось только мне
То я, как технический руководитель, посчитал для себя обязательным ознакомится хотя бы с азами языка и фреймворка.
Учить новый язык по большей части из всей команды пришлось только мне
То я, как технический руководитель, посчитал для себя обязательным ознакомится хотя бы с азами языка и фреймворка.
аргументация типа «мне не нравится синтаксис языка, поэтому язык говно».
Насколько быстр Python? Сколько страниц Python может сгенерировать за секунду (без учёта времени подключения и работы БД) на среднем сервере (например Amazon ec2 small)? Каковы издержки на передачу данных? Преположим, что это стандартная страница на 50кб (шапка, подвал, меню из 10 пунктов, 20 комментариев пользователей) и код написан профессионалом, что среда настроена оптимально и всё то нужно стоит (кроме http — кеша).
на моем, python с django работает примерно на уровне php(с акселераторами). без django — раза в 1.5 шустрее
Какой это уровень, можно конкретные цифры, пожалуйста?
100-120 для ab -c 100 -n 1000
на не особо шустром vps
на не особо шустром vps
100-120 rps? Сложность страниц примерно одинаковая, и разницы между php и python практически нет, я правильно понял? И без django 170-180 rps? В принципе, неплохая скорость. Можно ли на основе этого сделать вывод, что при выборе между php и python скорость языка не является аргументом?
Это вроде давно известный факт. Скриптовые языки вроде Perl (? тут не уверен, но счёл нужным упомянуть), PHP, Python и Ruby по скорости где-то на одном уровне находятся, если использовать «штатные» интерпретаторы. Скорость не аргумент вроде давно, как-то даже неприличным считается упоминать её в холиварах :) В пользу PHP основные аргументы: простота деплоя и, как следствие, дешевые хостинги, очень много готового кода (прежде всего «коробочные» продукты — CMS/F, форумы, магазины, игры и т. д.) и множество дешёвых разработчиков.
Оно понятно, но раз есть не «штатные» решения, было бы полезно услышать мнение питонщика с опытом. К слову, «простота» PHP и дешевизна разработчиков-джуниоров компенсируется ценой поддержки или полной переработки некоторых таких «решений». В среде питонщиков насколько такая ситуация распространена?
Преимущества в скорости работы какого либо из проектов написанных на PHP либо Python, находящихся на одном и том же сервере не обнаружено. Проекты не особо посещаемые, до 1000 уников в сутки. Так что острого вопроса скорости работы не стояло. А на счет нескольких PHP джуниоров или одного опытного питониста, тут сказать ничего не могу опыт — покажет. Но пока, все говорит о том, что опытный программист пока экономически более выгоден. Хотя опять же стоит отметить, что найти PHP программиста и проще и дешевле. Наверное из за большей конкуренции.
Питонщик с опытом вряд ли пользовался hiphop или даже phpdaemon в режиме true fastcgi.
При должной организации работы и использованием надлежащих инструментов не думаю, что разница в трудоемкости поддержки (цена человеко-часа — отдельный вопрос) будет значительна, ведь большую часть времени нормальный программист думает, а не ставит рекорды по скорости набора кода. Справедливости ради — субъективно, среди пхп-разработчиков (или их «менеджеров»?!) эти «должная» и «надлежащая» встречаются редко, лично для меня только в опенсорс проектах и то, далеко не во всех. Мои заказчики на предложение, например, внести приложение под контроль VCS и покрыть его тестами отвечали что-то вроде: «раз считаешь нужным — делай, но цена и сроки не изменятся».
К питонщикам (как к сообществу) не отношусь, изредка пишу для себя что-то на питоне (скрипты, автоматизирующие пользовательскую рутину (то, что когда-то писал на .bat) — баш не осилил, плагины для редакторов, где питон нативен), пробовал джангу на учебных проектах. В общем только в холиварах участвую, отстаивая точку зрения, что питон или руби много лучше PHP как языки, но для малого бизнеса, не имеющего хотя бы грамотного админа в штате, лучше заказывать свое первое представительство в вебе «чтобы было» лучше на PHP. Или закладывать в бюджет постоянный аутсорс, а не только разработку.
При должной организации работы и использованием надлежащих инструментов не думаю, что разница в трудоемкости поддержки (цена человеко-часа — отдельный вопрос) будет значительна, ведь большую часть времени нормальный программист думает, а не ставит рекорды по скорости набора кода. Справедливости ради — субъективно, среди пхп-разработчиков (или их «менеджеров»?!) эти «должная» и «надлежащая» встречаются редко, лично для меня только в опенсорс проектах и то, далеко не во всех. Мои заказчики на предложение, например, внести приложение под контроль VCS и покрыть его тестами отвечали что-то вроде: «раз считаешь нужным — делай, но цена и сроки не изменятся».
К питонщикам (как к сообществу) не отношусь, изредка пишу для себя что-то на питоне (скрипты, автоматизирующие пользовательскую рутину (то, что когда-то писал на .bat) — баш не осилил, плагины для редакторов, где питон нативен), пробовал джангу на учебных проектах. В общем только в холиварах участвую, отстаивая точку зрения, что питон или руби много лучше PHP как языки, но для малого бизнеса, не имеющего хотя бы грамотного админа в штате, лучше заказывать свое первое представительство в вебе «чтобы было» лучше на PHP. Или закладывать в бюджет постоянный аутсорс, а не только разработку.
Если в разработке не используются Case средства, то время написания самого кода, тоже существенный фактор. Python радует тем, что кода пишется ощутимо меньше. На счет поддержки тоже не все так гладко. Одно дело если проект разрабатывается корпоративно, существует четкая иерархия разработчиков, если люди которые постоянно контролируют качество кода и прочее. А вот если таких людей нет, то один юниор программист может написать модуль так, что кроме него там никто не разберется. Говно код можно написать на любом языке, но Python по моему как то меньше способствует написанию этого говнокода.
А с true fastcgi сравнивали? PHP и в 2 раза ускорение с ним даёт с symfony. То есть получается в ~1,5 раза быстрее чем python без django, если считать, что django и symfony одинаково тормозят.
Всё время мучает вопрос — а как в питоне начинающему «копипастить» примеры из уроков — ведь «табуляции» могут сбиться и код станет нерабочим (или хуже — неправильным)?
И о чем статья? Краткое ее содержание:
«Мы делали проекты на PHP, но он нам надоел. Перешли на Python — пока все нормально».
«Мы делали проекты на PHP, но он нам надоел. Перешли на Python — пока все нормально».
Вот так бывает, когда Яндекс не Rails выбирает :)
Внимательно послушайте, что говорит этот человек (http://www.youtube.com/watch?v=uF17_nhMRK0), и тогда проблема «PHP или Python» перестанет Вас тревожить.
Вот, кстати, отличное сравнение синтаксиса PHP/PERL/Python/Ruby.
hyperpolyglot.org/scripting
hyperpolyglot.org/scripting2
hyperpolyglot.org/scripting
hyperpolyglot.org/scripting2
Как надоело унижение php, «такой он отстойный и неправильный» можно подумать будешь писать на другом языке сразу перестанешь писать «гомнокод». то не нравятся «$» то «{}» Я наблюдаю последнее время отсутствия базовых знаний «виды сортировок...» «ооп» «стеки, очереди, кучи...» зато обосрать язык всегда пожалуйста. А вообще парни крутые на раз и стали писать на другом языке, тут уже год основной проект кое-как в порядок привести пытаемся (700k пос/мес).
Я не заметил в данном топике унижение PHP, есть вещи которые не нравятся, но слова «отстойный» и «неправильный» я не произносил. В названии топика указано, что выбор непростой, что однозначно правильного решения пока не найдено, и определить какая технология лучше подходит для разработки Веб приложений не так просто. Поэтому ни о каком унижении PHP речи не идет. Говорится о том что он не устраивает в некоторых планах. Но согласитесь, язык действительно не идеален.
Понятно, что гораздо важнее знать азы программирования, и разработки структуры приложения, паттерны проектирования, основы СУБД, реляционной алгебры, и возможно дискретной математики, язык и фреймворк — всего лишь средство реализации, и если базовые знания программирования оставляют желать лучшего, то разницы, как каком языке пишет человек, действительно нету. Но у меня поверьте базовые знания есть, и изучить новый язык для меня не составляет никакой проблемы, и поэтому если язык меня не устраивает то я перехожу на новый. Не факт что Python устроит во всем, но по крайней мере будет с чем сравнивать. А вы считаете что стремление в поиске более продвинутой технологии это унижение старой?
Понятно, что гораздо важнее знать азы программирования, и разработки структуры приложения, паттерны проектирования, основы СУБД, реляционной алгебры, и возможно дискретной математики, язык и фреймворк — всего лишь средство реализации, и если базовые знания программирования оставляют желать лучшего, то разницы, как каком языке пишет человек, действительно нету. Но у меня поверьте базовые знания есть, и изучить новый язык для меня не составляет никакой проблемы, и поэтому если язык меня не устраивает то я перехожу на новый. Не факт что Python устроит во всем, но по крайней мере будет с чем сравнивать. А вы считаете что стремление в поиске более продвинутой технологии это унижение старой?
Изучение нового это прекрасно. Смочь остаться на выбранной технологии/языке и т.д. почти победа. Дело не в том что то или иное средство лучше а в том что диктует бизнес, если вы сумеете продержатся в выбранных средствах/языке почет и хвала вам.(работали с perl,python,ruby но все равно не по своей прихоти со слезами на глазах вернулись к php)
За последние время огромное кол-во камней в огород php, просто надоело, язык не без изъянов но при этом он делает то что от него требуют, и не плохо. История повторяется на prel тоже жаловались, а посмотрите что сейчас происходит. да и python не без грешный конечно по сравнению с php он праведник но…
ЗЫ: контекст он и в Африке.
За последние время огромное кол-во камней в огород php, просто надоело, язык не без изъянов но при этом он делает то что от него требуют, и не плохо. История повторяется на prel тоже жаловались, а посмотрите что сейчас происходит. да и python не без грешный конечно по сравнению с php он праведник но…
ЗЫ: контекст он и в Африке.
На счет «диктует бизнес», с Вами на 100% согласен. Если бы я писал этот пост год назад, то, наверное, камней в огород PHP, полетело бы гораздо больше, и пост, наверное, получился бы обильно сдобренный матом, но…, слезть с «иглы» PHP за год не получилось. Если проект делается на заказ и он не слишком крупный, то заказчика по большей части волнует – доступность, распространенность и дешевизна хостинга, доступность специалистов, способных поддерживать сайт. Слово PHP, многим заказчикам знакомо, как ни странно, даже если они ничего общего не имеют с IT, многие заказчики думают, что это вообще единственный язык для разработки сайтов. Но при слове Python или еще что то, заказчик настораживается, и уже относится к тебе недоверчиво…. В общем, спустя год, наступило некоторое смирение что ли, и к языку отношение уже немного другое. Как к мулу, его все бьют, пинают, а он знай себе, везет груз, и делает свое дело.
Но когда созрела задача написать собственный проект, то тут решили рискнуть и попробовать другую технологию.
Но когда созрела задача написать собственный проект, то тут решили рискнуть и попробовать другую технологию.
Так сравнивали бы php + symfony2 с python + jango.
Иначе все описанные вами плюсы и минусы – это
бред малообразованного быдлокодера, который
открыл для себя MVC фреймврк.
Иначе все описанные вами плюсы и минусы – это
бред малообразованного быдлокодера, который
открыл для себя MVC фреймврк.
Да есть. Сомневаюсь что переход с CI на symfony2 устранят те недостатки языка которые не устраивали нас. Как раз к фреймворку CI претензий нет никаких, он всем устраивает, не идеален конечно, но так скажем «очень приятен в общении», а вот к самому языку претензии есть, и мы приняли решение (довольно не простое), что нужно попробовать новый проект разрабатывать на новом языке + фреймворке. Чтобы хотя бы самим иметь представления и понять какая из этих двух связок PHP + СI или Python + Django в практическом применении лучше. Кстати особых проблем в изучении нового языка я не вижу. Гораздо сложнее освоить новый фреймворк, понять его структуру, ньюансы и прочее. Так что если брать трудозатраты на изучение новой связки Python + Django или нового фреймворка на PHP, то Python + Django не намного сложнее освоить. Еще хочу заметить что работающим у нас программистам на PHP не надо будет ничего переучивать, так как они сидят на старых проектах на PHP и работы там тоже хватает. Для нового проекта будут наняты другие программисты. Переучивать язык и фреймворк нужно мне, для более грамотного контроля за разработкой. Поэтому мне не обязательно становится гуру питона и джанго. Достаточно освоить азы.
PS. Кстати мы рассматривали в качестве альтернативы CI другие PHP фреймворки. В частности интерес вызвали Kohana — родственник CI и YII — в принципе тоже вполне достойные фреймворки. Один недостаток они на PHP :)
PS. Кстати мы рассматривали в качестве альтернативы CI другие PHP фреймворки. В частности интерес вызвали Kohana — родственник CI и YII — в принципе тоже вполне достойные фреймворки. Один недостаток они на PHP :)
CI с синглтон-моделью и невозможностью нормального автокомплита в IDE — это не полноценный фреймворк. Это все-таки уже вчерашний день. Имхо, стоит посмотреть современные php-фреймворки, а не переучиваться на другой язык. Кохана — ок, Симфони — ок. Laravel недавно появился интересный, с миграциями из коробки. Да даже Yii ок, хотя он инопланетный несколько.
В PHPStorm при соответствующих настройках автокомплит для CI отличный. Хотя на счет «вчерашнего дня» возможно вы и правы. Но я уже сказал что изучить новый язык не такая уж и проблема, гораздо большая сложность составляет изучения самомго фреймворка, и его тонкостей. Поэтому решив опробовать новый фреймворк, решили попутно и опробовать новый язык. А вдруг понравится :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нелегкий выбор Python или PHP. А может и то и другое?