LINUX.ORG.RU

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


0

0

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

★★★★

Последнее исправление: Gvidon (всего исправлений: 1)

Ответ на: комментарий от postrediori

> Все эти языки очень похожи по синтаксису и возможностям (+- всякие вкусности).

Судя по всему ты видел эти языки только в статьях википедии, иначе не нес бы подобную чушь. Haskell и CL очень сильно разные, как по синтаксису, так и по семантике.

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

> В один ряд хаскель с руби ставить - это таки ппц.

ЗЫ это такой троллинг что-ли?

Извините уж, слишком долго C/C++/FORTRAN использовал (знаю, пора выходить из анабиоза).
Другие языки не очень-то воспринимал. Просто смотрел, как обычные алгоритмы на них выглядят (факториал посчитать, алгоритм Дейкстры и др.) Поэтому сильных отличий заметить не успел.
Если же у Вас есть длительный опыт работы с хаскелем/руби/лиспом, то куда мне с Вами тягаться?..

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

Та не сравниваю я Великий Lisp и его отпрыска CL с другими языками! И ежу понятно, что Lisp, на котором писали ещё в 70-е и творения 90-х - это разные вещи. Я просто сказал, что если выбирать язык «просто для себя», то это вопрос личных предпочтений.

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

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

Ну т.е. можно смело сказать, что ни хаскелль, ни общелисп в глаза не видел.

Если же у Вас есть длительный опыт работы с хаскелем/руби/лиспом, то куда мне с Вами тягаться?..

Не знаю, зачем тогда тягаешься?

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

>Не знаю, зачем тогда тягаешься?
Я то думал , что на форуме LORа людям советуют, что лучше, что хуже; помогают; идеями делятся; всеми силами приближают светлое будущее в этом гразном капиталистическом мире и т.д. и т.п. и др. (сайт ведь в честь свободной ОС называется)
А тут собрались фанаты Lisp'а и тупо отстаивают свой язык.
Как печально.

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

>Я то думал , что на форуме LORа людям советуют, что лучше, что хуже; помогают; идеями делятся; всеми силами приближают светлое будущее в этом гразном капиталистическом мире и т.д. и т.п. и др.

ВНЕЗАПНО! Тут занимаются не только этим.

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

[quote] I think we may have made a mistake in thinking that hackers are turned off by Lisp's strangeness. This comforting illusion may have prevented us from seeing the real problem with Lisp, or at least Common Lisp, which is that it sucks for doing what hackers want to do. A hacker's language needs powerful libraries and something to hack. Common Lisp has neither. A hacker's language is terse and hackable. Common Lisp is not. [/quote]

Если CL не хакабле, то что тогда хакабельнее. Это комплимент Common Lisp ? Наоборот задолбало хакерствовать, хочется уже промышленной зрелости. Хотя то что предлагает Franz или XAnalys достаточно зрелое, в последнем наконец появилась поддежка GTK+ под Linux, последнее уродство (Motif) устранено.

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

> Вот какого чёрта в Scheme имя функции по дурацкому соглашению — просто первый элемент в строке термов, никак не выделенный от своих аргументов? Как это хоть сколько-нибудь отвечает парадигме? Это лишь привносит путаницу.

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

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

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

Затем что это смотрится приемлемо лишь для функции одного аргумента.

(a b) #тут умножение явно отвечает операции аппликации

(a b c d) #тут по соглашениям применяется группировка влево и запись надо понимать как (((a b) c) d). Видно что отношения между a и b неравносильно отношению между b и c, хотя в исходном вырадении записано одинаково — умножением.

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

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

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

> Отделение функции от аргументов графически не нарушило бы функциональный подход и никого не оскорбило бы «приближением к си».

а при чем тут функциональный подход? лисп (во всяком случае CL и Scheme) давно не является воплощением функциональшины и в равной степени предоставляет возможность писать императивно.

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

а выражение

(a b c d)

надо понимать как

(apply a (list b c d))

и никак иначе...

и если уж группировать попарно, то только так:

(a . (b . (c . (d . nil))))

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

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

