Свертка
Похоже, я переживаю вторую волну функционализации мышления :) Первая была в 93-94гг, когда нам в школе объяснили LISP, и мы на нем делали всякие задания. Например, калькулятор рекурсивным спуском. Отголоском был годом позже спецкурс для студентов третьего курса, куда я будучи еще зеленым первокурсником храбро ходил, хотя и не все тогда получалось.
( Read more... )
Я пытался в прошлом году осилить книгу, где все объяснялось на примерах Scheme. Очень полезное чтиво, многие вещи встают на места (рекурсия в процедурном программировании никогда не была до конца понятной). Но все же это высший пилотаж, я имею ввиду использование на реальных проектах. Пожалуй, кроме Erlang`а я не слышал ни об одном языке, который бы широко использовался на прикладном уровне.
Кстати, Ruby ни разу не функциональный язык. Многое взял от Smalltalk, с его объектно-ориентированным подходом.
Обязательно пиши на такие темы! По крайней мере во мне ты найдешь благодарного читателя :)
Reply
Меня несколько удивило твое замечание о том, что функциональное программирование -- это часть дискретной математики. На я понял откуда ноги растут, видимо, из википедии :) (http://ru.wikipedia.org/wiki/Дискретная_математика) Если рассуждать логикой тех, кто это написал, то программирование вообще -- это часть дискретной математики, поскольку алгоритм -- это дискретная структура. Преимущество же функциональной парадигмы (будем так это называть) с точки зрения математиков в том, что она наиболее строгая, что делает возможным формальную верификацию, преобразования программ и пр. Поэтому математики и специалисты по computer science "любят" функциональные языки.
Это очень хорошо, что ты попробовал разобраться в программировании на Scheme. В MIT курс программирования традиционно преподают как раз на Scheme, а не нак промышленных языках, и это, я считаю, правильно.
Возможно, про Ruby я не совсем прав, приведя его в качеств примера, он, конечно, не позиционируется как чисто функциональный язык, но функциональные возможности там присутствуют в значительном объеме. Он вообще нахватался от самых разных языков. Erlang я не стал упоминать, я так понимаю, что основное в нем -- это concurrency model, а не парадигма программирования. Ради этого он разрабатывался, и поэтому его используют. Scala, F# и его основа OCaml. используются промышленно, см. например http://www.scala-lang.org/node/1658 . Про Haskell не знаю.
Reply
Угадал, оттуда.
с точки зрения математиков в том, что она наиболее строгая, что делает возможным формальную верификацию, преобразования программ и пр. Поэтому математики и специалисты по computer science "любят" функциональные языки.
Я заметил, что любят. Поясни про "формальную верификацию"!
Это очень хорошо, что ты попробовал разобраться в программировании на Scheme. В MIT курс программирования традиционно преподают как раз на Scheme, а не нак промышленных языках, и это, я считаю, правильно.
Книга как раз основана на курсе информатики MIT. Стоит озвучить ее название, вдруг кому пригодится:
"Structure and Interpretation of Computer Programs, 2nd Edition" by Harold Abelson and Gerald Jay Sussman (MIT Press, 1984)
Erlang я не стал упоминать, я так понимаю, что основное в нем -- это concurrency model, а не парадигма программирования
Ну это не делает его менее функциональным ;)
Scala, F# и его основа OCaml. используются промышленно, см. например http://www.scala-lang.org/node/1658
Не знал. Интересно. Получаются функ.языки действительно переживают второе рождение.
Как винил и ламповый звук ;)
Reply
Винил и ламповый звук сейчас -- это скорее мода, чем второе рождение. А функциональные языки -- это естественная реакция на усложнение задач, стоящих перед программистами. Так мне кажется.
Reply
По поводу винила - соглашусь лишь отчасти, по поводу лампового звука - нет.
Ренессанс ламповой аппаратуры - скорее естественная реакция на осознание синтетической природы звука транзисторного. А мода сейчас на дешевые и "быстрые" вещи.
Мода на дешевую технику, на поверхностный стиль жизни, на средства быстрой разработки (фреймворки, IDE и тд.), мода на фастфуд. Но никак не наоборот.
Reply
Давай я приведу пример. Пусть есть программа, которая решает квадратное уравнение. Методами формальной верификации можно установить, что:
а) программа выдаст результат для любых входных данных (то есть не зациклится)
б) программа вернет правильный результат, если уравнение имеет решение
с) программа вернет ошибку, если уравнение не имеет решения
Верификация делается не тестами, так как невозможно протестировать все возможные входные данные, а анализом кода программы и формальным доказательством, что он работает правильно.
Ну ладно, насчет лампы, может, ты и прав. Сильно спорить не буду :)
Reply
Если же рассуждать о том, что более понятно "по своей сути" - ну давайте рассмотрим простейший пример.
Представьте себе, что у вас есть куча документов, некоторые помечены грифом "важно" и вам нужно, чтобы ваш подчиненный подсчитал количество упоминаний вашего имени в помеченных документах. Как вы сформулируете ему задание? Будет ли ваша формулировка ближе к коду на си или к коду на хаскелле?
Псевдо-Си:
int res = 0;
for(int i = 0; i < numDocuments; i++) {
Document doc = documents[i];
if(!doc->isImportant) continue;
for(int j = 0; j < doc->numWords; j++) {
if(doc->words[j] == "keyman") res++;
}
}
return res;
Хаскелл:
count (=="keyman") [word | doc <- documents, isImportant doc, word <- words doc]
Reply
Кроме MIT: http://mitpress.mit.edu/sicp/
Ваш пример на Scala:
(documents filter (_.isImportant) map (_.words) flatten) count (_=="keyman")
через свертку:
(documents filter (_.isImportant) map (_.words count (_=="keyman")) foldLeft 0)(_+_)
Через for expression, что несколько ближе к Хаскелевскому синтаксису, но на Скале выглядит коряво:
(for (doc <- documents filter (_.isImportant); word <- doc.words) yield word) count (_=="keyman")
Reply
О! Вот это выглядит уже совсем по-человечески.
Однако осмелюсь заметить, что для подсчета вхождений больше подойдет что-нибудь менее экзотичное, LUA например. Кстатит, элегантный язык, IMHO. Но понимаю, что мы сейчас говорим не о применении, а о самой "прозрачности" парадигмы.
Reply
И да, согласен отсутствие бекграунда объясняет однобокость восприятия.
Reply
Reply
Reply
Reply
Вопрос резонный: насколько оправдано использование здесь Хаскелла :)
Да, и кстати, любопытно насколько такая реализация будет работать быстрее (и съедать меньше памяти и процессорного времени), чем скажем на Lua или Python?
Lua, как мне кажется просто создан для такого рода парсинга логов и создание отчетов.
Reply
Каждый раз, когда мне было нужно что-то дописать (а это было мне нужно довольно часто и срочно), я просто брал и дописывал минут за 10-20. И оно правильно работало с первой попытки - это очень типично для хаскелла. Такого никогда бы не случилось (в моих руках) ни с одним динамически типизированным языком, во всяком случае.
Я допускаю, что в руках гуру питона или гуру Lua соответственно Питон или Lua были бы так же продуктивны, как хаскелл в моих руках.
Но я замечу, что я не являюсь гуру хаскелла, и притом я могу со 100% уверенностью сказать, что если бы я писал эту утилиту на Java или C# (при том, что этими языками я владею намного более профессионально), то я бы задолбался.
Reply
Reply
Leave a comment