Mojolicious 1.0

До Perl4 включительно так и было. Но Perl5 был полностью переписан и задумывался изначально как язык общего назначения.

Переписать что-то полностью не значит в корне изменить сам ЯП. перл как был клоном awk, таким же и остался в 5ой версии, таким же остался и в 6ой.

>>потому что свободу программиста ограничивают, начиная с Алгола60.

Вот поэтому он и рипнулся,

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

а фортран и лисп всё ещё живут =)

Те Фортран и Лисп тоже умерли. Кстати, Фортран очень сильно ограничивает программиста.

>> У Перла есть XS

луа изначально писался для встраивания в программы на С и наоборот. Посмотрел тут биндинг от луа к лдап - проще некуда.

Разница в сложности биндинга к C у Lua и Perl не настолько критична. Ибо и там и там просто. У Lua проще, но это не важно.

Вот разница в сложности биндинга к C++ дает преимущество Lua, как встраиваемому языку.

Но, как я понимаю, здесь множество не будет считать это достоинством. По этому и не будут считать использование Lua обоснованным.

Когда-то давно, когда программисты были инженерами, а не ПТУшниками, прочитавшими «программирование для чайников за 15 минут», это называлось гибкостью языка программирования. А теперь, видите ли, если в ЯП не встроены защиты от быдлокодеров, и свобода программиста не ограничивается специально, то это называется поощрением плохого кода

Когда то давно кодинг не был широко распространённой индустрией, можно было работать над совершенством своего продукта годами: и объёмы кода были ничтожными, и технические средства не позволяли городить большие проекты. Сейчас темпы развития айти индустрии в разы выше.

> А если в самом фреймворке выносить в отдельный конфиг, то это не всегда полезно.

Зато на деплойменте-то как хорошо...

Гибкость же страдает.

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

> когда фреймворк утфные символы пополам режет, неправильно считает количество символов в строке, или не может поменять окончания или даты, то все совсем кисло...

Ох, это детский сад какой-то, а не фреймворк.

Затем, что во первых, на каждый чих либу не найдешь, да и зависимости в определенный момент начинают сильно досаждать при деплое.

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

> и свобода программиста не ограничивается специально, то это называется поощрением плохого кода...

Именно так это и называется. Если бы в перле не было с этим серьёзных проблем, на CPANе (а то и прямо в дистрибутиве, один CGI.pm чего стоит!) не болтались бы тонны плохо поддерживаемого дерьма.

> Ну для меня это например обработка нуклеотидных/аминокислотных сиквенсов - парное выравнивание, преобразование из одного алфавита в другой, поиск повторов (в том числе и вырожденных) и тд

И чем перл (именно как язык+stdlib, а не как сторонние библиотеки, написанные под данный случай) помогает Вам в решении этой задачи?

А чем еще должен заниматься веб-фреймвор как не генерацией и парсингом текста?

Господь с Вами. Веб-фреймворк - это прежде всего средство построения приложения, функционирующего в достаточно специфичной среде:

* относительно дорогие запросы и ответы;
* предполагаемое наличие большого количества параллельных и, как правило, независимых пользовательских сеансов с плохо контролируемым временем жизни;
* как следствие, желательность использования stateless моделей обработки данных;
* требуемая в большинстве случаев гибкость и изменяемость кода, чтобы поспевать за изменениями в постановке задачи;
ну и так далее, про это стопицот книжек написано и в два раза больше фреймворков создано.

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

Кстати, учитывая «промо»-стиль оформления новости, где гипножаба? :)

Mojo::Server::Hypnotoad - ALL GLORY TO THE HYPNOTOAD!

>Но, как я понимаю, здесь множество не будет считать это достоинством. По этому и не будут считать использование Lua обоснованным.

вот это вот вообще не аргумент.

>Никогда не видел, как от тривиальной смены версии в номере релиза что-нибудь отваливается? :-)

Нет, просто я никогда не меняю версии на продакшне. Кроме минорных релизов, и то, если _действительно_ нужно (исправлен баг фреймворка etc). Изначально делаю копию и далее работаю только с ней.

ЧЯДНТ?

Документация рекомендует использовать джангу из транка, если что.

>* как следствие, желательность использования stateless моделей обработки данных;

Тихонечко хаскел, хаскел. Или добавь немножко скалы...

* требуемая в большинстве случаев гибкость и изменяемость кода, чтобы поспевать за изменениями в постановке задачи;

луа, луа.

>Зато на деплойменте-то как хорошо...

если фреймворк сторонний, то да.

А если нужна интеграция или гибкая настройка. Например, загрузил модуль - появился урел. Нет модуля - нет урла?

Имхо в идее «конфиг, как программа» тоже есть свои большие преимущества.

И много где ее с успехом используют.

>> Но, как я понимаю, здесь множество не будет считать это достоинством. По этому и не будут считать использование Lua обоснованным.

вот это вот вообще не аргумент.

Согласен отсутствие достоинств это не аргумент. Это отсутствие аргументов ЗА использование.

