функциональщина :)

вот захотелось мне развлечься немного и разучить какое-нить функциональное язычие.
но вот выбор меня немного смутил — их много и каждый хвалят-ругают :)

в общем, что интересует:
— читабельность кода , а то вот начал читать про haskell но как-то меня смущает, что конструкция «where» позволяет объявить «подпрограммы» после кода, а let — перед вызывающим кодом :) , я заглянул в либы идущие с компилятором, там это усугубляется ... хотя может это я балованный
— скорость
— взрослость системы, условно говоря , если я хочу написать, ну пусть веб-сайт, все либы и фреймворки должны быть уже написаны и работать более-менее сносно — т.е. всякие феньки типа ajax или там интеграция с memcached должна уже быть
— поддержка всяких фенечек, типа message passing и т.д.

я понимаю что вопрос спорный, так что прошу отвечать более менее информативно — что именно пользовали и как ощущения

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
подытожу свой «трип» :
haskell — очень крут, много «плюшек» и «сахара», походу аналог с++ но в функциональной области
из плюсов:
— «взрослая» система типов, любая функция аналог «template» в с++, но без кучи синтаксических конструкций, т.е. a = a + b будет работать с любыми типами, которые понимают +
— «template haskell» — очень полезная вещь
— математичность :)
— оптимизация, как на уровне компилятора, так и «ручная»
из минусов:
— нет фигурных скобочек (да, есть, но не всегда)
— очень сложно реализовывать «императивные» вещи, например «курсор» (тот что while(cursor.next()) ) выглядит очень жутко, опять таки, имплементация прерванного continuation-passing style (CPS) выглядит несколько перегруженной

— монады могли бы быть более императивные , все равно они «специфические» и так

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

javascript/nodejs — тут я буду ковырять глубже. mixed style, фигурные скобочки, динамика, активно используется в production ... ну и javascript вроде как всем знаком, т.е. разработчиков искать относительно проще

Можете ещё F# посмотреть. Я не пробовал, говорят что похож на гибрид OCalm и Haskell на .net.

ну я принципиально «отбрасывал» jvm/.net (ничего не имею против платформ)
там есть еще и nemerle если что

собственно F# это практически Ocaml портированный на .НЕТ.

А не кажется что 2 недели это сильно галопом по европам что бы делать далеко идущие выводы?

даже меньше 2-х недель. так что это «беглый взгляд со стороны человека знающего с++/php» :)
конечно, я теперь могу подписаться что haskell очень клевый, но работать буду там где больше денег, а их, увы .... больше в high-load пшп

А, я понял, ты просто комплексовал перед местными 24-летними синьёрами которые знают haskell, scala, clojure, groovy, go, ocaml, erlang, lisp и никогда не деплоят ошибок в продакшн.

я бы добавил — «умеют пользоваться версионкой» :)
но нет, я просто развивал свой кругозор, пару интересных идей я таки нашел:
— как делать фейковые урлы (без обращения к серверу) — из derby.js

— как можно при помощи lazy loading уменьшить нагрузку на апач

Так чего учить-то: хаскель или скала? :) Код на хаскеле читается на первый взгляд плохо, это наверное один из самых тяжелочитаемых ЯП? Скачал уже книжки по скале, а тут вроде подхваливают хаскель ;)

Если вы хотите именно прошариться в функциональном программировании причем серьезно — учите Хаскель. Если хотите писать как и дальше но баловаться ФП — учите скалу, Лисп да что угодно. Писать с определенным налетом функциональности можно на большинстве современных языков. Для крутых функциональщиков эталоном является хаскель. Там есть монады, это круче чем печеньки:))))

Я смотрел Скала — конференцию, там выступал создатель Хаскеля. Вообще судя по всему скала плавно дрейфует по сложности и культуре к Хаскелю.

«круче чем печеньки!» © — +стопіцот, дозвольте утягнути в використання)
Скала здається чимось середнім між Хаскелем і Джавою.

Беріть користуйтеся на здоров’я :)

все зависит от того, какие цели :)
скала ( я вот глянул) надстройка над jvm с плюшками и костылями, где jvm не справляется. при этом достаточно утилитарна , за счет «прямого» интерфейса с jvm
хаскель же это такой академический монстр, некоторые навороты там очень неплохо выглядят, например тот же template haskell (такая себе фича для создания dsl) но несколько коряво исполненные

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

Скала более ориентирована на реальную жизнь, на ней можно писать и ентерпрайз — приложения. Хаскель же более трушный.

Не знаю, поки що з кодом на Хаскелі проблем не було, синтаксис поки що здаться простим і приємним (за винятком коду любителів понавизначати символьних операторів, але таке в багатьох мовах може бути).
А от у Скали, наскільки я знаю, синтаксис обтяженіший деталями, більш традиційний.

Якщо хочеться справді нової і консистентної мови, то вибір однозначно Хаскель)

Система типов скалы — мощь сила и жесть. Я ёё так и не осилил :-)

Хаскель даж попроще в этом плане будет.

Самое главное — не столько пинать хаскель и т.д. — сколько раскуривать само функциональное программирование, лямбда — исчисление, монады. Почитайте книгу Оказаки «Функциональные структуры данных».

Это все мифы.

1. Такая штука, как «само функциональное программирование», практически не существует. *Идиоматичный* код на разных языках выглядит часто очень по-разному.

Например: циклы в Scheme — рекурсия, в Haskell — комбинаторы вроде map и fold, в Lisp (который с натяжкой можно назвать функциональным) — свой собственный DSL.

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

3. Функциональные структуры данных — это уже высший пилотаж. Советовать это начинающему функциональщику — все равно что советовать начинающему программисту Кнута.

так это же не сразу, просто будет человек знать что такое есть

Но трандеть про монады — это ж прикольнее чем работать ;)
Да и ЧСВ возростает.

вот ЧСВ тут совершенно не при чем

«Триндіти про ООП краще, ніж працювати»

«Триндіти про структуризацію програми краще, ніж працювати»

Монади — це лише спосіб структурувати програму, який має застосовуватись, коли для нього є передумови і коли він починає сам напрошуватись.

В хаскеле монады довольно сложны для восприятия.

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

Монады как практический инструмент не сложнее, скажем, указателей или наследования. Просто еще одна концепция, которую надо освоить. Другое дело, что многие считают, что все возможные концепции они изучили еще в институте, а монады — это то, что они и так используют в C++ или jQuery, только по-сложному объясненное.

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

Чтобы хранить состояние, достаточно использовать монаду State (или, в общем случае, включить State в ваш стек монадных трансформеров).

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

Ну и приятный и гибкий синтаксис в придачу.

То есть по сути использование микро — DSL?

А чем интересно просто, Хаскель лучше для построения DSL чем другие языки?

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

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

Если интересны DSLи, есть множество статей о них в контексте Haskell. Например, можно почитать arbitrary.name/papers/fpf.pdf — над ним, кстати, работают и украинские программисты.

Это что касается DSL в целом. А для micro-DSL, которые я имел в виду выше, главным преимуществом является сильная статическая типизация. Такой же стиль программирования принят и, к примеру, в Common Lisp, но там из-за отсутствия типизации легко написать что-то, не имеющее смысла. Соответственно, и интерпретатор такого DSLя должен содержать кучу кода по валидации и обработке ошибок.

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

Большое спасибо Роман очень интересно.

Скажімо так: вони складні до сприйняття і прості після сприйняття :)

Насправді — просто кілька правил і дві-три абстрактні функції.

и еще — вот есть в хаскеле sparks — типа отложенные многопоточные вычисления. все классно, но вот не понятно можно ли их конфигурировать — т.е. вроде как есть опция для указания количества потоков, но знают ли sparks об єтой опции ?

Каждый HEC (haskell execution context) формируется для отдельного процессора, в каждом HEC есть свой Spark Pool, который держит спарки, как только какой-то процессор становится idle программа запускает спарк. Когда ты указываешь количество тредов, ты указывавешь не количество тредов ОС, а Haskell Lighweight Threads(HLT), а потом уже передаются системным потокам, но ими вроде управлять нельзя.

$ ./A +RTS -N8

В таком коде, ты говоришь,что использовать 8 HLT, как только кто-то из них свободен, на него цепляется спарк.

Для наглядности:i.stack.imgur.com/f57Hm.png

спасибо. вроде все разумно, меня как раз и смущало что может получится слишком много тредов ОС, а раз уж threads pool сделан, то все в порядке

Это неверно. -N задает именно число потоков ОС. На них мапятся как обычные легковесные потоки (создаваемые с помощью forkIO/forkOS), так и spark-потоки, которые создаются автоматически по мере надобности.

ну я где-то так и понял, вобщем для меня главное что создатели хаскеля об этом позаботились

Как то уж категорично. Цитата с офф.дока:

7.22.3. Parallel Haskell

GHC includes support for running Haskell programs in parallel on symmetric, shared-memory multi-processor (SMP). By default GHC runs your program on one processor; if you want it to run in parallel you must link your program with the -threaded, and run it with the RTS -N option; see Section 4.15, “Using SMP parallelism”). The runtime will schedule the running Haskell threads among the available OS threads, running as many in parallel as you specified with the -N RTS option.

Как то не стыкуется, речь о Haskell потоках, которые исполняются на доступных поток ОС.

А то что, уже в коде написано это другой вопрос. Когда у вас есть forkOS тогда и будет создавать и новый хаскель поток и лепить его к свежесозданному системному потоку.

Если неправ, поясните. Ориентировался всегда на эту доку community.haskell.org/...lticore-ghc.pdf

Так ровно это ж и написано :) Просто «running as many» относится не к Haskell threads, а к OS threads (хотя здесь оно действительно двусмысленно сформулировано).

То, что Haskell потоки исполняются на OS потоках, четко сказано в статье, на которую Вы ссылаетесь: «Haskell threads are executed by a set of operating system threads, which we call worker threads» (секция 4.1).

То, что -N соответствует OS threads, четко вроде как нигде не написано, но должно быть ясно исходя из здравого смысла. OS треды нужны для того, чтобы распараллелить нагрузку по ядрам. В документации по -N[x] сказано «Normally x should be chosen to match the number of CPU cores on the machine». А легковесных потоков может быть тыщи и мильйоны. Они, собственно, потому и легковесные, что легче потоков OS. И используются они не для параллелизма, а для concurrency, и под капотом превращаются в вызовы epoll/kqueue/poll/select/... То есть легковесные потоки и спарки — два вида штук, которые могут исполняться на OS тредах. См. ту же секцию 4.1.

я тут потихоньку пинаю хаскель\yesod (на удивление все «аккуратненько» — шаблонизатор с поддержкой вставок кода , автоматический ребилд на изменение — прямо пшп)

но вот крутится вопрос, который я пока не могу сформулировать «в гугль», в общем есть pure functions , классно, в гайдах упоминается что их можно вычислить один раз и все, так вот — будет ли система кешировать их автоматически или надо указывать ручками, ну т.е. например, есть функция которая возвращает футер странички (ну там шаблоны всякое разное, но по сути получается какой-нить getFooter) — так вот — будет ли система вычислять его каждый раз или запихнет где-то в память (как управляется ?) и просто будет вставлять в каждую последующую страничку ?

потихоньку пинаю хаскель\yesod (на удивление все «аккуратненько» — шаблонизатор с поддержкой вставок кода , автоматический ребилд

Yesod это template haskell, не совсем канонический, но удобный для веба. Кстати, они недавно получили спонсорскую поддержку, так что будут активнее развиваться.

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

Конечно, вычисляется каждый раз, суть pure function в том что она не дает сайд эффектов.

Для того, чтоб сделать то, что ты хочешь смотри www.haskell.org/...iki/Memoization.

esod это template haskell, не совсем канонический, но удобный для веба.
тут я немного не понял — вроде как шаблонизатор отдельный (хоть и часть yesod) ?
меня еще немного смутило требование явной «регистрации» в трех местах каждого контроллера (хандлера в yesod) ... т.е. есть скриптик, который автоматизирует, но вроде как неаккуратненько , многие вебфреймворки єту феньку предоставляют
Memoization.
о. это оно. спасибо
template haskell
впечатлила меня эта фича, это посерьезнее string expanding во всяких php, grails , да и относительно c++ templates/defines оно выглядит сурьезно

Смотри на Haskell, Clojure, Groovy — последний быстрее всего изучается, но Хаскелл интереснее будет.

вот начал читать про haskell но как-то меня смущает, что конструкция «where» позволяет объявить «подпрограммы» после кода, а let — перед вызывающим кодом :) ,

это как в математике «пускай переменная а будет» «let a be», или наборот как в физических формулах «F=ma, где m- масса тела, a — ускорение » «F=ma, where m-mass, a -acceleration»

Это на само деле удобно, надо привыкнуть или ты курсовые по физике не писал?

скорость

Хаскель генерится в С, с опцией -o компилятора может в определенных задачах выдавать скорость равную С. Если много ленивых вычислений то не будет, есть проблемы space leak из-за них.

взрослость системы

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

В Хаскелл есть замечательный вывод типов и поиск по образцу (pattern matching), который вносит ясность при чтении кода.

спасибо за качественный коммент :)

Groovy — последний быстрее всего изучается

гм. когда-то я на него «смотрел» в рамках grails , чет не заметил там функциональности ... хотя да с функциями там было что-то

это как в математике «пускай переменная а будет» «let a be», или наборот как в физических формулах «F=ma, где m- масса тела, a — ускорение » «F=ma, where m-mass, a -acceleration»

кстати да. теперь много проще

просто память мне «подкинула» что let похож на let из бейсика (вроде ?) а where больше из sql ...

ты курсовые по физике не писал?

нет. у меня только пять курсов статистики и около оной было :)

В Haskell либ завались на всякий вкус и цвет

ну я так понял хаскель не новодел , а достаточно взрослый «продукт»

гм. когда-то я на него «смотрел» в рамках grails , чет не заметил там функциональности
Grails это ж фреймворк, кстати очень хороший на мой взгляд. А функциональности там завались, особенно метасистема хороша.
Если тебе близка JVM среда, то смотри серию Functiona thinking от Нила Форда, www.ibm.com/...ional thinking
Самая первая часть:www.ibm.com/.../library/j-ft1

Он популярно рассказывает о функциональных примочках, на хабре есть перевод около 80% статей. Ищи в поиске.

просто память мне «подкинула» что let похож на let из бейсика (вроде ?) а where больше из sql ...
Математические метафоры лучше подходят для Haskell, where SQL это ж указание множества, а тут список переменных или объявления внутренних функций.

Языку вообще около 20 лет, его создатель работает в MS Research. Они одни из первых предложили интересные идеи для concurrency — Software Transactional Memory(STM). Конечно ноги изначально росли из академической среды, но где-то с 2006 года он очеловечился. Есть в США даже фирмы которые работают только с ним.

С Clojure другая фишка, его создатель Рич Хики, гениальный адаптатор, на мой взгляд, он сначала пытался в лисп подтянуть джаву, потом забил на 2 года ушел в проектирование. И получился диалект лиспа(отмечу не канонический — lisp-2) на JVM, в виде Сlojure. И теперь туда попадают лучшие идеи типа STM, но сообщество молодое, всего 5 лет, однако последние год очень активное.

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

Grails это ж фреймворк, кстати очень хороший на мой взгляд.

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

Если тебе близка JVM среда

как-то у меня с ней не сложилось :)

Справедливости ради, кодогенератор в С в Haskell (точнее, в GHC) скорее мертв, чем жив. Живы только native backend и llvm backend.

да, с 7й версии «deprecated», но если очень надо, то можно.

Сам пишу на Erlang.
Але я б не став його рекомендувати для написання веб-сайту. є фреймворки для цього але він ну зоввсім не для цього.
А веб-сервер — так.
Для початку можете попробувати розібратися з вебсервером cowboy — написаному на Ерланзі.

Якщо будуть запитання — звертайтеся.

можно попробовать clojure с интерестными задачками — 4clojure.org

Agda, если хочется занятся мастурбацией в присядку в противогазе.
Scala/Clojure если хочется написать что-то стоящее.

Haskell — для обучения ФП, возможно для стартапа.

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

От просто интересно:
Люди, которые рекомендуют Хаскелл, хоть одну строку на нем написали?

Или это как раньше Лисп: +100500 к ЧСВ и крутости коммента.

я могу книгу хорошую порекомендовать: 1593272839.pdf

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

Больше чем одну. Около 50 гдето

В продакшине Haskell и Clojure, части более крупного проекта, в виде библиотек к «бааальшому» java приложению, где-то по 5000 LoC каждый.

И таки да, я рекомендую и то и то другое, т.к вначале все писалось на java и было громоздко. Еще есть «скриптота» на Groovy на серверах, для выполнения системных тасков и билды на Gradle, но я им перестал заниматься уже месяцев 8 как.

Ребята из параллельной команды, пишут вообще на Scala, но их проект влили в фирму, так бы тоже Java была.

Особых проблем в таком «зоопарке» нет, т.к все на JVM поэтому логи общие и поддерживать можно нормально.

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

в доке хаскеля обещают, что если удалось скомпилиться :) то багов нет ... ггы

Я тоже читал такие заявы, но у меня в голове это никак не укладывается, типа если я по ошибке напишу + вместо * при вычислении факториала то прога не скомпилится?

ну ты как всегда, от таких ошибок ни один язык не спасет...

хаскел спасет от джунов:))) они быстро перегреются

хаскел спасет от джунов:)))

Хаскелисти рождаютсо синьорами?

я написал, как раз одну строку — сбацал функцию, которая каждую чётную букву в строке заменяет на точку :)

Без хаскеля вы не проникнетесь функциональщиной по-настоящему, монады, моноиды, функторы...

Эндофункторы, изоморзфим, хиломорфизм, катаморфизм, зигаморфизм, комонады, тайпклассы, монадные трансформеры наконец.

Один комбинатор неподвижной точки чего стоит.

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

Чисто для расширения сознания, задался тем же вопросом.
Скала — большой соблазн писать «как на джаве».
Руби — ООП

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

Про библиотеки. Оказывается что под любой язык их куча! На профильных ресурсах довольно легко найти или прямые сслыки или хоть ключевые слова.

Ну сознание можно и как-то вот так расширять: habrahabr.ru/post/148076

Скала — большой соблазн писать «как на джаве».
Руби — ООП

Тогда только pure functional Haskell, только хардкор :)

ЛИСПы, МЛи?

Большинство языков довольно гибкие в плане парадигм. Но у каждого есть основная. ИМХО, у Руби/Скала это ООП, а не ФП. ФП прикручивается, легко, но через очень явную призму ООП.

LISPы — это не только ФП, это еще, и весьма своеобразные возможности метапрограммирования, например.

А ML — вроде как в предках Haskell’а числится.

LISPы — это не только ФП, это еще, и весьма своеобразные возможности метапрограммирования, например.

Угу «и», в дополнение к функциональный. Могу ошибаться, но вся пьянка про ФП началась именно с него (от где хардкор).

А ML — вроде как в предках Haskell’а числится.

Предок Хаскелла — миранда, некоторые идеи которой были взяты из МЛ. Но Хаскелл — это НЕ развитие МЛ.

Да хаскелл — пюре. И шо? «Чистота идеи» хорошо в академических кругах. На практике же важно удобство и прозрачность идеи (это особо важно при «обучении»).

Угу «и», в дополнение к функциональный.

«мета» — возможности — это, в случае LISP’ов — не просто «и», это, как на мой вкус, как раз то из-за чего эта игра стоит хоть каких-то свеч.

Да хаскелл — пюре. И шо? «Чистота идеи» хорошо в академических кругах. На практике же важно удобство и прозрачность идеи (это особо важно при «обучении»).

В случае Haskell — на уровне «идей», опять же, как на мой вкус, все просто и прозрачно. Вот синтаксис как-то фигово в голову лезет, я поэтому его забросил: очень интересно, но, блин, каждый раз когда начинаешь что-то читать или пытаешься что-то сделать — приходится все вспоминать практически с нуля. У LISP’ов с этим сильно проще :)

>(((У) ((((LISP’ов с) этим) сильно) проще) :))

Очевидный фикс же.

Ерланг не чисто функциональный язык, и функциональная составляющая там не главное. И да, синтаксис унаследован от пролога.

А для настоящего расширения сознания с функторами, апплекативными функторами, монадами, алгебраическими типами, и черти чем еще — только хаскель %-)

а почему вы Питон забыли? Он тоже умеет ФП, как и почти все остальные парадигмы :)

а почему вы Питон забыли?
Потому что питон — это богомерзкий язык, который не погиб в пучине ада, потому что его оттуда выбросили. (где-то так :) )

Толсто. Кстати, ДОУ разве не на Питоне?

Кстати, ДОУ развве не на Питоне?

Шо и требовалось доказать.

Хаскель, только хаскель. Все остальное — паллиативы и половинчатые решения.

если задача изнасиловатьмозг функциональщиной, то рекомендуется таки заморочится с хаскелем, ибо он доставляет :-)

если хочется чегото практичного то скала/кложур.

F# / Objective Caml ещё — фенечек там куча, F# до кучи может использовать и не только свои фенечки а фенечки написанные на C#, IronPython и на говноязыке VB.NET

Если параллельно увлекаетесь некромантией то Nemerle

А какие фреймворки предлагается юзать для кложуры?

А разве нельзя в объектно ориентированном языке типа Java или C# писать в «функциональном стиле»?

И обычный Си он жеж вроде функциональный?

Обычный Си — процедурный.

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

Ну тогда — процедурный с элементами функциональщины.

Эт вам я ссылку на ГОбжект бросал?

Сам язык конечно же процедурный, но при желании превращается во что угодно (особо легко в брейнфак :) )

Ну это же не то... Кстати, Piet — должен расширить сознание так, что оно улетит в стратосферу.

PS: поздравляю с пачётным орденом троля.

ну судя по тому что хаскель генерит си код сначала (или может генерить, я еще не разобрался) то да — си это функциональный

Нед. С — процедурный, от того, что в нем мона пользовать разные парадигмы, он функециональным или объектным не становицца (вон Objective-C кучу лет транслировался именно в С, но С же не стал от этого объектным, не?). Другое дело, что в любом языке можно пользовать все парадигмы, только вот геморроя много больше, если язык под парадигму не предназначен.

та я собственно об єтом же

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

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

Тут оказалось что хаскелл компилитсо в Ц-код. То есть весь зоопарк что вы перечислили реализуетсо на Ц.
Не, так лучше:

лол, просто, лол!

О ты заработал язык! Поздравляю!

Больше того, ассемблер функциональнее С и любого языка во всех смыслах -))

Что уж говорить про машинный код...

можно, библиотека Functional Java для этого есть.

Під «функціональним програмуванням» мається наувазі зовсім інше, ніж під процедурним. Функціональне програмування включає в себе: розвинену і строгу систему типів, функції як first-class властивість мови (покажіть мені «функціональний літерал», лямбда-функцію, в Сі), можливість формувати функції на льоту (каррінг, часткове застосування), застосування map/fold/reduce/fliter для обробки масивів, а не звичайних циклів, чисті функції (про які відомо, що їх виконання не створює побічних ефектів, вхід повністю визначає вихід), іммутабельні значення (програмувати на С++, не змінюючи змінних, важко, а на Javа і взагалі неможливо, здається).

Весь цей бульйон створює поживне середовище, в якому стиль програмування змінюється до невпізнаванності для нефункціонального програміста, але це приносить з собою купу переваг.

Скала не достаточно странный.

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

ТС хочет такого шоб не было других вариантов (только функциональный, или 99% функциональщины).
да, вы правы

Лично у меня после ерланга, следующий окамл (к тому времени в макпортах должна появится версия 4, мо там шота интересное). На него еще __нормально__ не смотрел.

гм. фигурные скобочки — єто большой плюс, но jvm ...

В Haskell синтаксис можна використовувати як і in Python way (відступи), так і з Сі-подібними дужками і крапками з комою. Зазвичай користуються першим, зручніше. І взагалі, синтаксис Хаскеля часто приємний, хоч є багато любителів перевантажувати його зайвими значковими операторами. Наприклад, після Хаскеля в Ерлангу реально вибішує ставити крапку після кожної операції і не забувати про крапку з комою в потрібних місцях.

Подписаться на комментарии