Некоторые сумбурные мысли о выборе Web-фреймворка и языка программирования

 
+
-
edit
 

Balancer

администратор
★★★★★
Django Go IT Play Framework Python. Java Revel RoR Ruby web компьютеры фреймворки
Некоторые сумбурные мысли о выборе Web-фреймворка и языка программирования

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



Поскольку программирование в стиле Perl/PHP (поменял исходник, переключился в браузер, нажал F5, видишь результат) мне давно импонирует, то и к фреймворкам я присматривался «скриптовым». В первую очередь, конечно, Django и RoR.

Присматривался к ним не первый год, на Django даже один проект делал (но забросил — очень уж неэффективно писать на чистом Django). Но перейти так и не решился. По сути получается замена шила на мыло.



 
RoR тут мне вообще не нравится. Довольно медленный и очень, очень капризный. Ну что за проект, при постановке которого по инструкции с оф. сайта получаем на первом запуске тонну Depricated. Что за язык, в котором постоянно ломают обратную совместимости. Поддержка того же Redmine, написанного на RoR — это ад какой-то. Ну и то, что Ruby является наследником Perl тоже не улучшает отношения к нему. Конечно, тут всё не так плохо, как в Perl, но постоянно возникает желание писать в write-only стиле. В общем, не пошло.



Django гораздо приятнее. Довольно строгий Python в роли платформы. Относительно высокая производительность. Но... после практических экспериментов сделал вывод о размене шила на мыло. Не смотря на некоторый выигрыш в производительности, затраты на реализацию фреймворка на новой платформе за обозримое время не окупятся.

Так что, в итоге, смена платформы и не произошла.



Однако, в прошлом году, я столкнулся с интересным проектом — Play Framework. Это классический Web-фреймворк (MVC, роутинг, ORM и прочее) на JVM. Первая версия работала с Groovy, вторую переделали на Java и Scala. Интересен тем, что не смотря на то, что фреймворк реализован на «компилирующих» языках, работа под ним идёт в духе PHP. Поменял исходник, обновил страницу — класс автоматом перекомпилируется и обновится. Скорость разработки становится очень высокой. При этом мы имеем всю мощь JVM. От довольно высокой производительности до широчайшего спектра библиотек.

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



Недавно столкнулся ещё с одном весьма интересным решением — фреймворком Revel. Идея этого движка была взята с Play (на оф. сайте так и пишут), но реализован он был на платформе Go. Сперва я оценил очень высокую производительность. Позже познакомился с самим Go. Язык неплох и интересен. Хотя и своеобразен. В минусах — намного меньшее количество библиотек, чем на JVM. Даже ORM отсутствует из коробки (хотя прикручивается из сторонних библиотек). В плюсах высокая скорость компиляции (про скорость работы я уже писал), быстрый старт виртуальной машины, намного более экономное отношение к памяти, чем на JVM.

В общем, я всерьёз задумался о переходе на Go.

Но, вот ирония судьбы. Стоило вчера поднять на ЛОРе эту тему, как объявился старый знакомый с предложением возобновить работу с одним старым-старым Java-based проектом. При чём мне реально интересно им заняться. И в этом случае вариант с Play Framework получает серьёзный бонус — мне не придётся распыляться на два фронта. А идеологию свою я всё равно планирую реализовывать и в этом проекте.

Так что, видимо, всё же, Play Framework? :)


// Транслировано с balancer-it.blogspot.com
 
RU Gudleifr #05.08.2016 10:11  @Balancer#12.03.2013 13:45
+
-
edit
 

Gudleifr

втянувшийся

Делая нечто подобное, быстро пришел к тому, что никакая фиксация языка не спасет. Процесс циклический. И простота "машины" (у меня чисто HTML-Perl) это позволяет.

Пусть у нас в наличии некоторая OC. Уровень ее нам не важен: может, полуразобранный Спектрум, может, MS Excel... Пусть это будет, даже, не ОС в полном смысле слова, для примера не важно. Нам важно, чтобы была "машина", управляемая нашими командами и для которой мы мечтаем писать программы. Для определенности/понятности возьмем, например, MS-DOS. Теперь начнем "изобретать программирование".
0) Программирование нулевого уровня - ручной ввод команд одна за другой. В MS-DOS мы так и делали. Скопировать файл, запустить игру, почистить директорий...
1) Когда мы увидели, что набирать по одной команде лениво, мы начали писать командные файлы (скрипты) - несколько команд "упакованных в одну", возможно даже с какой-то примитивной логикой "если ошибка, то...".
2) Покопавшись в компьютерных журналах, мы узнали, что командные файлы можно научить не тупо выполнять "что прошито", но и спрашивать у пользователя "чего изволите?". Правда, изначально в DOS не было никаких средств для обращения к оператору, но их можно было легко создать или спереть готовые на стороне, не суть. Главное, что мы научились писать, как определил Мур "Программы с вводом".
Пропустим следующий этап и сразу перейдем к (4):
4) Мы стали системными программистами, и можем написать свой BASIC - систему, которая позволяет нам писать программы не на убогом командном языке MS-DOS, даже не знающем, что наш IBM PC может выводить на экран графику, а на крутой машине, умеющей работать с массивами и строками, бибикать ноты и рисовать цветные линии... По сути, мы возвращаемся к (0), но уже на новом технологическом уровне - можем вводить мощные команды, писать продвинутые скрипты-программы и т.д.
Теперь заткнем дыру:
3) Мы ищем способ не только увязывать команды в скрипты, но и создавать новые простые команды (а, заодно, и способы обмена информацией и передачи управления между ними). Т.к. результатом (4) будет новый язык (проблемно-ориентированный), то есть большое искушение назвать то, что, мы делаем на этом этапе, FORTH.
Однако, как ни назови, несомненно одно: нам придется залезть внутрь нашей исходной MS-DOS машины. И начать писать не на исходном языке команд command.com, а в кодах (например, в debug.com). И большая часть нашего BASIC-интерпретатора будет в этих кодах и написана (хотя он и сможет обращаться к MS-DOS, например, для работы с файлами). В случае же использования FORTH-метода "отскок в коды" будет совсем невелик - всего десяток основополагающих слов. Но, все равно, будет.
 
 47.047.0