А если их нет, то зачем?

>> и свобода программиста не ограничивается специально, то это называется поощрением плохого кода...

Именно так это и называется.

Если ты не умеешь писать нормальный код, то тут хоть вообще всё ограничь и выкинь из ЯП всё что можно, а ты всё равно умудришься говнокода нагенерировать.

Просто не надо смешивать ниши учебных ЯП и профессиональных. В учебных от ограничений польза есть, они школоту по рукам бьют при первой же возможности, а для программиста это лишняя помеха.

>Ох, это детский сад какой-то, а не фреймворк.

ха. сколько таких недофреймворков в топах сидит...

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

Чудес не бывает. Или это скриптовые и как следствие медленные фреймворки и жаба, что синоним жирная.

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

Я разворачивал хаскелную платформу и то получил гемора, а там вообще все сделано очень и очень надежно...

Луашка, слава богу, очень простая. Вся сборка укладывается минут в 15, но ты глянь что эти упыри делают с деплойментом в том же спутнике http://sputnik.freewisdom.org/ . Это просто песдец, как надо все запутать..

Или проект kepler http://www.keplerproject.org/. Песенка. модули wsapi и wsapi-fcgi имеют одинаковые исходники (а зачем вообще было тогда wsapi-fcgi?). В федоре собрали wsapi, но забыли скомпилировать сам модуль и собрать зависимости (просто положить пару луашных скриптов). В итоге платформа в федоре вообще нерабочая.

А ты говоришь, стопицот тулз для деплоймента...

>Mojolicious даёт разработчику возможность отказаться от монструозных веб-фреймворков с излишне сложной структурой, уродливым API и кучей зависимостей

Архитектура MVC

Не может быть.

За epoll спасибо.

И причём здесь вёб?

> Если ты не умеешь писать нормальный код, то тут хоть вообще всё ограничь и выкинь из ЯП всё что можно, а ты всё равно умудришься говнокода нагенерировать.

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

Не, на самом деле, где-то с 2005 года (может, чуть раньше) в общем количестве модулей на CPANе стали заметны те, где используется единые соглашения об устройстве ООП, генерации и обработки ошибок и так далее. То есть, можно говорит, что даже при отсутствии в языке/среде ясного и чёткого стайлгайда, как решать те или иные типовые задачи, человеки способны в итоге договориться до чего-то сравнительно приличного. Правда, заняло это 10+ лет...

> жаба, что синоним жирная.

Я не знаю, что такое «жирная». Если это сервис для 100500 клиентов, то вполне приемлемым является вариант, когда этот сервис обслуживается кластером, требуемые для этого механизмы есть из коробки, как меня уверяют.

Если это сервис для ограниченного числа клиентов, то в наличие имеются и вполне даже миниатюрные решения.

Ну и да, мне казалось, что не любителям Хаскеля рассуждать о скромности в запросах по памяти :)

По оф. сайту сразу понятно какие изящные и компактные решения ребята умеют делать. У меня даже главная страница тормозит при скроллинге.

> Тихонечко хаскел, хаскел. Или добавь немножко скалы...

«Так, мальчик, положи экспонат на место, отойди, не мешай работать».

P.S. Нет, я не против того, чтобы необходимо использовать верифицируемые методики. Но исходный разговор был про парсинг текстов и выдачу результатов, что совсем в стороне от верификации и создание приложений.

>> У меня даже главная страница тормозит при скроллинге.

лор-эффект

>Где-то рассказывали, что lisp продолжительное время был второй по популярности. Java тоже скорее выбивается. Pascal не совсем подходит, он ведь распространен, правда в школах и немного в вузах.

Из всех перечисленных языков внятную стратегию развития имел лишь Паскаль да и тот изрядно расширен был хаками борландовскими сделавшими из паскаля язык пригодный для системного программирования. Лисп популярен никогда не был, он всегда был в той же нише что и ранний паскаль - язык для академиков и университетов

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

Кстати, недавно написали http://check-host.net на Mojolicious как раз. Классный фреймворк, попробуйте.

Это хороший ответ на вопрос, что именно в perl позволяет Вам анализировать сиквенсы лучше, чем в других языках.

>Ржу. Ну и какое это отношение имеет к кодингу?

Отсутствие ассоциативного мышления верный признак низкого интеллекта

>И чем перл (именно как язык+stdlib, а не как сторонние библиотеки, написанные под данный случай) помогает Вам в решении этой задачи?

Навскидку: дефолтные переменные ($_ и собратья), оперирование лексемами а не строчками кода (см задачу про переворачивание текста в книге с ламой, там все реализуется тремя операторами в одну строчку), выполнение регэкспов непосредственно в выражении без всяких компиляций или создания объекта, не нужно заморачиваться с типами, хеши

> Заметил такую особенность - си привлекает людей неспособных увидеть за деревьями леса. Видят одно дерево, два дерева, кустик между ними а леса как целого не видят.Тактики а не стратеги.

