LINUX.ORG.RU

Функциональщина. Что выбрать?


0

0

Решил в свободное время заняться изучением модного нынче функционального программирования. Встал естественный вопрос: что выбрать? Этих всяких лиспов, хацкелей, оцамлей и т.п. вагон и маленькая тележка. Чтобы не распыляться выбрал Scheme, т.к. его используют в SICP, но настораживает его не слишком большая распространённость и «академичность». С другой стороны, лямбды и прочие «вкусности» потихоньку приходят и во всякие там питоны и даже плюсы. Не холивара окаянного ради, а сугубо для просвещения и развития спрашиваю: что изучать, чтобы не лежало оно потом мёртвым грузом? У каких языков какие плюсы, минусы и области применения?

★★★★

Последнее исправление: Gvidon (всего исправлений: 1)
Ответ на: комментарий от Miguel

А я не обиделся. Ты же не живой человек, а просто буквы на экране. Тебя нет, на кого обижаться-то? Просто раньше я был готов подобные слова простить интересному виртуальному собеседнику, а теперь считаю это неправильным. В чистом остатке:

про хеш-таблицы ты не ответил
про масштабные проекты ты не ответил

И в общем, можешь уже не отвечать, потому что беседа с тобой окончена.

Для всех остальных - ещё одно преимущество лиспа. На обычных языках можно только писать программы. На лиспе можно создавать динамические среды. Например, можно в любой момент поменять определение функции или класса, не останавливая программу. Чем больше программа, тем важнее становится это свойство. В Лиспе оно существует «от роду», в Хаскеле или Окамле этого свойства нет, хотя в них и есть ограниченный REPL.

den73 ★★★★★
()
Ответ на: комментарий от Miguel

>Ещё раз, для таких, как ты: РЕЧЬ НЕ ШЛА.

Почему ты давишь на меня шифтом?

Помнится, тред начался с вопроса «а какая функциональщина у нас нынче поприкладнее будет?». Производительность и написанные на языке проекты/библиотеки — очень четко показывают на степень практичности ЯП. Например, сколько воя про эрланг, а на деле даже вменяемых биндингов к memcached нет.

Неинтересно, извини.

Иными словами, ты не готов обсуждать практическую применимость своего любимого языка, и в этом треде ты просто генерируешь информационную энтропию?

Тогда твоё сраное мнение в данной дискуссии никому не интересно.

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

linuxfan
()
Ответ на: комментарий от linuxfan

> Поделками на хацкиле не пользуюсь, ибо ничего нужного на нем попросту не пишут
Ну, это не совсем правда, на хаскеле написан darcs. И, кстати, хаскелевые программы работают быстро, см.

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=ghc&lang2=gcc

Ну и с тем же Питоном можно сравнить.

den73 ★★★★★
()
Ответ на: комментарий от jtootf

>а у меня вот Firefox почему-то сильней тормозит; неужели тоже из-за типизации?

Это потому что теперь «каждая домохозяйка может сделать свой сайт». Почему-то никому не приходит в голову, что css+html (javascript — отдельная песня, которой пока лучше не касаться) — это что-то вроде SQL: вроде бы и не язык программирования, но тормоза генерирует. Я намекаю на перегруженность и чрезмерно сложную верстку многих современных сайтов.

К примеру, весьма минималистичный лоровский интерфейс на этом же самом P IV вполне себе летает.

linuxfan
()
Ответ на: комментарий от den73

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

Да это на куче языков можно... в том же Питоне.

tailgunner ★★★★★
()
Ответ на: комментарий от linuxfan

Почему-то никому не приходит в голову, что css+html (javascript — отдельная песня, которой пока лучше не касаться) — это что-то вроде SQL: вроде бы и не язык программирования, но тормоза генерирует

почему же, приходит. я бы даже сказал, что это очевидно, что объём и плотность данных влияют на время обработки

К примеру, весьма минималистичный лоровский интерфейс на этом же самом P IV вполне себе летает.

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

jtootf ★★★★★
()
Ответ на: комментарий от den73

про хеш-таблицы ты не ответил

Я отвечал на более общий вопрос - об императивном алгоритме.

про масштабные проекты ты не ответил

На что именно, на то, в чём именно участвовал я? И не отвечу, не в персоналиях дело.

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

Да, горячий релоад - в Хаскеле вещь более сложная, хотя не невозможная (hs-plugins).

Miguel ★★★★★
()
Ответ на: комментарий от tailgunner

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

den73 ★★★★★
()
Ответ на: комментарий от den73

> Насколько я понял, там нельзя переопределить функцию

Можно. Попробуй сам в REPL.

Но самое главное - питон намного медленнее лиспа

Ну будет он чере пару лет на уровне Си, и что?

и в нём нет макросов.

Смотря каких, смотря зачем.

