LINUX.ORG.RU

Подскажите годную альтернативу PHP/MySQL для PHP-быдлокодера со стажем.


1

2

Имею несколько лет опыта разработки на PHP/MySQL. До этого изучал C/C++ но их знаю на уровне hello world т.к. никаких серьёзных проектов не делал. Имел небольшое знакомство с Java которая не понравилась по многим факторам в том числе из-за ужасной производительности.

Чем больше опыта - тем лучше понимаешь что платформа PHP/MySQL трухлявая. Но совершенно не представляю куда ещё податься. Пытался перейти на Ruby. Поначалу язык показался очень приятным. Но при более близком знакомстве с написанными на нём фреймвёрками не понравился.

Присматриваюсь к Python. Нравится изящество и простота, толковый подход, упор на надёжность (в том числе и в большинстве программного обеспечения написанного на Python). Но есть одна проблема: с PHP было всё просто, можно сразу сесть и писать. Синтаксис дался легко т.к. был знаком с C/C++ до этого. Основную часть PHP изучил за 1 день. Поставил Apache + PHP + MySQL и можно сразу приступать к разработке. Для small to medium sized ничего более не требовалось. Но начал замечать что в более объёмных проектах было бы неплохо иметь framework. Имел знакомство с некоторыми PHP frameworks включая cakephp и не известно как прозносимый yii. Очень не понравились из-за громоздкости. Пытался разработать свой более lightweight. И пришёл к выводу что OOP в PHP хоть и существует но пользоваться им крайне не приятно и производительность начинает резко падать при любой OOP-изации. Обнаружил множество тёмных мест в PHP. Обратил внимание на сравнение - количество bug fix'ов в новых версиях PHP vs. Python и поразился как непрофессинально пишется PHP. Очень понравилось что последнее Security Advisory в Python датируется 2006 годом (как такое возможно? может я что то путаю: http://python.org/news/security/).

В общем Python как платформа выглядит для меня очень привлекательно, но как только дело доходит до практики не знаю с чего начать. Просто так сесть и писать как в PHP не получится - в дополнение нужен ещё framework. Но их так много что я не знаю как выбрать. Такие большие как Django отпадают т.к. ищу что то более lightweight. Множество других имеют довольно скудную документацию, по крайней мере с документацией PHP не сравнится.

Например нравится Pyramid, прочитал один туториал - понравилось. Начал читать другой для более сложного приложения и в конец запутался т.к. очень много вариантов. Может кто-то порекомендует что ещё почитать и/или посмотреть open source приложения т.к. с текущим объёмом знаний браться за серьёзный проект на Pyramid не считаю возможным.

Другими словами: требуется эффективная надёжная среда разработки веб приложений. Прошу помочь PHP-быдлокодеру стремящемуся к прекрасном :)

По поводу MySQL думаю переключиться на PostgreSQL, учитывая поглощение MySQL ораклом и как следствие проприетаризация.

Ответ на: комментарий от baverman

Да, признаю, ЛОР можно было бы и на PHP оставить.

Я, собственно, тоже не делал заявлений вроде «PHP лучший язык, а вы все дураки» (это было бы глупо), но люди действительно верят в маразм о том, что на динамических языках (Python/Perl/Ruby/PHP) хайлоад и мидлоад не пишут.

resurtm ★★★
()
Последнее исправление: resurtm (всего исправлений: 1)
Ответ на: комментарий от Reaper

Простое равномерное размазывание на временной промежуток количества просмотров - это совсем не RPS в пике

Это я прекрасно понимаю.

Возьмем поминутную статистику ЛОРа:

http://top.mail.ru/mdynamics?id=71642&period=2&date=2012-12-23&ge...

В самом пике 175 хитов в минуту. То есть где-то тысячная часть от суточного трафика. Для сайта с аналогичным профилем нагрузки и 200000 хитов это будет 3.3 RPS. То есть, я даже завысил свою оценку.

baverman ★★★
()

В общем Python как платформа выглядит для меня очень привлекательно, но как только дело доходит до практики не знаю с чего начать. Просто так сесть и писать как в PHP не получится - в дополнение нужен ещё framework. Но их так много что я не знаю как выбрать. Такие большие как Django отпадают т.к. ищу что то более lightweight. Множество других имеют довольно скудную документацию, по крайней мере с документацией PHP не сравнится.

Учитывая что расклад примерно такой Django-90%, Flask-6%, Pyramid-3%, Others-1%, и джангу ты отметаешь, посмотри Flask/Pyramid.

