![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Небольшой ответ на ответы на мои "наезды" на хаскель
Сейчас я опишу одну из главных причин по которым я недолюблюваю Ъ ф.п, и люблю CL.
Понимаете, рассуждая о развитии IT-индустрии, можно провести аналогию с классической промышленностью.
В истории классической промышленности были периоды когда всё делали единично и ручками. Я мог бы сравнить такие периоды с ранним развитием IT. Со временами расцвета UNIX или DOS. С языками вроде Си.
Потом были периоды рабовладельческого строя и раннего капитализма, когда любую задачу закидывали необходимым количеством человеков. Я бы сказал, что сейчас в IT-индустрии как раз такой подобный период, со всеми этими Java и PHP.
Но в итоге, во всех развитых странах промышленность пришла к автоматизации. И производит продукты лучше, быстрее и качественнее, чем когда-либо.
И IT-индустрию ждет когда-нибудь то же самое, то есть массовая автоматизация, программы которые пишут программы(понимаете, к чему я клоню, да?), и это неминуемо.
Я смотрю на языки функционального программирования, вроде хаскеля, как на, ну не знаю, алмазные лопаты. Выглядят красиво, конечно, прочностью обладают неслабой, но что они могут сделать против таких детищ автоматизированной промышленности, как отбойные молотки и экскаваторы?
Я не вижу, как ф.п. может помочь с если уж не уменьшением, то хотя бы со сдерживанием растущей сложности софта. Я вижу ф.п. как модный фетиш, и ничего более, и поэтому время от времени на него наезжаю, т.к. бессмысленные фетиши меня раздражают, т.к. бессмысленные фетиши это может быть круто в дизайне шмоток, например, но не в инженерии.
Кстати, скоро напишу на хабр статью о макросах и метапрограммировании в лиспе, как только продумаю её.
Понимаете, рассуждая о развитии IT-индустрии, можно провести аналогию с классической промышленностью.
В истории классической промышленности были периоды когда всё делали единично и ручками. Я мог бы сравнить такие периоды с ранним развитием IT. Со временами расцвета UNIX или DOS. С языками вроде Си.
Потом были периоды рабовладельческого строя и раннего капитализма, когда любую задачу закидывали необходимым количеством человеков. Я бы сказал, что сейчас в IT-индустрии как раз такой подобный период, со всеми этими Java и PHP.
Но в итоге, во всех развитых странах промышленность пришла к автоматизации. И производит продукты лучше, быстрее и качественнее, чем когда-либо.
И IT-индустрию ждет когда-нибудь то же самое, то есть массовая автоматизация, программы которые пишут программы(понимаете, к чему я клоню, да?), и это неминуемо.
Я смотрю на языки функционального программирования, вроде хаскеля, как на, ну не знаю, алмазные лопаты. Выглядят красиво, конечно, прочностью обладают неслабой, но что они могут сделать против таких детищ автоматизированной промышленности, как отбойные молотки и экскаваторы?
Я не вижу, как ф.п. может помочь с если уж не уменьшением, то хотя бы со сдерживанием растущей сложности софта. Я вижу ф.п. как модный фетиш, и ничего более, и поэтому время от времени на него наезжаю, т.к. бессмысленные фетиши меня раздражают, т.к. бессмысленные фетиши это может быть круто в дизайне шмоток, например, но не в инженерии.
Кстати, скоро напишу на хабр статью о макросах и метапрограммировании в лиспе, как только продумаю её.
no subject
Применять ф.п. вместо инструментов, которые во втором подходе используются - тоже не получится, потому что ф. языки банально на порядок сложнее всяких Java и PHP.
Ценность ф.я. для третьего подхода тоже сомнительна, это стезя метаязыков типа лиспа(вообще, я думаю, когда-нибудь в будущем код совсем не придется писать - визуально или словесно описанные в общих чертах архитектуры будут сразу отображаться в машкодах).
no subject
Наоборот, чтобы писать хороший код на Си(чтобы писать операционные системы, например) нужна огромная квалификация и навыки, код должен быть до мельчайших деталей продуман.
Томпсон, Ритчи, да ну Кармак, в конце-концов - таких людей единицы, и эти единицы даже с современными запросами к индустрии разработки ПО не справятся, по причине малочисленности, я уж не говорю о будущем.
И в перспективе, даже современный подход с этими запросами не справится, и это уже видно.
no subject
no subject
Я должен сейчас вдруг внезапно понять, что это серебряная пуля, которая определенно зарулит метапрограммирование и автоматизацию? Вряд ли.
no subject
no subject
no subject
Более того, лисп никак не имеет монополии на метапрограммирование -- при определённом желании это делается на любом языке.
Я пытаюсь донести другую мысль -- что при внесении изменений в систему наличие статической системы типов является фактически жизненной необходимостью. Потому как 100% покрытия тестами в большом проэкте достичь очень тяжело (даже для line coverage, я уж не говорю о condition coverage). И ещё тяжелее его поддерживать при внесении изменений.
no subject
Неудобно и через жопу, и плюс с подключением внешних инструментов.
>Я пытаюсь донести другую мысль -- что при внесении изменений в систему наличие статической системы типов является фактически жизненной необходимостью.
Я пытаюсь донести мысль что тотальное метапрограммирование и автоматизация избавит от множества неудобств, которые вносятся человеческим фактором.
(no subject)
no subject
Сейчас остался только вопрос контроля, который в Лиспе решается на уровне конца 70-х годов, на уровня языка Ада.
Ибо типы-то он игнорирует!
no subject
Типы это довольно убогая и неудобная для конкретных случаев система контроля. Специализированные макросы дают больший контроль, чем типы.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(Anonymous) - 2011-11-03 02:01 (UTC) - Expand(no subject)
(Anonymous) - 2011-11-02 12:34 (UTC) - Expandno subject
Специальные формы часто (очень часто) выполнимы в виде ФВП в языке с нормальным порядком вычислений.
no subject
Верно, но лисп это постоянное метапрограммирование, мы там можем вынести язык на сколь угодно высокий уровень. Это не язык, это метаязык.
>Специальные формы часто (очень часто) выполнимы в виде ФВП в языке с нормальным порядком вычислений.
Это фигня, этим покрывается 1% использования макросов от силы. Плюс, это добавляет издержек по производительности.
no subject
>Это фигня, этим покрывается 1% использования макросов от силы.
Есть статистика применения макросов в большом проекте на Лиспе? Действительно ли там всего 1% может быть закрыт нормальным порядком вычислений?
Или эта цифра только что придумана из головы, чтобы уменьшить ценность моего аргумента?
В Хаскеле Template Haskell я использую только и исключительно для кодогенерации по структурам типов. Всё то, чтобы я сделал на макросах в Си, я делаю с помощью ФВП.
>Плюс, это добавляет издержек по производительности.
Нет.
>>Если вам требуется метапрограммирование, то вам требуется язык выше уровнем.
>Верно, но лисп это постоянное метапрограммирование, мы там можем вынести язык на сколь угодно высокий уровень. Это не язык, это метаязык.
То есть, у Лиспа нет границ и он применим всюду, сколь угодно низко и сколь угодно высоко.
Есть ли вообще область деятельности программиста, где Лисп проиграет какому-либо другому языку?
Я спрашиваю, чтобы определить, является ли применимость Лиспа фальсифицируемой. Если является, то значит имеет право на существование какой-то другой язык, возможно, не один. Если не является, то Лисп подобен всемогущему богу от программирования и я говорю с религиозным человеком.
no subject
Обычно, большая часть применения макросов сводится либо к DSL, либо к макросам вида define-что-то-там.
В качестве примера последнего - ну вот у меня в DOORS COM-интерфесы определяются специальными макросами. Вот тут примеры: https://github.com/Lovesan/LDX/blob/master/dxgi/interfaces.lisp
Они кое-что делают во время компиляции, и раскрываются в определения функций, содержащих код для маршалинга данных из Си и обратно, код вызова методов сторонних интерфейсов и код коллбэков-трамплинов из Си в лисп. Это просто вне ФВП, я вообще не могу никак фвп к этому привязать.
Или вот, из CLSQL: http://clsql.b9.com/manual/ch02s02.html
DSL макросы позволяют строить какие угодно по своей структуре, начиная с чего-нибудь наподобие LINQ2SQL и заканчивая встроенным подмножеством алгола как в LOOP (http://l1sp.org/cl/loop). mv (http://13-49.blogspot.com/) использует DSL для верификации и генерации чего-то наподобие VHDL, насколько я знаю.
Если еще взять и reader-макросы, то и какие-угодно по синтаксису.
Как простенький пример - см. расширение ридера для RDNZL: http://weitz.de/rdnzl/#examples.
Как более сложный пример - я как-то делал библиотеку парсер-комбинаторов по PEG для статьи на хабр; статью написать так руки и не дошли, но вот код: https://gist.github.com/1333362
Там можно PEG-выражения прямо в лиспе использовать, по типу такого:
(это применение парсера по описанной грамматике к соответствующей строке)
>Всё то, чтобы я сделал на макросах в Си, я делаю с помощью ФВП.
В лиспе я обычно это делаю начиная с
(declaim (inline function-name)):)Сишные макросы с лиспами сравнивать нельзя, у них разное назначение.
>То есть, у Лиспа нет границ и он применим всюду, сколь угодно низко и сколь угодно высоко.
Сколь угодно высоко. Насчет низко - только если как кодогенератор - рантаймы у лиспа слишком жирные.
А вообще, я планирую статью о метапрограммировании и макросах для хабра, как я в постинге сказал, вот там подробнее все распишу.
(no subject)
(no subject)
no subject
(Anonymous) 2011-11-02 12:38 pm (UTC)(link)В ленивом языке приходится ввести спецформу, эквивалентную begin, в энергичном - эквивалентную if. 1-1.
no subject
Нет.
(no subject)
(Anonymous) - 2011-11-03 01:39 (UTC) - Expandno subject
Я не буду утверждать тот-же Haskell уже там, но как метод борьбы с сложностью композиционность и чистота (точнее не столько сама чистота, сколько явные эффекты) мне кажутся более правильным подходом.
no subject
no subject
no subject
Это и сокрытие состояния в объектах, и чистота которая позволяет точно знать что вот в этом коде state-related тараканов точно нет и его можно кешировать/параллелить/you name it.
И библиотеки комбинаторов и ещё 1001 методов.
(no subject)
no subject
no subject
no subject
no subject
Потому что как только мы убираем линивость, то ФВП превращаются или в тыкву (компилятор не может упрощать код поскольку это будет нарушением семантики языка) или же в стандартный кошмарик где нам приходится руками сворачивать/переписывать код, протаскивать аккумуляторы или параметры ограничивающие глубину рекурсии и т.п.
no subject
Это как минимум.