RU спокойный тип #12.11.2016 10:21
+
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★☆
а вот интересный вопрос, существуют какие-то удобные средства разработки для питон + фласк ?
более удобные через mcedit :D

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

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

(если в двух словах то начиналось как нагрузочные скрипты для SIP свитча и SIP атс (фронта и бэка) с мониторингом, а теперь из мониторинга какой-то медиа архив получается для SIP систем, скоро они уже захотят свой поисковик по медиаданным делать)
 49.049.0
Это сообщение редактировалось 12.11.2016 в 10:29
RU Balancer #12.11.2016 10:26  @спокойный тип#12.11.2016 10:21
+
-
edit
 

Balancer

администратор
★★★★★
с.т.> а вот интересный вопрос, существуют какие-то удобные средства разработки для питон + фласк ?

Вот тут не советчик. Я под Питоном только с Django работал и то только в одном проекте — не понравилось :)
 44
RU Gudleifr #13.11.2016 15:52  @спокойный тип#12.11.2016 10:21
+
-
edit
 

Gudleifr

втянувшийся

с.т.> ... питон ...
с.т.> ... проект явно перерос размер скрипта ...

Для Python это проблема. Пока скрипт маленький, все замечательно, вплоть до изобретения своих парадигм и нетривиальных абстракций. Но, с увеличением размеров, количество необходимой ОО-обфускации и паразитных побочных эффектов растет экспоненциально. Показать, что обернутый в три и более фантиков объект имеет требуемое поведение, практически невозможно.

Единственный выход - изобрести свои проблемно-языковые абстракции, связывающие python-машину и машину-решающую-нужную-задачу. Связывающие за одно действие. Для этого, кстати, универсальный редактор удобнее IDE.
 49.049.0
Это сообщение редактировалось 14.11.2016 в 13:59
RU Balancer #13.11.2016 17:29  @Gudleifr#13.11.2016 15:52
+
-
edit
 

Balancer

администратор
★★★★★
с.т.>> ... питон ...
с.т.>> ... проект явно перерос размер скрипта ...
Gudleifr> Для Python это проблема.

Питон как язык не мешает писать хорошие декомпозированные приложения. Не идеален, но и не плох. Тут, скорее, проблема в принятых в коммьюнити Питона подходах. Народ любит писать монолитно, что хорошо для скрипта, но плохо для большого проекта.
 54.0.2840.8554.0.2840.85
RU спокойный тип #18.11.2016 09:14  @Balancer#13.11.2016 17:29
+
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★☆
Balancer> Питон как язык не мешает писать хорошие декомпозированные приложения. Не идеален, но и не плох. Тут, скорее, проблема в принятых в коммьюнити Питона подходах. Народ любит писать монолитно, что хорошо для скрипта, но плохо для большого проекта.

это не народ любит - это китайце-индусы так хотят
написал два отдельных демона плюс рестуфл апи (небольшое) на WSGI под апач - просто , элегантно местами даже, модульно, никаких классов и прочего усложнения ради усложнения - чисто простые скрипты-демоны в Unix-way

нет говорят, не хотим апач, не хотим отдельно, хотим скрипт который будет ещё из себя по httр запросы принимать )) что бы не конфигурить кучу всего а один скрипт поставить из репо и жить припеваючи )))

пока сошлись на двух демонах, один из них будет gunicorn-а прямо из себя запускать - но уже определённо не так хорошо получается как могло бы
для них проблема даже настроить клиентскую и серверную часть согласованно , в конце концов просто пришлось запилить один конфиг который обе части понимают
 49.049.0
RU Balancer #18.11.2016 09:40  @спокойный тип#18.11.2016 09:14
+
-
edit
 

Balancer

администратор
★★★★★
Balancer>> Народ любит писать монолитно
с.т.> это не народ любит - это китайце-индусы так хотят

А они уже не народ? :)
 44
RU спокойный тип #18.11.2016 09:46  @Balancer#18.11.2016 09:40
+
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★☆
Balancer>>> Народ любит писать монолитно
с.т.>> это не народ любит - это китайце-индусы так хотят
Balancer> А они уже не народ? :)

это не пишущий народ ))) это уже заказчики (типа производители sip оборудования третьего эшелона в моём случае)
 49.049.0

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru