Ну, предложите альтернативные языки для реализации.

> Сама идея совмещения разметки с логикой, изначально реализованная в php/jsp/asp/т.п. оказалась неудачной.

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

При работе с AJAX/COMET нужно генерировать много мелких строчек на JS. Так вот, в виде чистого JS с подстановками, в духе моих макросов для SQL, это будет выглядеть более читаемо, чем в виде скобочек, я в этом убедился на практике. Например, потому, что в JS можно использовать разные виды кавычек, а в лиспе - нет.

Да, я кстати забыл ещё об одной мелочи: отлов синтаксических ошибок.
Если я пишу select * from zoo (вместо foo), я получаю ошибку синтаксиса. SQL говорит мне конкретное место в тексте, где произошла ошибка. Когда у меня исходный код является инлайном в лиспе, я могу точно определить место _своего_ исходника, где находится ошибка. И я могу это автоматизировать, так что, нажатием одной кнопки сразу попадаю на место ошибки.

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

> Ну, предложите альтернативные языки для реализации.

В данный момент альтернативы C++ для многих задач просто нет.

> При работе с AJAX/COMET нужно генерировать много

мелких строчек на JS.

Хм, зачем?

> > При работе с AJAX/COMET нужно генерировать много

мелких строчек на JS.

Хм, зачем?

Я не помню, это было 2 года назад. Я не занимаюсь вебом. Видимо, для обработки событий видгетов.

А, ну так нужно и говорить, что не при работе c AJAX/COMET, а во всяких извращениях типа SymbolicWeb ))

Только я не понял одного- можно ли инлайнить эти шаблоны прямо в исходник Хаскеля?

Можно. И подставлять в них функции Haskell тоже можно.

> Не знаю про веб, но смесь SQL и клиентского языка - это вещь вполне осмысленная.

Ну да, то-то столько ORM'ов понаворатили...

Самый лучший LISP - это Tcl.

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

> И кстати, может хоть кто-нибудь из лисперов или хаскеллеров в

кои-то годы нам покажет хоть строчку полезного кода

Да устали показывать то уже. Кстати, что вы считаете «полезным кодом»?

> В данный момент альтернативы C++ для многих задач просто нет.

Ещё нет альтернативы C и Perl.

> Ещё нет альтернативы C и Perl.

Ну про C то что говорить, тут всё очевидно. А вот Perl имеет большой исторический багаж и его трудно выкинуть (да и зачем?), но вот писать новые системы на Perl никакой необходимости нет. Его можно использовать, а можно и нет.

Просто намедни понадобился скрипт, удаляющий коментарии внутри кода на C. Найденные скрипты для sed содержали ошибки, а код на perl работал без ошибок. Хотя надо будет вернуться к этой задачке, да на C переписать :)

> Хотя надо будет вернуться к этой задачке, да на C переписать :)

Лучше на Python или на Ruby или вообще на любом высокоуровневом языке.

Вот они, кстати, для сравнения - Perl, Sed. Код на Perl заметно короче.(Взято со stackoverflow и ещё откуда-то)

> Лучше на Python или на Ruby или вообще на любом высокоуровневом языке.

Сторонник мнения, что если задача типовая, то рано или поздно должна быть переписана на C.

> если задача типовая, то рано или поздно должна быть переписана на C.

Зачем?

В этом примере - для экономии ресурсов цпу. Если файлов много и они большие...
Но если разница с Perl получится незначительная, то скрипт предпочтительнее, т.к. не требуется сборка.
Иными словами, этот пример - слишком простая задача для того, чтобы здесь потребовался слабо типизированный язык.

Вы экономите ресурсы цпу на задаче удаления комментариев из кода на С? Вряд ли мы сможет понять друг друга.

Есть такие люди которые всё бы рано или поздно переписали бы на C. В основном потому что язык C они понимают, а все остальные языки им кажутся грамоздкими и медленными. С другой стороны программа на perl, python, ruby тянент за собой огромный интерпретатор (иногда конкретной версии) и кучу модулей с установкой которых могут быть проблемы. В этом плане бинарная дистрибьюция как-то понадёжнее.

Ну это пример, видимо плохой... =)
Цель задачи - построить дерево зависимостей заголовочных файлов, если файлов много, а задача не одноразовая, то разница будет заметной.

> если файлов много, а задача не одноразовая,

то разница будет заметной.

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

А какой из языков слабо типизированный C или Perl?

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

Bash :)

И как понять, какую часть кода возможно потребуется модифицировать? Вообще, это же преждевременная оптимизация. ИМХО, решение переписать код на C или сразу писать код на C должно приниматься под мощным давлением суровой реальностью, требующей более высокой производительности, либо удешевления, но не в результате абстрактных рассуждений.

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

Но если задача совершенно новая и её трудно разделить на подзадачи, то, вероятно, все эти требования уйдут на второй план.

> В идеале... Энергопотребление, отзывчивость...

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

>Удаление коментариев - типовая задача
Вы не поверите, но мне такая задача ни разу в жизни не встречалась. Можно юзкейс для примера?

Построение дерева зависимостей файлов исходного кода.

Что круче?

Яйцо

Что круче: Лисп или Хаскелль?

Ну что? За пятнадцать страниц наверное уж решили что лучше?

> За пятнадцать страниц наверное уж решили что лучше?

К обсуждению этого вопроса вроде ещё не приступали. А что, интересно?

Что круче: вилка или топор? Что-то на лоре в последнее время слишком много идиотов с идиотскими вопросами. Идиотов, которые рассуждают о «крутости» языка по его популярности.

Ну что? За пятнадцать страниц наверное уж решили что лучше?

Я пока решил, что Лисп круче.

Гораздо больше идиотов, которые рассуждают о том, какие на ЛОРе идиоты, совершенно не ориентируясь в ситуации.

А кто-то сомневался? Ты мог решишь что-то другое? :)

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

А кто-то сомневался? Ты мог решишь что-то другое? :)

У человечества сложилось два основных взгляда на программирование: одни говорят, что это почти математика, другие - что хакерство (такая штука for fun). Так вот, я - не математик :)

давление внешней среды, которое слабее год от года

Вы знаете про закон Вирта? :)

Лисп вне сомнения круче, но Хаскель пока крут тем, что у него есть полторы нормальных реализации, в отличие от кучи реализаций лиспа (и особенно схемы).

> Хаскель пока крут тем, что у него есть полторы нормальных реализации,

в отличие от кучи реализаций лиспа (и особенно схемы).

Что-то не понял логики. Для CL есть две отличных open-source реализации (SBCL и ClozureCL) и две отличных коммерческих (со всеми вытекающими).

Наличие малого числа _основных_ реализаций — это большой плюс. Как я уже говорил — посмотрите на Схему — куча реализаций и в каждой свои костыли для всяких реальных задач.

Не хочешь же ты сказать, что математиков становится все больше и больше?

> Кстати да, только вчера думал, что давненько на ЛОРе не было лиспосрача, а тут бац

mv всегда к вашим услугам. Правда на этот раз толстовато ИМХО.

По теме: Конечно же Хаскель круче. Алгебраические типы данных, монады, отсутствие деструктивных операций - что может быть круче? А Лисп (Common Lisp, с другими близко не знаком) - обычный практичный язык на опробованных десятилетиями идеях, доведённых до ума. Совершенно ничего крутого. Поэтому в разработке софта лучше CL.

> По теме: Конечно же Хаскель круче. Алгебраические типы данных, монады, отсутствие деструктивных операций - что может быть круче? А Лисп (Common Lisp, с другими близко не знаком) - обычный практичный язык на опробованных десятилетиями идеях, доведённых до ума. Совершенно ничего крутого. Поэтому в разработке софта лучше CL.

И этот человек жалуется на толстоту.

Всё правильно сказал, чего тебе не нравится?

в точку