Преимущества функционального программирования

Шарп видел? Вот там фп применено как надо(LINQ).

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

В чистом виде оно ненужно совершенно.

если с++ головного мозга и думать как математик (Ъ программист) не умеешь, то да, не нужно совершенно

Ты эху фигню видел вообще?

Да. И успешно применял.

а вокруг одни дебилы?

Один ты в белом пальто стоишь, ага.

Так что там с дебагом? В последних студиях отлично отрабатывает дебаггер на линк выражениях.

Ты эху фигню видел вообще?

Да. И успешно применял.

в школьном проекте

в реальных проектах это применять нельзя, ибо запаришься потом переписывать

Один ты в белом пальто стоишь, ага.

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

Так что там с дебагом?

вырастешь - узнаешь, хотя я сомневаюсь

В последних студиях отлично отрабатывает дебаггер на линк выражениях.

последнии студии на столько кривые и бажные, что их может юзать только школоло, в реальных системах юзают <=2010, а там дебагер в лямбды не умеет

в реальных проектах это применять нельзя, ибо запаришься потом переписывать

чет никто не запарился еще

последнии студии на столько кривые и бажные, что их может юзать только школоло, в реальных системах юзают <=2010, а там дебагер в лямбды не умеет

понятно, ынтерпрайз-кукаретик очередной.

понятно, ынтерпрайз-кукаретик очередной.

что же вы, дети, понимаете под словом «ынтерпрайз»?

я тебе про CADы говорю, на которых города проектируют и дороги/мосты/здания моделируют

PS: не кукаретик, а разработчик када и плагинов для autocad

PS: не кукаретик, а разработчик када и плагинов для autocad

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

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

А ты, int13h, конечно, молодец. Такую платину кастанул!

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

вы про мой первый пост?

Какие крупные комплексы ПО были написаны (созданы) с использование этой парадигмы начиная с ее зарождения?

Нашли что-нибудь? Если да, то внесите в шапку, не читать же 8 страниц срача.

тут на последних страницах самая мякотка, евпочя.

в большей части - AutoCAD, со вставками на C

Он про «царя».

я уже просто не могу понять: в треде смешались кони, люди. =)

А на чем он писан?

я не уверен, но ядро написано на Common (?) LISP со вставками на C

Я про поток сознания царя.

Давайте подведем итоги нашего срача топика. Из всего самого годного я нашел только две реально полезные вещи созданные на основе ФП: Autocad и Emacs. Хотя, в первом я полностью не уверен - мало информации о технологиях разработки ПО в Autodesk. Что еще, подсказывайте?

вещи созданные на основе ФП: Autocad и Emacs.

Чушь. И то, и другое к ФП имеют чуть менее, чем никакого отношения.

Что еще, подсказывайте?

Ты ищешь какую-то странную фигню.

Из всего самого годного я нашел только две реально полезные вещи созданные на основе ФП: Autocad и Emacs.

AutoCAD и Emacs — ни разу не ФП, а галимая императивщина во все поля. В емаксе используется статическое метапрограммирование в лисповском стиле, а лисп в Автокаде — что-то из разряда говна на палочке. Ни разу не видел ни одного макроса в автокадовских исходниках. Там лисп как бейсик примерно используется.

Что еще, подсказывайте?

Зависит от определения ФП. Использование языков, способствующих написанию программ в функциональном стиле (ML) к ФП относится?

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

Ни разу не видел ни одного макроса в автокадовских исходниках.

у вас есть исходники автокада?

Устроился я тут на работу, C# программистом, до этого с C# не был знаком абсолютно. Читаю теперь Троелсена. Читаю про классы - везде, везде я вижу простые лямбда замыкания. Классы, методы, свойства - всё это на поверку оказывается сахарком поверх лямбд. Отсюда делаю вывод: императивное программирование - это простое функциональное программирование, приправленное состояниями.

Ни разу не видел ни одного макроса в автокадовских исходниках.

у вас есть исходники автокада?

Имелись ввиду исходники программ на AutoLISP. Однажды мне захотелось познакомиться с самым известным Success Story лиспа, и я попросил знакомого инженера-конструктора (проектировщика трубопроводов) мне показать, что и как он делает с лиспом в Автокаде; объяснить, что при помощи этого инструмента можно сделать, а что нельзя; ну и примеры программ продемонстрировать.