Например нравится Pyramid, прочитал один туториал - понравилось. Начал читать другой для более сложного приложения и в конец запутался т.к. очень много вариантов. Может кто-то порекомендует что ещё почитать и/или посмотреть open source приложения т.к. с текущим объёмом знаний браться за серьёзный проект на Pyramid не считаю возможным.

Да, рановато тебе на Flask/Pyramid. Поюзай всетаки джангу.

Другими словами: требуется эффективная надёжная среда разработки веб приложений. Прошу помочь PHP-быдлокодеру стремящемуся к прекрасном :)

Тогда бери Pyramid.

bismi
()

щас haskell/yesod все используют, вылезай из криокамеры.

x4DA ★★★★★
()

Другими словами: требуется эффективная надёжная среда разработки веб приложений.

эффективная

PhpStorm

надёжная

vim

commit ★★
()
Ответ на: комментарий от resurtm

Сэр, я сказал «на той же машине», что проистекает из того что Python/Ruby банально тормознее Java. А размаштабировать на много машин можно любое приложение и возможно Python/Ruby будут иметь много плюсов

vertexua ★★★★★
()

Запах тролля чую я ...

Имею несколько лет опыта разработки на PHP/MySQL
платформа PHP/MySQL трухлявая
Основную часть PHP изучил за 1 день
... yii. Очень не понравились из-за громоздкости
Пытался разработать свой
OOP в PHP хоть и существует но пользоваться им крайне не приятно
дело доходит до практики не знаю с чего начать
Django отпадают т.к. ищу что то более lightweight
прочитал один туториал

Призываю Капитана Пикарда

Axonom
()
Ответ на: комментарий от vertexua

Сэр, я сказал «на той же машине», что проистекает из того что Python/Ruby банально тормознее Java. А размаштабировать на много машин можно любое приложение и возможно Python/Ruby будут иметь много плюсов

benchmarks показывают что ваша джава действительно потребляет меньше процессорного времени. Однако она при этом такими темпами жрёт память что становится страшно, и если учесть манипуляции с памятью, содержание жирной VM, свопинг памяти - все преимущества теряются. Ощущения от работы с Java пренеприятнейшие.

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

Автору рекомендую остановиться на Python + Pyramid + PostgreSQL. Сам поначалу плевался на излишнюю простоту Python особенно после знакомства с Ruby. Но потом проникнулся идеологией и увидел реальные преимущества (а не абстрактную красоту как в Ruby). Вообще ruby красив для абстрактных целей (поковыряться, полюбоваться) но не для работы, Python - рассчитан на реальные задачи. Это как паскаль и C++.

tyler19
()
Ответ на: комментарий от vertexua

Сэр, я сказал «на той же машине», что проистекает из того что Python/Ruby банально тормознее Java. А размаштабировать на много машин можно любое приложение и возможно Python/Ruby будут иметь много плюсов

Когда твоя единственная машина начинает захлёбываться от количества посетителей, почти всегда узким местом становятся операции с бд. Время исполнения каждого запроса начинает расти в сторону бесконечности. И вот в этот момент, допустим, мы берём и меняем тормозной руби на скоростной дот.нет. Что происходит? Суммарное время ответа уменьшается на те несчастные 30 миллисекунд, на которые код на дот.нете отрабатывает быстрее. Но при этом бд мы никак не разгрузили и запрос как отрабатывал полторы минуты, так и отрабатывает. Итого, суммарно время ответа сервера с полутора минут сорока миллисекунд заменой на дот.нет мы получили полторы минуты десять миллисекунд. Профит!

Reaper ★★
()

Прошу помочь PHP-быдлокодеру стремящемуся к прекрасном :)

Стремись лучше к целесообразному. А освободившееся время и заработанные деньги трать на азартные игры и распутных женщин.

r_asian ★☆☆
()
Ответ на: комментарий от tyler19

Но потом проникнулся идеологией и увидел реальные преимущества (а не абстрактную красоту как в Ruby). Вообще ruby красив для абстрактных целей (поковыряться, полюбоваться) но не для работы, Python - рассчитан на реальные задачи.

Зомби уже и до ЛОРа добрались…

Deleted
()
Ответ на: комментарий от tyler19

Дурь пишешь тут ты в виде:

Вообще ruby красив для абстрактных целей (поковыряться, полюбоваться) но не для работы, Python - рассчитан на реальные задачи.

Deleted
()
Ответ на: комментарий от Deleted

Это вовсе не дурь а констатация факта. Руби быдлокодеры давно уже превзошли php быдлокодеров. Руби фреймвёрки дырявые, в том же рейлсе чуть ли не ежемесячно всплывает серьёзная проблема с безопасностью. У рубистов модно городить трухлявую систему из огромного количества компонентов от различных разработчиков сомнительного качества. Если я напишу систему на руби + рейлс мне будут сниться кошмары как я зайдя на тот же linux.org.ru снова читаю об уязвимости этого дырявого говна на первой странице. Если же я это сделаю на Python + Pyramid буду спать спокойно. Сравним:

http://www.ruby-lang.org/en/security/

http://www.python.org/news/security/

tyler19
()
Ответ на: комментарий от tyler19

Успокойся, фанатизм из ушей сейчас полезет :}

Deleted
()
Ответ на: комментарий от tyler19

Питон - ребенок рассуждает о фреймворках и языках программирования.

рельсогосподин

s9gf4ult ★★
()
Ответ на: комментарий от VirRaa

Все верно, или в вашей Вселенной PHP работает быстрее JIT компилированных языков, работающих на скорости 90% от С++?

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Все верно, или в вашей Вселенной PHP работает быстрее JIT компилированных языков, работающих на скорости 90% от С++?

Я к тому, что ту нагрузку, что у ЛОРа, спокойно выдержит PHP, легко.

VirRaa ★★★
()
Ответ на: комментарий от baverman

Я честно скажу что не смог разобраться как отфильтровать. Пробовал в формочке снизу под «Download as CSV». Там пункты Sort On в 2 экземплярах и Group On в 2 экземплярах. Выбирал Type и там и там а где выбирать «Security/Crash»?

tyler19
()
Ответ на: комментарий от vertexua

Все верно, или в вашей Вселенной PHP работает быстрее JIT компилированных языков, работающих на скорости 90% от С++?

Вы сильно преувеличиваете. Java раз в 10 медленнее C++ и жрёт раз в 100 больше памяти. Вот proof: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=j...

tyler19
()
Ответ на: комментарий от VirRaa

Или приведи конкретные аргументы или иди лесом. В PHP'шном OOP всё отстойно начиная от синтаксиса и огромного количества нелогичных ограничений и заканчивая резким падением производительности.

tyler19
()
Ответ на: комментарий от tyler19

В PHP'шном OOP всё отстойно начиная от синтаксиса и огромного количества нелогичных ограничений и заканчивая резким падением производительности.

Маленький мой дружочек, какой же ты смешной. Во-первых, обсираешь ты, соответственно приводи аргументы сам. Во-вторых, если тебя так бесят ограничения в PHP ООП, как же ты живёшь без приватных методов (один из пастулатов ООП - инкапсуляция) в питоне?

VirRaa ★★★
()
Ответ на: комментарий от VirRaa

Мне насрать на теоретические пастулаты, больше интересует практическое удобство. И вот OOP в PHP крайне не удобный. Регулярно натыкался на ограничения которые кроме как недоработкой не назовёшь (т.е. смысла в них нет). Как только снова столкнусь постараюсь не забыть и отписаться сюда.

tyler19
()
Ответ на: комментарий от tyler19

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

Тебе насрать, просто потому что ты мудак и не понимаешь что такое ООП. Вот и всё. Несешь чушь про то, что натыкался и ни одного примера не привёл. Клоун.

VirRaa ★★★
()
Ответ на: комментарий от vertexua

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

Vit ★★★★★
()
Ответ на: комментарий от alix

Я бы еще Node.js помацал

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

tyler19
()
Ответ на: комментарий от VirRaa

(один из пастулатов ООП - инкапсуляция)

приватных методов

Facepalm. Поначитаются всякого бреда и идут размахивать «постулатами».

baverman ★★★
()
Ответ на: комментарий от baverman

Facepalm. Поначитаются всякого бреда и идут размахивать «постулатами».

В центре ООП находится понятие объекта. Объект — это сущность, которой можно посылать сообщения, и которая может на них реагировать, используя свои данные. Объект — это экземпляр класса. Данные объекта скрыты от остальной программы. Сокрытие данных называется инкапсуляцией.

И, да, Подскажите годную альтернативу PHP/MySQL для PHP-быдлокодера со стажем. (комментарий)

VirRaa ★★★
()

требуется эффективная надёжная среда разработки веб приложений

Ruby on Rails + GIT + Postgresql

Alve ★★★★★
()
Ответ на: комментарий от VirRaa

Объект — это сущность, которой можно посылать сообщения, и которая может на них реагировать, используя свои данные.

Золотые слова. Только при чем тут private?

baverman ★★★
()
Ответ на: комментарий от VirRaa

Хы-хы, да, до Говоруна тебя как муравью до Бреста.

Маленький вопросик. Зачем нужен private, если он легко обходится?

baverman ★★★
()
Ответ на: комментарий от Alve

Ruby on Rails + GIT + Postgresql

Вы что то путаете. Пойдём по пунктам:

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

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

tyler19
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.