о какой роли речь? чем функция принципиально отличается от аргумента? в ФП по большому счету ничем.

какой смысл менять

map sin [1..10]

на

map( sin(), [1..10] )

?

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

> Промышленная зрелость — это UML, IDEF, RDP и PMBOK, да.

IMHO - это как Пролог для ИИ, безусловно неплохо подходит к широкому кругу задач ИИ, но как таковой ИИ на нем не построишь, сколько усилий не прилагай. Если все это применять на любой проект, то 80% сдохнет не начавшись.

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

>Обратил внимание на число комментов и срочно пишу коммент номер 667.

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

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

Я вот тут придумал, как бы ещё вскрыть гнилую сущность ФП. Вот такая метафора предлагается.

Императивное программирование похоже на чёрную доску, мел и тряпку.
Функциональное программирование похоже на стопку бумаги и чернила. Вполне ясно, что с точки зрения эффективности, гибкости и ресурсоёмкости чёрная доска лучше. С точки зрения точности, может быть, лучше бумага. В общем, не похоже, что моя метафора выражает моё (плохое) отношение к чистому ФП, но раз уж я её придумал, что ж, оставить её при себе? Нет уж!

А вообще, конечно же, ясно, что КТО-ТО делает всё, чтобы не дать информационным технологиям развиваться достаточно быстро и свободно. Кто-то придумывает ненужные и вредоносные идеи (такие, как ООП или монады), продвигает их силой власти и денег, отделяет одни идеи от других и противопоставляет их друг другу, хотя на самом деле правильные идеи, как правило, совместимы между собой. Я не думаю, что дело здесь просто в зарабатывании денег. Деньги, по большому счёту - это всего лишь инструмент. Речь идёт, видимо, о власти над миром, и недаром из символики разных программных продуктов торчат то какие-то сомнительные рога, то глаз в пирамиде. Было, правда, одно исключение - Sun, вроде и название солнечное, и свастику не побоялись нарисовать, и операционку солярисом назвали. Вроде как видна обращённость к светлым силам. Но продвинули в итоге... Яву. По моим понятиям, GNU - это тоже один из изрядно ГНУсных проектов. Во-вторых, у меня есть некоторые сомнения в идентичности животного, являющегося символом проекта. А во-первых, качество ГНУсных продуктов, мягко говоря, оставляет желать много лучшего (да, можно кидать в меня тухлыми овощами).

Конечно, проблема здесь - в самих людях. Люди просто-напросто тупы в своём большинстве и склонны поддаваться харизме. Как их научил первый харизматичный «посвятитель», так у них в голове и закладывается. Поэтому, имеют место быть религиозные войны между разными языками. Хотя, если быть честным и иметь кругозор, то становится ясно, что все современные ЯП - это говно и ни одного достойного среди них нет.

С другой стороны, кому на самом деле будет хорошо, если ИТ будут развиваться свободно и с нужной скоростью? Повысится вычислительная мощность отдельного человека и любых организаций. Легче будет разрабатывать всякие гадкие предметы и технологии. В общем, дело ясное, что дело тёмное. Традиционно.

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

>Я вот тут придумал, как бы ещё вскрыть гнилую сущность ФП.

И после этого не слова собственно про ФП... Оригинально :-/

SV0L0CH
()

Выбор прост - не иди в программисты, после 45 лет никому не будешь нужен.

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

>Выбор прост - не иди в программисты, после 45 лет никому не будешь нужен.

Тоже борьба с конкурентами? правильно :)

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

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

Гы. ТЫ будешь удивлен, но ВНЕЗАПНО люди делают прикидки на бумажных черновиках, а не на доске =). А доска - намного реже нужный нишевый инструмент, когда надо что-то написать для аудитории.

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

> Гы. ТЫ будешь удивлен, но ВНЕЗАПНО люди делают прикидки на бумажных черновиках, а не на доске =)

