функциональщина :)
вот захотелось мне развлечься немного и разучить какое-нить функциональное язычие.
но вот выбор меня немного смутил — их много и каждый хвалят-ругают :)
в общем, что интересует:
— читабельность кода , а то вот начал читать про haskell но как-то меня смущает, что конструкция «where» позволяет объявить «подпрограммы» после кода, а let — перед вызывающим кодом :) , я заглянул в либы идущие с компилятором, там это усугубляется ... хотя может это я балованный
— скорость
— взрослость системы, условно говоря , если я хочу написать, ну пусть веб-сайт, все либы и фреймворки должны быть уже написаны и работать более-менее сносно — т.е. всякие феньки типа ajax или там интеграция с memcached должна уже быть
— поддержка всяких фенечек, типа message passing и т.д.
я понимаю что вопрос спорный, так что прошу отвечать более менее информативно — что именно пользовали и как ощущения
119 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів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 если что
А не кажется что 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) но несколько коряво исполненные
я вот смотрел с точки зрения веба и прямо видел, как бородатые пшд , писавшие код, когда еще мышек не было, вдруг решили написать веб фреймворк, и начали сочинять велосипеды и наступать на все грабли какие найдут, например решили, что сессии лучше хранить в кукисах (типа сэкономим одно обращение к базе\кешу но позволим нормально маштабироваться) ну и т.д.
А от у Скали, наскільки я знаю, синтаксис обтяженіший деталями, більш традиційний.
Якщо хочеться справді нової і консистентної мови, то вибір однозначно Хаскель)
Хаскель даж попроще в этом плане будет.
А еще TaPL?
Ну и Lambda the ultimate
Это все мифы.
1. Такая штука, как «само функциональное программирование», практически не существует. *Идиоматичный* код на разных языках выглядит часто очень по-разному.
Например: циклы в Scheme — рекурсия, в Haskell — комбинаторы вроде map и fold, в Lisp (который с натяжкой можно назвать функциональным) — свой собственный DSL.
2. Для программирования на ФЯП знание лямбда-исчисления абсолютно не обязательно. Вы будете сталкиваться с простейшими концепциями типа лямбда-функций и карирования, но все это объясняется за десять минут и относится к лямбда-исчислению примерно так же, как подсчет сдачи в магазине относится к матанализу.
3. Функциональные структуры данных — это уже высший пилотаж. Советовать это начинающему функциональщику — все равно что советовать начинающему программисту Кнута.
Но трандеть про монады — это ж прикольнее чем работать ;)
Да и ЧСВ возростает.
«Триндіти про структуризацію програми краще, ніж працювати»
Монади — це лише спосіб структурувати програму, який має застосовуватись, коли для нього є передумови і коли він починає сам напрошуватись.
Если подходить к ним как к моноидам в категории эндофункторов, то, конечно, сложны. Поэтому я против запугивания новичков теоркатом и прочей хардкорной теорией.
Монады как практический инструмент не сложнее, скажем, указателей или наследования. Просто еще одна концепция, которую надо освоить. Другое дело, что многие считают, что все возможные концепции они изучили еще в институте, а монады — это то, что они и так используют в C++ или jQuery, только по-сложному объясненное.
Чтобы хранить состояние, достаточно использовать монаду State (или, в общем случае, включить State в ваш стек монадных трансформеров).
Для меня главное преимущество Хаскеля (из которого следуют много других) перед — это статическая типизация и сильная и выразительная система типов. Благодаря ей возможны такие вещи, как монады, которые значительно упрощают программирование. Благодаря ей возможно создание простых и удобных API, которые сложно использовать неправильно. Благодаря ей решение задачи удобно разбивать на две подазадачи: объявление «языка», соответствующего предметной области, и выражении задачи на этом языке.
Ну и приятный и гибкий синтаксис в придачу.
да, именно так
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-потоки, которые создаются автоматически по мере надобности.
ну я где-то так и понял, вобщем для меня главное что создатели хаскеля об этом позаботились
Как то уж категорично. Цитата с офф.дока:
Как то не стыкуется, речь о 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.
но вот крутится вопрос, который я пока не могу сформулировать «в гугль», в общем есть pure functions , классно, в гайдах упоминается что их можно вычислить один раз и все, так вот — будет ли система кешировать их автоматически или надо указывать ручками, ну т.е. например, есть функция которая возвращает футер странички (ну там шаблоны всякое разное, но по сути получается какой-нить getFooter) — так вот — будет ли система вычислять его каждый раз или запихнет где-то в память (как управляется ?) и просто будет вставлять в каждую последующую страничку ?
Yesod это template haskell, не совсем канонический, но удобный для веба. Кстати, они недавно получили спонсорскую поддержку, так что будут активнее развиваться.
Конечно, вычисляется каждый раз, суть pure function в том что она не дает сайд эффектов.Для того, чтоб сделать то, что ты хочешь смотри www.haskell.org/...iki/Memoization.
меня еще немного смутило требование явной «регистрации» в трех местах каждого контроллера (хандлера в yesod) ... т.е. есть скриптик, который автоматизирует, но вроде как неаккуратненько , многие вебфреймворки єту феньку предоставляют о. это оно. спасибо
Смотри на Haskell, Clojure, Groovy — последний быстрее всего изучается, но Хаскелл интереснее будет.
это как в математике «пускай переменная а будет» «let a be», или наборот как в физических формулах «F=ma, где m- масса тела, a — ускорение » «F=ma, whereЭто на само деле удобно, надо привыкнуть или ты курсовые по физике не писал?
Хаскель генерится в С, с опцией -o компилятора может в определенных задачах выдавать скорость равную С. Если много ленивых вычислений то не будет, есть проблемы space leak из-за них.
В Haskell либ завались на всякий вкус и цвет, разве что для новых БД приходится свои драйвера писать, в виде оберток на Сшными. В Сlojure много хипстерских вещей(читай не нужных и понтовых), вот там приходится много самому писать, но сообщество развивается.
В Хаскелл есть замечательный вывод типов и поиск по образцу (pattern matching), который вносит ясность при чтении кода.
спасибо за качественный коммент :)
гм. когда-то я на него «смотрел» в рамках grails , чет не заметил там функциональности ... хотя да с функциями там было что-то
кстати да. теперь много прощепросто память мне «подкинула» что let похож на let из бейсика (вроде ?) а where больше из sql ...
нет. у меня только пять курсов статистики и около оной было :)
ну я так понял хаскель не новодел , а достаточно взрослый «продукт»
Если тебе близка JVM среда, то смотри серию Functiona thinking от Нила Форда, www.ibm.com/...ional thinking
Самая первая часть:www.ibm.com/.../library/j-ft1
Он популярно рассказывает о функциональных примочках, на хабре есть перевод около 80% статей. Ищи в поиске.
Математические метафоры лучше подходят для Haskell, where SQL это ж указание множества, а тут список переменных или объявления внутренних функций.Языку вообще около 20 лет, его создатель работает в MS Research. Они одни из первых предложили интересные идеи для concurrency — Software Transactional Memory(STM). Конечно ноги изначально росли из академической среды, но где-то с 2006 года он очеловечился. Есть в США даже фирмы которые работают только с ним.
С Clojure другая фишка, его создатель Рич Хики, гениальный адаптатор, на мой взгляд, он сначала пытался в лисп подтянуть джаву, потом забил на 2 года ушел в проектирование. И получился диалект лиспа(отмечу не канонический — lisp-2) на JVM, в виде Сlojure. И теперь туда попадают лучшие идеи типа STM, но сообщество молодое, всего 5 лет, однако последние год очень активное.
Вообще неважно какой ФЯП ты будешь курить, это как другой взгляд на мир, для понимания целостности картины очень полезно, пускай ты даже много не напишешь.
Мне лично нравится, но в реальном мире это гибридный подход обычно.
ну в то время когда я на него смотрел, он меня не впечатлил — нет, вроде все на первый взгляд красиво и аккуратно, но при попытке сделать чет реальное посыпались глюки, что-то я забагрепортил, что-то пофиксил сам, но потом подумал, зачем нужен такой фреймворк который приходится фиксить перед работой с ним :)
как-то у меня с ней не сложилось :)
Справедливости ради, кодогенератор в С в Haskell (точнее, в GHC) скорее мертв, чем жив. Живы только native backend и llvm backend.
да, с 7й версии «deprecated», но если очень надо, то можно.
Але я б не став його рекомендувати для написання веб-сайту. є фреймворки для цього але він ну зоввсім не для цього.
А веб-сервер — так.
Для початку можете попробувати розібратися з вебсервером cowboy — написаному на Ерланзі.
Якщо будуть запитання — звертайтеся.
можно попробовать clojure с интерестными задачками — 4clojure.org
Scala/Clojure если хочется написать что-то стоящее.
Haskell — для обучения ФП, возможно для стартапа.
гм. всем спасибо — буду разбираться с хаскелем, тем более что можно глянуть в получаемый си-код :)
Люди, которые рекомендуют Хаскелл, хоть одну строку на нем написали?
Или это как раньше Лисп: +100500 к ЧСВ и крутости коммента.
я могу книгу хорошую порекомендовать: 1593272839.pdf
впринципе «официальные» гайды вполне себе разумные .. ага. нагуглил — читаю его же, переодически подглядывая в «большой»
Больше чем одну. Около 50 гдето
В продакшине Haskell и Clojure, части более крупного проекта, в виде библиотек к «бааальшому» java приложению, где-то по 5000 LoC каждый.
И таки да, я рекомендую и то и то другое, т.к вначале все писалось на java и было громоздко. Еще есть «скриптота» на Groovy на серверах, для выполнения системных тасков и билды на Gradle, но я им перестал заниматься уже месяцев 8 как.
Ребята из параллельной команды, пишут вообще на Scala, но их проект влили в фирму, так бы тоже Java была.
Особых проблем в таком «зоопарке» нет, т.к все на JVM поэтому логи общие и поддерживать можно нормально.
Багов не деплоим!!!111
Балаболы
в доке хаскеля обещают, что если удалось скомпилиться :) то багов нет ... ггы
Я тоже читал такие заявы, но у меня в голове это никак не укладывается, типа если я по ошибке напишу + вместо * при вычислении факториала то прога не скомпилится?
ну ты как всегда, от таких ошибок ни один язык не спасет...
А от каких спасет?
Хаскелисти рождаютсо синьорами?
я написал, как раз одну строку — сбацал функцию, которая каждую чётную букву в строке заменяет на точку :)
Эндофункторы, изоморзфим, хиломорфизм, катаморфизм, зигаморфизм, комонады, тайпклассы, монадные трансформеры наконец.
Эзотеричненько
Скала — большой соблазн писать «как на джаве».
Руби — ООП
Сейчас сморю на ерланг. Немного странный язык, как-то уж очень похоже на логическое, а не функциональное программирование. И сам язык, пока, «не цепляет».
Про библиотеки. Оказывается что под любой язык их куча! На профильных ресурсах довольно легко найти или прямые сслыки или хоть ключевые слова.
Ну сознание можно и как-то вот так расширять: habrahabr.ru/post/148076
Тогда только pure functional Haskell, только хардкор :)
Большинство языков довольно гибкие в плане парадигм. Но у каждого есть основная. ИМХО, у Руби/Скала это ООП, а не ФП. ФП прикручивается, легко, но через очень явную призму ООП.
LISPы — это не только ФП, это еще, и весьма своеобразные возможности метапрограммирования, например.
А ML — вроде как в предках Haskell’а числится.
Угу «и», в дополнение к функциональный. Могу ошибаться, но вся пьянка про ФП началась именно с него (от где хардкор).
Предок Хаскелла — миранда, некоторые идеи которой были взяты из МЛ. Но Хаскелл — это НЕ развитие МЛ.
Да хаскелл — пюре. И шо? «Чистота идеи» хорошо в академических кругах. На практике же важно удобство и прозрачность идеи (это особо важно при «обучении»).
«мета» — возможности — это, в случае LISP’ов — не просто «и», это, как на мой вкус, как раз то из-за чего эта игра стоит хоть каких-то свеч.
В случае Haskell — на уровне «идей», опять же, как на мой вкус, все просто и прозрачно. Вот синтаксис как-то фигово в голову лезет, я поэтому его забросил: очень интересно, но, блин, каждый раз когда начинаешь что-то читать или пытаешься что-то сделать — приходится все вспоминать практически с нуля. У LISP’ов с этим сильно проще :)
>(((У) ((((LISP’ов с) этим) сильно) проще) :))
Очевидный фикс же.
Ерланг не чисто функциональный язык, и функциональная составляющая там не главное. И да, синтаксис унаследован от пролога.
А для настоящего расширения сознания с функторами, апплекативными функторами, монадами, алгебраическими типами, и черти чем еще — только хаскель %-)
а почему вы Питон забыли? Он тоже умеет ФП, как и почти все остальные парадигмы :)
Толсто. Кстати, ДОУ разве не на Питоне?
Шо и требовалось доказать.
если хочется чегото практичного то скала/кложур.
Если параллельно увлекаетесь некромантией то Nemerle
А какие фреймворки предлагается юзать для кложуры?
И обычный Си он жеж вроде функциональный?
лол, просто лол.
Обычный Си — процедурный.
Указатели на функции, да и указатели вообще, превращают его в функциональный (или любой другой) язык с динамической типизацией. :)
Ну тогда — процедурный с элементами функциональщины.
Сам язык конечно же процедурный, но при желании превращается во что угодно (особо легко в брейнфак :) )
Ну это же не то... Кстати, Piet — должен расширить сознание так, что оно улетит в стратосферу.
PS: поздравляю с пачётным орденом троля.
ну судя по тому что хаскель генерит си код сначала (или может генерить, я еще не разобрался) то да — си это функциональный
Нед. С — процедурный, от того, что в нем мона пользовать разные парадигмы, он функециональным или объектным не становицца (вон Objective-C кучу лет транслировался именно в С, но С же не стал от этого объектным, не?). Другое дело, что в любом языке можно пользовать все парадигмы, только вот геморроя много больше, если язык под парадигму не предназначен.
та я собственно об єтом же
А лямбда-функції, а чисті функції, а каррінг, а замикання, а продовження, а монади, а іммутабельність, а композиція функцій?!..
Тут оказалось что хаскелл компилитсо в Ц-код. То есть весь зоопарк что вы перечислили реализуетсо на Ц.Не, так лучше:
лол, просто, лол!
О ты заработал язык! Поздравляю!
Что уж говорить про машинный код...
Прочитайте всю ветку.
можно, библиотека Functional Java для этого есть.
Весь цей бульйон створює поживне середовище, в якому стиль програмування змінюється до невпізнаванності для нефункціонального програміста, але це приносить з собою купу переваг.
scala
При желании на любом языке можно писать в функциональном стиле, как я понял, ТС хочет такого шоб не было других вариантов (только функциональный, или 99% функциональщины).
Лично у меня после ерланга, следующий окамл (к тому времени в макпортах должна появится версия 4, мо там шота интересное). На него еще __нормально__ не смотрел.
гм. фигурные скобочки — єто большой плюс, но jvm ...
В Haskell синтаксис можна використовувати як і in Python way (відступи), так і з Сі-подібними дужками і крапками з комою. Зазвичай користуються першим, зручніше. І взагалі, синтаксис Хаскеля часто приємний, хоч є багато любителів перевантажувати його зайвими значковими операторами. Наприклад, після Хаскеля в Ерлангу реально вибішує ставити крапку після кожної операції і не забувати про крапку з комою в потрібних місцях.