И вот что выяснилось:

Автолисп — это не совсем лисп. Киллер фичи лиспа — макросов — или совсем в языке нет, или же нам не удалось их обнаружить. А раз макросов нет, то в плане выразительной мощности ничем этот «лисп» не отличается от попсовых динамических языков типа JavaScript. Для функционального программирования Автолисп тоже плохо подходит, т.к. даже лексического скоупинга и замыканий в нём нет: lambda — конструкция создания не замыкания, а анонимной функции, не поддерживающей ни upward, ни downward funargs (в общем случае) [1]. Очевидно, главная причина, почему Автолисп до сих пор используется — необходимость обеспечивать совместимость с километрами уже написанного кода.

Касательно километров: типичные программы на Автолиспе — как third-party, так и написанные самим моим знакомым — брутальные портянки скобчатого говнокода, без намёка на читабельность и _редактируемость_. По поводу последнего поясняю — нормального редактора лиспокода (структурного, в стиле paredit) в Автокаде нет. Пишешь портянки — изволь парность скобочек вручную отслеживать. К счастью, специально для ковыряния в портянках из огрызков ногтей предусмотрительные разработчики добавили в среду разработки символьный отладчик :-)

Короче, Автокад — это не Success Story лиспа, а скорее Success Story концепции «встроенный юзерский язык в большой и сложной софтине». А настоящая народная история успеха лиспа — это Emacs, в котором макросы повсеместно используются (хотя и elisp по-своему гаденький).

Ссылки:

[1] https://en.wikipedia.org/wiki/Funarg_problem

Из всего самого годного я нашел только две реально полезные вещи созданные на основе ФП: Autocad и Emacs

Каков критерий полезности?

maxima (http://maxima.sourceforge.net/)

coq (http://coq.inria.fr/)

nikki (http://joyridelabs.de/game/)

mighttpd2 (http://www.mew.org/~kazu/proj/mighttpd/)

Сойдут?

Один из побочных эффектов FP - простой API, который есть шанс повторно использовать.

Как результат - больше полезных библиотек, которые используются ... в других библиотеках.

Мы используем CHICKEN Scheme в разработке прошивки для мультимедиа аппаратов (типа такого). Нижний уровень написан на Си - так исторически было проще, но вся логика, включая GUI (собственный велосипед) - на Схеме. Если отбросить субъективные метрики, типа простоты и понятности для пишущих, можно отметить, что общее количество кода уменьшилось раз в 20 по сравнению с предыдущей версией, выполненной в более классическом стиле (Си и Си++) не учитывая ставшие не нужными толстые библиотеки типа Qt. Производительность и функциональность остались на уровне.

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

Мы используем CHICKEN Scheme в разработке прошивки для мультимедиа аппаратов (типа такого).

Лол, массовые самоубийства быдлокодеров на ЛОРе. Они, оказывается, караоке на своих пьяных быдлокорпоративах под Лисп напевают.

Фу такими быть! Настоящие пацаны такое на чисто аппаратном уровне делают, см. MilkyMist One SoC.

А настоящая народная история успеха лиспа — это Emacs, в котором макросы повсеместно используются (хотя и elisp по-своему гаденький).

гаденький, ага. а вот даже TeXmacs почему-то не особо популярен, хотя он и на нормальной схеме вместо говоноелиспа, не говоря уже о каком-то мохнатом Zmacs или Climacs на православном CL, или минималистичном Emact со встроенном ISLISP.

я бы вообще Емаксом не пользовался, кабы не org-mode babel. и вся та требуха которая уже кем-то написана.

Касательно километров: типичные программы на Автолиспе — как third-party, так и написанные самим моим знакомым — брутальные портянки скобчатого говнокода, без намёка на читабельность и _редактируемость_

кстати, в BricsCAD встроенный ISLISP, в котором совместимость с автолиспом сделана макросами. оно быстрее автолиспа раз в 30.

тянет на «историю успеха»?

по идее, конечно, нужен какой-то структурный редактор с семантическими фреймовыми базами данных, который сам себя дописывает и переписывает в фоне, когда юзер гуйню теребит :) что-то типа SHRLDU

а live coding какие-то среды не пытались использовать?

Пара ссылок:

LISP в NASA: Lisping at JPL - не история успеха, скорее наоборот, но полезно ознакомиться в назидание молодым поколениям.

Из области геймдева: State-Based Scripting in Uncharted 2: Among Thieves - PLT Scheme используется в качестве скриптового языка в игровом движке.

Это embedded - тут не то что live, обычный gdb зачастую непоиспользуешь.

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

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

Лол, массовые самоубийства быдлокодеров на ЛОРе. Они, оказывается, караоке на своих пьяных быдлокорпоративах под Лисп напевают.

:-)))))))))