Но это всё оффтоп.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Пойнт в том, что считать это каким-то выдающимся преимуществом Лиспа просто смешно.

*голос из зала* и в Erlang можно!

это я к тому, что поинт вполне прозрачен

jtootf ★★★★★
()
Ответ на: комментарий от linuxfan

Почему ты давишь на меня шифтом?

Может, хоть так дойдёт.

Помнится, тред начался с вопроса «а какая функциональщина у нас нынче поприкладнее будет?».

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

Иными словами, ты не готов обсуждать практическую применимость своего любимого языка, и в этом треде ты просто генерируешь информационную энтропию?

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

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

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

Miguel ★★★★★
()
Ответ на: комментарий от den73

Если бы у лиспа был вменяемый синтаксис

то им бы никто не пользовался

jtootf ★★★★★
()
Ответ на: комментарий от den73

>Ну, это не совсем правда, на хаскеле написан darcs.

Как известно шире всего darcs используется на common-lisp.net. Не сказал бы, чтобы он мне хоть раз понадобился за пределами лиспового «фофанья».

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

linuxfan
()
Ответ на: комментарий от anonymous

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

обобщенная декларативная итерация по произвольному числу аргументов.

Эээ. Не лиспер. Навкидку, если я правильно понял задачу, нужно писать что-то примерно такое такое.

import Data.List

s_iter:: (a->Bool) -> (a-> a) -> a-> a -- ^ эта функция итеративно трансформирует последний аргумент, пока результат не будет соответствовать предикату. Сделано это <s>через жопу </s> путём генерации бесконечного списка трансформаций, из которого берётся первый элемент, удовлетворяющий предикату. s_iter p t i = head $ filter p $ iterate t i

ap_ps:: a -> [a-> Bool] -> Bool -- ^ адаптер, пакующий несколько предикатов в один ap_ps a ps = and $ map ($ a) $ ps

ap_ts :: a -> [a->a] -> a --^ адаптер, пакующий несколько трансформаций в одну ap_ts a t:ts = ap (t a) ts ap_ts a [] = a

c_iter:: [a-> Bool] -> [a-> a] -> a -> a -- ^ конструируем обобщение по числу трансформаций и предикатов. s_iter ps ts = s_iter ( `ap_ps` ps) (`ap_ts` ts)

Дисклеймер: накатано на коленке в течении 5 минут, в компилере не тестировалось. до удобочитабельного и рабочего состояния доводить откровенно лень.

anonymous
()
Ответ на: комментарий от jtootf

>думаю, что если бы в портаже было два-три пакета, он бы тоже летал. нет, у тебя очень серьёзные аргументы, правда

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

linuxfan
()
Ответ на: комментарий от linuxfan

Как известно шире всего darcs используется на common-lisp.net

ого. а пруфлинк можно?

jtootf ★★★★★
()
Ответ на: комментарий от linuxfan

На практике дистрибутив, в котором всего два-три пакета звучит как-то противоестественно

не более противоестественно, чем браузер, расчитанный на работу исключительно с ЛОР-style сайтами (если он, конечно, не текстовый)

jtootf ★★★★★
()
Ответ на: комментарий от tailgunner

>Ну будет он чере пару лет на уровне Си, и что?

Наверное, ты хотель сказать: «Через пару лет появятся такие компьютеры, на которых питон будет выполняться с такой же скоростью, с какой выполняется скомпилированный сишный код на сегодняшних»?

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

linuxfan
()
Ответ на: комментарий от linuxfan

Хочу сравнить надёжность кода с generic стеками на plain c и stl stack. По скорсти оно более-менее монопенисуально, но в plain c нужно руками следить за тем, что со стеком работают правильно, а для других обобщённых функций ещё и придётся таскать руками словарь для работы с объектами из стека. В случае c++ за тебя всё сделает система шаблонов, которая здесь используется как средство привнести параметризованный тип в язык. Не лучший способ, но на безрыбье...

anonymous
()
Ответ на: комментарий от Miguel

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

Я полагаюсь на авторитетное мнение дядьки Грэма, который говорил, что если босс запрещает вам лисп, но очень хочется, тогда следует взять питон.

linuxfan
()
Ответ на: комментарий от linuxfan

>Наверное, ты хотель сказать: «Через пару лет появятся такие компьютеры, на которых питон будет выполняться с такой же скоростью, с какой выполняется скомпилированный сишный код на сегодняшних»?

А не компиляция ли сиплюсплюсного рака занимает 99% времени инсталляции пакетов в системе Gentoo?

Absurd ★★★
()
Ответ на: комментарий от linuxfan

> Наверное, ты хотель сказать: «Через пару лет появятся такие компьютеры, на которых питон будет выполняться с такой же скоростью, с какой выполняется скомпилированный сишный код на сегодняшних»?

Нет, я хотел сказать, что допинают либо PyPy, либо Unladen Swallow, либо еще что-нибудь.

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