Гы. ТЫ будешь удивлен, но ВНЕЗАПНО чистое ФП не разрешает ничего зачёркивать, и если Я чему и удивлён, так это тому, что ТЫ не понял этого. Чистое ФП подразумевает, что любую формулу или рисунок нужно полностью переписать, в крайнем случае можно обозначить фрагмент уже написанной формулы индексом и сослаться на него. А черновик - он оттого и черновик, что он чёрно-перечёркнутый.

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

Вполне ясно, что с точки зрения эффективности, гибкости и ресурсоёмкости чёрная доска лучше.

Не лучше. Ресурсоёмкость лучше только в очень узкой нише. Очевидно, что если ты собираешся сохранить полученные результаты, тебе понадобится новая доска, а эту придётся залить эпоксидкой, и преимущество теряется. Т.е. доска эффективнее только для работ, *не* *стоящих* сохранения. Что есть (за пределами индустрии глюкодлья) неэффективная трата ресурсов (человеческих). В то время, как, например, конспекты лекций поколениями передаваемые из рук в руки, сэкономили нецензурное количество студенческого времени. Бумага автоматически сохраняет результаты твоей работы. Ты всегда можешь пересмотреть вывод, сделаный 20 страниц назад, если его сборщик мусора не унёс. Т.е. с т.з. ресурсоёмкости и эффективности (за пределами одной узкой ниши) бумага гораздо нтереснее.

Про гибкость же и говорить смешно. «Доска» совержшенно не гибка. Максимум - стол для пингпонга, и мелок для кия. А куда только не запихивают бумагу! Валюта, упаковка, топливо, строительный материал, украшение. А чернила, говорят, некоторые умудрялись использовать в качестве спиртного. Конечно, мел тоже можно погрызть без большого вреда, но удовольствие же совсем другое.

Итого, автор не подумал.

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

>чистое ФП не разрешает ничего зачёркивать

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

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

>Гы. ТЫ будешь удивлен, но ВНЕЗАПНО чистое ФП не разрешает ничего зачёркивать, и если Я чему и удивлён, так это тому, что ТЫ не понял этого.

ВНЕЗАПНО, аналогия, которая приводит к другим выводам - херовая аналогия.

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

> Т.е. с т.з. ресурсоёмкости и эффективности (за пределами одной узкой ниши) бумага гораздо нтереснее.

Это просто в несовершенном физическом мире так получилось, что доска стоит дорого, а бумага - дёшево. Если условно считать стоимостью носителя его объём в килобайтах, то получится, что доска обычно очень маленькая и дешёвая. Для прочтения курса лекций достаточно одной доски, но для его записи потребуется общая тетрадь на 32 листа. Что по килобайтам будет эквивалентно примерно 20-30 больших досок. Хотя я не спорю, что метафора от этого ослабевает в глазах тех, кто не хочет её воспринимать. Видимо, восприятие метафоры зависит от воспринимающего более сильно, чем я ожидал :) Тот, кто не хочет воспринимать метафору, придерётся к внешним уровням, если они сделаны не слишком аккуратно.

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

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

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

Тогда метафора поломается, а она была довольно хороша. Доска не пытается сохранить только что написанное, точно так, как программы с деструктивными апдейтами/inplace алгоритмами. В бумагу же «persistence» встроен, как в «нормальные» функциональные, т.ч. сборка мусора и неизвестные требования по ёмкости свойственна обоим. Общие тетради на 32 листа могут без больших трудностей обеспечить изучение курсов лекций произвольному кол-ву студентов, без каких-либо затрат со стороны центрального лектора (?«бесплатный» паралелизм, ленивое изуч^Wвычисление?), «доска» же требует от всех одинаковой скорости воспроизведения/восприятия и синхронизации времени находжения перед ней (?мутексы/семафоры/блокировки/етц?). Метафора правильная. Просто «ценности» отличаются. Доску безусловно оценят артисты и торговцы недвижимостью(?эмбедщики?) — неограниченная возможность зарабатывать повторением и ограниченное пространство ценны для них. Я, сдавший большинство предметов благодаря чужим конспектам, написанным пока я занимался всякой более интересной фигнёй, обоснованно ценю «бумагу».

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