Мы используем CHICKEN Scheme в разработке прошивки для мультимедиа аппаратов (типа такого). Нижний уровень написан на Си - так исторически было проще, но вся логика, включая GUI (собственный велосипед) - на Схеме. Если отбросить субъективные метрики, типа простоты и понятности для пишущих, можно отметить, что общее количество кода уменьшилось раз в 20 по сравнению с предыдущей версией, выполненной в более классическом стиле (Си и Си++) не учитывая ставшие не нужными толстые библиотеки типа Qt. Производительность и функциональность остались на уровне.

Зачёт! :-) Очень прикольно. Спасибо за Success Story.

Только вот из примера непонятно, используется ли в программе определяющая фича лиспа — статическое метапрограммирование на макросах. Если нет, то неясно, почему именно лисп в качестве инструментального средства был выбран, а не ML какой-нибудь, который в плане выразительности от «лиспа без макросов» мокрого места бы не оставил + некоторые статические гарантии бы дал (для ембеда явно не лишнее). Гуйня у вас, случайно, не на компилируемом DSL описывается?

Кстати, о железках — вспомнил ещё одну историю успеха. Есть уфимская контора — Полигон — которая разработкой телекоммуникационных железок занимается. Они активно в продакшне функциональные языки используют — Erlang, Haskell, OCaml. Про OCaml мне говорили, что его на таких железках используют, куда рантайм других языков не влезает (если забыть про C++). Сейчас кастану в ветку ихнего главного программиста — может расскажет чего интересного.

я бы вообще Емаксом не пользовался, кабы не org-mode babel. и вся та требуха которая уже кем-то написана.

Same here. Подсел на org-mode/babel в качестве инструмента для создания интерактивных воркшитов, а также личного баг-трекера/планировщика. Некоторое время для literate programming его использовал (обмазываясь мейкфайлами), но, к счастью, красноглазие отпустило. Пришёл к выводу, что нормальных инструментов для LP сейчас нет. Babel — лучшее из существующего, но и у него проблем хватает (баги, тормоза, зависимость от Emacs); и инфраструктурные затраты на LP непомерными получаются.

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

Всё просто — причина непопулярности TeXmacs в его непопулярости :-) Я о том, что упомянутая выше «требуха на елиспе» появилась в результате популярости Емакса. Когда-то требухи совсем немного было, но люди использовали Емакс, т.к. выбора не было. А сейчас кто будет использовать TeXmacs, если он едва ли 1% функциональности Емакса покрывает, учитывая всю жизненно важную требуху? Нихрена же там нет для разработки программ, например.

А концептуально TeXmacs прекрасен, конечно же: структурный редактор, WYSIWYG, с отличным _интерактивным_ тайпсеттингом, возможностью составлять документы из разнородных блоков (следствие структурности) и человеческим встроенным языком.

Теоретически, можно на базе TeXmacs построить нормальную среду для литературного программирования (интерактивную, с полным WYSIWYG). Ещё можно что-то наподобие JetBrains MPS соорудить. В Емаксе такое хер сделаешь — все нервы уже на простейших полурабочих прототипах закончатся. Реализация babel и всяких там mmm-mode — это ведь ужас-ужас, на соплях всё держится и от малейшего дуновения ветерка разваливается начинает. В TeXmacs же есть ядровая, качественная поддержка multi-mode и структурного редактирования. Надо бы поиграться с этим.

кстати, в BricsCAD встроенный ISLISP, в котором совместимость с автолиспом сделана макросами. оно быстрее автолиспа раз в 30.