Что такое «скриптовые языки»? Динамически типизированные? Лисп, Смолток и Пролог использовались для вполне прикладных задач еще до PC.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

>Хочу сравнить надёжность кода с generic стеками на plain c и stl stack.

Я элегантно задаю тебе направляющий вектор, указывающий на детсад, в котором тебе пояснят, почему C++ ни разу не динамически типизированный язык.

В мире вообще довольно мало вещей, для которых не хватает C и действительно нужен C++.

linuxfan
()
Ответ на: комментарий от den73

>>И, кстати, хаскелевые программы можно писать так. что они будут работать быстро, см.

fixed. И на читабельности это зачастую сказывается не лучшим образом.

anonymous
()
Ответ на: комментарий от linuxfan

> демонстрировалось место хаскеля в вычислениях по сравнению с icc. Было что-то вроде «питон против си на рекурсивном вычислении чисел фибоначчи»

Если это так - я рад :) Хотя я всё же считаю, что лучше какие-то бенчмарки, чем вообще никаких. И что поставленные на шутауте задачи достаточно хороши, чтобы можно было судить. Кстати, и на шутауте мы видим, что Хаскель сливает С, при всех оттопыренных пальцах, а можно ещё сравнить с плюсами и слив будет сильнее. Но питон сливает просто эпически (кстати, и Схема тоже там рядом). Относительно быстрых языков ФП я знаю три: окамль, хаскель, коммон лисп - примерно в таком порядке по быстродействию.

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

Насчёт питона - попробую. Хотя вроде уже один раз пробовал. Может, неправильно пробовал :)

А, вот кстати, может быть, можно посоветовать для развлечения clojure. Это - достаточно современный язык с сильным упором на ФП. Для тех, кто фанатеет именно от ФП, clojure - лучше чем CL. Поскольку он на Ява-платформе, а серверная Ява-платформа быстра (если верить тому же шутауту), clojure может оказаться языком с хорошим будущим.

den73 ★★★★★
()
Ответ на: комментарий от anonymous

И на читабельности это зачастую сказывается не лучшим образом.

любые нетривиальные оптимизации плохо сказываются на читабельности. везде и всегда

jtootf ★★★★★
()
Ответ на: комментарий от linuxfan

Я никак не могу понять, какую точку зрения ты отстаиваешь.

Что Питон - хорошая вещь? Никто особо не спорит, если добавить оговорку «на своём месте».

Что Питон является функциональным языком? Это неверно.

Что Питон тормоз? Опять же, и так всем известно.

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

Что я не интересуюсь скоростью работы программ? Интересуюсь.

Сформулируй какую-нибудь позицию, а то непонятно.

Miguel ★★★★★
()
Ответ на: комментарий от Absurd

>А не компиляция ли сиплюсплюсного рака занимает 99% времени инсталляции пакетов в системе Gentoo?

Nope. Firefox собирается за 20-30 минут. 40% времени инсталяции нынче занимает make menuconfig, если не пользовать genkernel.

Собственно, плюсовый рак кроме firefox/webkit/opera не нужен.

linuxfan
()
Ответ на: комментарий от Miguel

> Что статическая типизация хороша даже без вывода типов и полиморфизма? Приведи аргументы, имея при этом в виду, что, кроме скорости, есть и другие параметры.

Анонимный брат запостил хорошую цитату SPJ.

tailgunner ★★★★★
()
Ответ на: комментарий от linuxfan

В мире вообще довольно мало вещей, для которых не хватает C и действительно нужен C++.

Гм. Таких вещей вообще нет, поскольку для любой вещи найдётся язык, более подходящий, чем C++. Так что он «действительно нужен» вообще нигде.

Miguel ★★★★★
()
Ответ на: комментарий от linuxfan

Ну т. е. пойнта ты не понял. А был он не в моих частных предпочтениях статики без веских причин на обратное, а в необходимоти полиморфизма для комфортного программирования в статике.

anonymous
()
Ответ на: комментарий от den73

Писать в стиле ФП можно на любом языке, вопрос - насколько это будет неудобно.

Если ты один - можно.

А если рядом с тобой сидит другой, то что именно он напишет и как это будет расходиться с твоим пониманием функциональности, в Лиспах или Питонах не контролируется.

Miguel ★★★★★
()
Ответ на: комментарий от tailgunner

>Нет, я хотел сказать, что допинают либо PyPy, либо Unladen Swallow, либо еще что-нибудь.

Современные реалии таковы, что более вероятно дождаться нового сверхбыстрого железа, чем серьезной оптимизации быдлокода. Что-нибдь толковое выйдет разве что если какой-нибудь llvm или CLR приплетут, но железоподобные питоны в такой же, прости Господи, жопе, в какой они были 5 лет назад.