Зато перл — это когда после намечания стратегии придумывается строчка кода с использованием какого-нибудь не нужного никому, но клевого оператора >=^^=< «крабе», а потом все это обязывается тучей костылей, чтобы использование этого оператора хоть как-то обосновать.

Не при загрузке. Именно при скроллинге. Это из-за модной несдвигаемой шапки сайта.

Отсутствие ассоциативного мышления верный признак низкого интеллекта

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

Логика шизофреника обычно непротиворечива что делает невозможной точную диагностику. У тебя же полное непонимание того что могут быть другие способы мышления кроме квадратного и линейного

> Не при загрузке. Именно при скроллинге. Это из-за модной

несдвигаемой шапки сайта.

Пора бы тебе свой PentiumII на мусорку отнести, может бабушки подберут.

> Не при загрузке. Именно при скроллинге. Это из-за модной несдвигаемой шапки сайта.

Короче выкинь свой моп, все ок работает.

> а поконкретней, в чем RoR тормоз, и ваш опыт работы с ним? http://fatbrother.livejournal.com/4556.html

> Из всех перечисленных языков внятную стратегию развития имел лишь Паскаль

О былой популярности лиспа вне академических кругов намекают lisp Machines (вроде, по меркам того времени, их было не то чтобы много, но прилично), да и был пик интереса к AI, что тоже способствовало. Если не ошибаюсь, чем-то лиспоподобным расширяется autocad, [максима как очевидный пример], мoжно вспомнить о схеме, которая встречается, скажем, в гимпе, а иногда (в качестве языка для обучения) в западных вузах.

Хотя, мне что-то подсказывает, что вы несколько исказили первоначальную проблему относительно хаков: хак ведь хаку рознь, и важно, скорее как их много и насколько негативно они влияют, а не иделистическое «присутствуют ли они в языке».

> Ну и да, стоит помнить о том, что Play! писан джавистами, уставшими от прелестей J2EE и решившими слепить свой велосипед, чем-то неуловимо напоминающий Django и RoR. И что это не вполне Java.

И чем же именно оно не вполне Java?

> Что делать?
Добавь:

check_certificate=no

>Я не знаю, что такое «жирная». Если это сервис для 100500 клиентов, то вполне приемлемым является вариант, когда этот сервис обслуживается кластером, требуемые для этого механизмы есть из коробки, как меня уверяют.

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

Если это сервис для ограниченного числа клиентов, то в наличие имеются и вполне даже миниатюрные решения.

по жабски да. сотня метров ОЗУ и камень на три гигагерца - верх миниатюрности.

Ну и да, мне казалось, что не любителям Хаскеля рассуждать о скромности в запросах по памяти :)

при компиляции он жрет память гигами. но при работе во фреймворках я такого не замечал.

.S. Нет, я не против того, чтобы необходимо использовать верифицируемые методики. Но исходный разговор был про парсинг текстов и выдачу результатов, что совсем в стороне от верификации и создание приложений.

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

>хак ведь хаку рознь, и важно, скорее как их много и насколько негативно они влияют

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

>клевого оператора >=^^=< «крабе»

крабе нет но есть кораблик, космический. Очень удобен в операциях сравнения «больше, меньше или равно»

>крабе нет но есть кораблик, космический. Очень удобен в операциях сравнения «больше, меньше или равно»

очередной кривой хак. Попытка перенести правила сравнения строк на числа.

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

Просто офигеть, какая суперпричина и каков масштаб элегантности решения....

Ну, когда (любой) результат выдаётся на клиента путём выбрасывания РантаймЭксепшна - это как бы не совсем то, что описано у Дж.Гослинга как стандарт программирования на Java.

У меня человек когда в первый раз с этим столкнулся, долго не мог понять, а чего это у него после render() никакой код не выполняется, ему и в голову не приходило такое, м-м-м, причудливое решение по передаче управления. Потом-то, конечно, разобрались, и место в коде наши (play.mvc.results.*), и в доках, кажется, прочли, но осадочек остался...

> умственно убогие вообще не понимают что к чему а те кто понимает пруцца

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

очередной кривой хак. Попытка перенести правила сравнения строк на числа

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

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

> Ну, когда (любой) результат выдаётся на клиента путём выбрасывания РантаймЭксепшна - это как бы не совсем то, что описано у Дж.Гослинга как стандарт программирования на Java.

Ну мало ли что Гослинг сказал. На плюсах тоже бывают такое напишут, что волосы стают дыбом и выпадают. И ничего, плюсами оно быть не перестает. Просто товарищам следует поучиться у французов, как обращаться с этим животным. Все-таки RuntimeException не для того придуман был.

>>Я не знаю, что такое «жирная». Если это сервис для 100500 клиентов, то вполне приемлемым является вариант, когда этот сервис обслуживается кластером, требуемые для этого механизмы есть из коробки, как меня уверяют.

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

Это ты про свои успехи в области Java пишешь? Тогда понятно. Поздравляю, особенно если инъекции пошли тебе в карман.