тянет на «историю успеха»?

Да это же полнейшая укатайка — называть историей успеха лиспа реализацию «недолиспа» на другом, «нормальном» лиспе :-) Напоминает то, как Хаскельщики приводят GHC в качестве примера большой программы на Хаскелле.

По поводу «быстрее в 30 раз» — думаю, в Автокаде лисп тормозной не потому, что разработчики — дурачки, не способные конкурировать с «истинными лисперами», а потому, что для тех задач, которые на Автолиспе решаются, текущей производительности с головой хватает, а ускорение привело бы к неоправданному усложнению реализации (сейчас это, наверняка, простейший интерпретатор уровня AST).

Сам я занимаюсь разработкой встроенного языка в крупной коробочной (и очень дорогой) софтине, и с точно такой дилеммой столкнулся, когда от гораздо более производительного решения (хитрого трассирующего джита и точного копирующего GC) пришлось осознанно отказаться в пользу решения тормозного, но простого и надёжного (ahead-of-time компиляция + консервативный GC). Написанный на OCaml компилятор — это, кстати, своего рода Success Story функционального программирования; правда, речь не о «крупном комплексе ПО» (как автор просит), а всего лишь об одном из модулей ядра крупной промышленной софтины. Если кому интересно, могу подробнее рассказать.

по идее, конечно, нужен какой-то структурный редактор с семантическими фреймовыми базами данных, который сам себя дописывает и переписывает в фоне, когда юзер гуйню теребит :) что-то типа SHRLDU

ETAOIN SHRDLU КТУЛХУ ФХТАГН!!11 :-)))

Не понял про «который сам себя дописывает и переписывает в фоне». Ты про то, что редактор должен реактивным образом выполнять пропагацию изменений в базе знаний (простейший пример: формулки пересчитывать и картинки перерисовывать)? Ну, такое Mathematica, и в какой-то мере Excel, умеют делать.

По поводу семантических фреймов и интерактивности:

Предыстория: я сейчас в качестве личной базы знаний Пролог использую (swi) — храню коллекцию фактов в обычных текстовых файлах и тупо делаю в емаксе «consult file» на каждый чих, при каждом внесении изменений. Интеграции с org-mode нет никакой, а единственное, что есть интерактивного — куча горячих клавиш для выполнения часто используемых запросов. Плюс подхода с plain-text базой знаний — возможность использовать контроль версий (hg), с ветками, распределённостью и прочими блекджеками. Минусом же является почти полное отсутствие интерактивности.

Так вот, есть следующая идея: можно взять готовую среду/фреймворк для разработки интерактивных воркшитов (TeXmacs, IPython, а может даже и Mathematica) и соорудить поверх «структурный org-mode», в котором семантические блоки (pages? snippets?) были бы связаны реактивно (dataflow в стиле Excel), а в качестве универсального средства представления знаний использовался бы не Пролог, а более дружественный к интерактивной реактивности Datalog (в частности, зацикливания вычислений исключены были бы).

Такая вот странная идея. Скорее всего так и останется в мокрых мечтах...

Если кому интересно, могу подробнее рассказать.

Рассказывай, конечно.

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

Ну вот в last of us/uncharted оно как раз и было киллер-фичей.

Babel всякие это вообще не LP. Там даже += нельзя сделать. LP почему-то мало кто понимает. Вон еще псведо-LP новинка: http://vimeo.com/97623064.

Под Eclipse есть Ъ: http://lep.sourceforge.net/.

PLT Scheme используется в качестве скриптового языка в игровом движке.

http://www.reddit.com/r/programming/comments/1gmvrb/realm_of_racket_is_finall...

Тут был большой тред на эту тему со сливом борще-архитекторов.

https://www.youtube.com/watch?v=oSmqbnhHp1c

А ты не в курсе, что Datalog семантически эквивалентен реляционной алгебре, а, следовательно, и SQL? Так что твои мокрые мечты давным давно реализованы в мейнстриме.

PLT Scheme используется в качестве скриптового языка в игровом движке.

И вот опять это вранье. Вас же, скобканутых, в прошлый раз уже с треском слили. Опять решили опозориться, что ли?

Ты, пацан, рамсы попутал. Слили как раз скобканутых борщехлебов.

Это ты что-то попутал. Напоминаю фаталити:

(state ("shake-hands")
  (on (begin)
    (track ("player")
      [wait-move-to "player" "waypoint7"]
      [signal "player-at-waypoint"]
      [wait-for-signal "sully-at-waypoint"]
      [wait-animate "player" "shake-sullys-hand"])

    (track ("sullivan")
      [wait-move-to "sullivan" "waypoint7"]
      [signal "sully-at-waypoint"]
      [wait-for-signal "player-at-waypoint"]
      [wait-animate "sullivan" "shake-drakes-hand"])))

Babel всякие это вообще не LP. Там даже += нельзя сделать. LP почему-то мало кто понимает.

+= действительно нельзя сделать, и это к лишним телодвижениям приводит. Зато, в отличие от многих других систем, поддерживается возможность переупорядочивания и произвольного вкладывания чанков, без которой LP невозможно пользоваться (антипримеры — ocamlweb, literate haskell). Впрочем, именно эта фича в Babel и глючит сильнее всего — вставка номеров строк порой неправильно работает, tangle иногда сильно тормозить начинает. Долго ковырялся в кишках Babel, но решить всех проблем не смог, а главное — увидел, насколько же это хрупкая и костыльная вещь. Не хотелось бы завязывать себя (молчу про других людей) на таком инструменте. К сожалению, почти весь Емакс такой (скорее, почти весь лиспокод).

Вон еще псведо-LP новинка: http://vimeo.com/97623064.

Вот это воистину как та часть Babel, которая за интерактивные воркшиты отвечает, и не более того.

Под Eclipse есть Ъ: http://lep.sourceforge.net/.

На вброс похоже. Eclipse что, научился в multi-mode? Судя по докам, оно только C++ поддерживает (или же один язык на документ); хотя прямым текстом об этом нигде не говорится — прошу пояснить.

Мне обязательно нужна возможность смешивать в одном документе исходники на разных языках программирования (R, Python, Haskell, Bash, SQL, etc...), не теряя при этом в возможностях по эффективному редактированию. Как минимум подсветка синтаксиса интерактивная нужна, и вот с этим аспектом Babel на отлично справляется — в каждом чанке полноценный language-mode работает.

А ты не в курсе, что Datalog семантически эквивалентен реляционной алгебре, а, следовательно, и SQL?

Даже если и эквивалентен (конкретному варианту реляционной алгебры), речь о UI идёт — о том, что существуют юз-кейсы, в которых интерфейс дейталога оказывается более адекватным, чем интерфейс SQL. Навскидку, большие отличия Datalog как UI: возможность не объявлять схему данных заранее, возможность задавать правила вывода (аналог в SQL — копипаста подзапросов?). Разница очевидной становится в случаях, когда в Datalog рекурсивные правила используются, или же когда нужно «склеивать» правила, определяющие транзитивные отношения между сущностями. В SQL в таких случаях обычно приходится писать нечитабельные портянки с большим количеством джойнов.

Я встроенный дейталог (простейший интерпретатор) в программах на OCaml использую часто. Выглядит это вот так примерно (см. <:dl_fact< ... >>, <:dl_clauses< ... >>). Особенно удобно графы таким образом представлять и всякие dataflow факты. Не могу представить, как можно в таких случаях использовать SQL. И вот для личной базы знаний такой UI — самое то, как кажется. Я и SQL в личной базе использую, для хранения tabular data (всяких экспериментальных данных, от объёмов которых пролог умер бы, и с которыми потом удобно в R или Excel прямо из БД работать), но большую часть знаний всё равно в прологе храню — удобнее сильно.

Так что твои мокрые мечты давным давно реализованы в мейнстриме.

Что реализовано в мейнстриме? Интерактивная, реактивная среда для Literate Programming/Reproducible Research, с унифицированным механизмом представлением знаний в виде фактов Datalog (важная фича UI)? — Не нашёл. Недостаточно внимательно смотрел?

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

Напоминаю, что это тупо конфигфайл вместо многословного XML, а не код. И транслируется этот конфиг в C++. Слились вы по грязному, борщехлебы.