Лисп, Смолток и Пролог использовались для вполне прикладных задач еще до PC.

Да, только делали это не отвергнутые в ПТУ быдлокодеры, а ученые, которые десять раз думали, прежде чем написать. Ну и объемы данных были совсем другие, что тоже немаловажно.

linuxfan
()
Ответ на: комментарий от linuxfan

> Был как-то тред, на котором наглядно демонстрировалось место хаскеля в вычислениях по сравнению с icc

Это ты про тот эпичный тред с твоими фантазиями на тему «icc заруливает gcc в 6 раз, а окамл — в 36»? Так там ничего, кроме фантазий, и не дождались... Ну, если не считать «я там где-то лет 10 назад на каком-то сайте читал, что icc рвёт gcc как тузик грелку, но мне лень искать»

kemm
()
Ответ на: комментарий от den73

>clojure может оказаться языком с хорошим будущим.

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

linuxfan
()
Ответ на: комментарий от linuxfan

>>А не компиляция ли сиплюсплюсного рака занимает 99% времени инсталляции пакетов в системе Gentoo?

Nope.

Ну, чтобы исключить затраты на комплиляцию пакетов нужно сравнивать yum и apt-get.

Absurd ★★★
()
Ответ на: комментарий от linuxfan

>Поделками на хацкиле не пользуюсь, ибо ничего нужного на нем попросту не пишут, а то бы был повод и в его сторону кинуть камень. Хотя, в принципе, его уже за один bf-подобный синтаксис закопать стоит.

Интересно, как люди выставляют свое невежество напоказ...

Waterlaz ★★★★★
()
Ответ на: комментарий от Miguel

>Сформулируй какую-нибудь позицию, а то непонятно.

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

Если den73 захочет возразить, то советую ему попробовать cl-sql биндинг для лиспа. Выглядит невероятно вкусно, но какой 3.14 начинается, стоит столкнуться с «не-ascii» данными.

linuxfan
()
Ответ на: комментарий от linuxfan

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

И что? Это относится к быдлокоду на любом языке.

железоподобные питоны

Что за звери?

Лисп, Смолток и Пролог использовались для вполне прикладных задач еще до PC.

Да, только делали это не отвергнутые в ПТУ быдлокодеры, а ученые

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

Ну и объемы данных были совсем другие, что тоже немаловажно.

Теперешние объемы было просто негде хранить.

/me .oO( мля, я защищаю динамически типизированные языки )

tailgunner ★★★★★
()
Ответ на: комментарий от linuxfan

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

Ага. Так. Теперь в какую из этих категорий относится Хаскель?

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

>Таких вещей вообще нет, поскольку для любой вещи найдётся язык, более подходящий, чем C++

То-то я так и не увидел ни одного UI-тулкита, написанного не на C/C++. Кругом одни биндинги. Хотя, нет, есть же еще swing на Java.

linuxfan
()
Ответ на: комментарий от anonymous

>А был он не в моих частных предпочтениях статики без веских причин на обратное, а в необходимоти полиморфизма для комфортного программирования в статике.

В C есть универсальный способ для generic-алгоритмов. Несколько неэффективный, небезопасный, зато действительно универсальный: void*. С одной стороны ужасно, с другой стороны, единожды отведав хардкорных плюсовых template<>, приходит понимание, что void* имеет свои плюсы.

linuxfan
()
Ответ на: комментарий от linuxfan

>То-то я так и не увидел ни одного UI-тулкита, написанного не на C/C++.

И при этом UI-шная логика совершенно отвратительно ложится на С и С++.

Absurd ★★★
()
Ответ на: комментарий от kemm

>icc заруливает gcc в 6 раз, а окамл — в 36

Ну зарулил gcc в два или три раза, а окамль раз в 5-6. Ты подумай о том, что вместо одной минуты результатов пришлось бы ждать шесть, а то абстрактное «шесть раз» ты как-то не воспринимаешь.

linuxfan
()
Ответ на: комментарий от Waterlaz

>Интересно, как люди выставляют свое невежество напоказ...

Невежество и неосведомленность в силу объективных причин — это разные вещи. Ну не буду я ни за какие блага xmonad на десктопе использовать.

linuxfan
()
Ответ на: комментарий от linuxfan

И какое отношение cl-sql имеет к «функциональщине»? И, кстати, что cl-sql та ещё библиотека кажется уже всё давно знают и никто ей пользуется.

archimag ★★★
()
Ответ на: комментарий от linuxfan

>Ну зарулил gcc в два или три раза, а окамль раз в 5-6. Ты подумай о том, что вместо одной минуты результатов пришлось бы ждать шесть, а то абстрактное «шесть раз» ты как-то не воспринимаешь.

емнип gcc отработал на 20% быстрее окамла. И что-то там с icc было тоже далеко даже не в 1,5 раза быстрее gcc..

Waterlaz ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.