. Вою волком. У мнея математика закончилась лет пять тому назад, не успев начаться Лямбда исчисление я ни сном ни духом А там — только оно. Ыыыыы.
M>Один из примеров — представление чисел не помню кем не помню зачем Зачем? Читая эту книгу я периодически забываю даже то, что никогда не знал про Хаскель А я еще до монад не добрался...
Вчера купил эту книгу. Убийственная. Прочел первую главу. Нужно автора кастрировать путем повешения. И чтобы он висел столько времени, сколько средний человек, купивший данную книгу, будет разбирать формулы и формулировки данные в ней. Если бы я до этого не разбирал его лекции, то первую главу неделю читал. А ведь первая глава — это введение в ФП. Какого хрена в первой же главе разбирать синтаксически ориентированное конструирование и доказательство свойств функций. Набор типовых задач — впечатляет:
1 Получение остаточной процедуры.
2 Построение мат. описания функций.
3 Определение формальной семантики языка программирования.
4 Описание динам. структур данных.
5 Автомат. построение "значительной" части программы по описанию структур данных.
6 Доказательство наличия некоторого свойства программы.
7 Эквивалентная трансформация программ.
По данным задачам (и их формулировкам) средний человек решит что тот-же Хаскель — что-то такое небесное и обычным людям не предназначен.
Вобщем на обложке нужно написать — "Только для математиков" или "Нематиматикам читать запрещено" или "Теперь вы сможете сформулировать почему вы не любите функц. программирование".
Вообще это большая проблема учебников написанных математиками. Очень мало хороших учебников которые можно читать. Такое впечатление, что математики искренне верят что из формулы сразу понятен алгоритм действий.
Здравствуйте, GlebZ, Вы писали:
GZ>Вобщем на обложке нужно написать — "Только для математиков" или "Нематиматикам читать запрещено" или "Теперь вы сможете сформулировать почему вы не любите функц. программирование".
Можно так "Экстремальное математическое порно для тех про проводит вечера в одиночестве".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Можно так "Экстремальное математическое порно для тех про проводит вечера в одиночестве".
Да самое интересное, что книжка хорошая. Я собственно ее и купил из-за математики. Но из обложки можно сделать вывод, что книга является учебником по функциональному языку Haskell. А это уже сильно огорчает.
Здравствуйте, VladD2, Вы писали:
EC>>Hardcore в общем, можно ещё на первой странице проверять достиг ли читатель 18 лет.
VD>Ага. А на последней достиг ли он оргазма.
Но даже такая намного лучше, чем никакой — она позволяет (мне во всяком случае) получить неплохую общую картину.
Ну и то, что на родном языке тоже приятно.
Зашёл тут по чьей-то ссылке, там что-то говрится про типы в хаскеле.
Вот пара примеров оттуда
(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t)
pz = (((. head . uncurry zip . splitAt 1 . repeat) . uncurry) .) . (.) . flip
Так, и хочется воскликнуть: и эти люди запрещают нам ковыряться в носу! (и этим людям не нравятся скобки в LISP'е!)
Имхо даже для исследовательских целей это явный перебор.
И насколько я понимаю, (почти?) все ФЯ страдают подобной ненаглядностью. Понятно, что это дело вкуса/привычки, но меня лично подобный синтаксис — серьёзное препятствие для изучения/применения.
Может кто-нибудь посоветовать для ознакомления ФЯ "попроще"? но и не настолько простой как, например, unlambda.
Лисп в виде scheme'ы уже, Nemerle не прелагать, пока мне рано. Купил книжку по хаскелю
, теоретическая часть благодаря фак. "К" МИФИ прошла на ура, но часть, относящаяяся собственно к языку имхо не очень понятна.
Есть ли язык, имеющий столь же простой синтаксис, как, например, pascal/modula2? Но функциональный.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>Зашёл тут по чьей-то ссылке, там что-то говрится про типы в хаскеле. F>Вот пара примеров оттуда
F>
F>(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t)
F>
Сложные типы (например, типы функций ну очень высокого порядка) всегда выглядят страшно, это не синтаксическая сложность, а семантическая, синтаксис лишь отражает структуру типа. Решается, как и в C/C++, введением синонимов. Типы вида int (*(*(*)())[3])() нравятся больше?
F>Имхо даже для исследовательских целей это явный перебор.
В принципе, начинать изучать ФП с сайта Олега Киселева — это перебор , для понимания большинства его статей нужен черный пояс в теории языков программирования и смежных областях (теория типов, например).
F>Может кто-нибудь посоветовать для ознакомления ФЯ "попроще"? но и не настолько простой как, например, unlambda. F>Лисп в виде scheme'ы уже, Nemerle не прелагать, пока мне рано. Купил книжку по хаскелю
, теоретическая часть благодаря фак. "К" МИФИ прошла на ура, но часть, относящаяяся собственно к языку имхо не очень понятна. F>Есть ли язык, имеющий столь же простой синтаксис, как, например, pascal/modula2? Но функциональный.
Здравствуйте, frogkiller, Вы писали:
F>Зашёл тут по чьей-то ссылке, там что-то говрится про типы в хаскеле.
Ключевое слово выделено
F>Вот пара примеров оттуда
F>
F>(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t)
F>
F>
F>pz = (((. head . uncurry zip . splitAt 1 . repeat) . uncurry) .) . (.) . flip
F>
Так не пишут. Эти примеры взяты с одной целью — показать конвертацию из типа в определение, и из пойнтфри стиля в пойнтфул. У автора наверняка были причины выбрать именно такие сложные и непонятные выражения
А в целом — да, для того, чтобы понять что написано на языке Х надо как минимум знать язык Х.
F>Так, и хочется воскликнуть: и эти люди запрещают нам ковыряться в носу! (и этим людям не нравятся скобки в LISP'е!)
F>И насколько я понимаю, (почти?) все ФЯ страдают подобной ненаглядностью. Понятно, что это дело вкуса/привычки, но меня лично подобный синтаксис — серьёзное препятствие для изучения/применения.
Это не синтаксис, это конкретные примеры. И на С# можно наворотить непонятной хрени.
F>Может кто-нибудь посоветовать для ознакомления ФЯ "попроще"? но и не настолько простой как, например, unlambda. F>Лисп в виде scheme'ы уже, Nemerle не прелагать, пока мне рано. Купил книжку по хаскелю
, теоретическая часть благодаря фак. "К" МИФИ прошла на ура, но часть, относящаяяся собственно к языку имхо не очень понятна. F>Есть ли язык, имеющий столь же простой синтаксис, как, например, pascal/modula2? Но функциональный.
Я бы всё таки начал со Scheme, очень простой язык. Ну, а так Ocaml, наверное.
Здравствуйте, palm mute, Вы писали:
PM>Сложные типы (например, типы функций ну очень высокого порядка) всегда выглядят страшно, это не синтаксическая сложность, а семантическая, синтаксис лишь отражает структуру типа. Решается, как и в C/C++, введением синонимов. Типы вида int (*(*(*)())[3])() нравятся больше?
Ты мозги то не пудри. Это ведь был всего лишь пример эмуляции перегрузки. В С++ перегрузка выражается просто и естественно. Никакой лишней косвенности там не будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты мозги то не пудри. Это ведь был всего лишь пример эмуляции перегрузки. В С++ перегрузка выражается просто и естественно. Никакой лишней косвенности там не будет.
Человек жаловался на синтаксис конкретно этой строчки:
(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t)
VD>Ты мозги то не пудри
Ну да, ну да. Что ты там говорил про Зверька? "Вот научится вести себя на людях...". Успехов, дорогой модератор.
Здравствуйте, lomeo, Вы писали:
F>>Зашёл тут по чьей-то ссылке, там что-то говрится про типы в хаскеле. L>Ключевое слово выделено
Ага. Но точнее я объяснить не смог
L>А в целом — да, для того, чтобы понять что написано на языке Х надо как минимум знать язык Х.
Мне казалось, что одна из задач языка облегчить понимание, что на нём написано. А вот подобные записи с моей точки зрения не совсем интуитивно понятны.
Что особенно смущает, что в императивных языках традиционно переменным, типам и тд даются осмысленные наименования. В ФЯ в большинстве примеров, что я видел, всё именуется одно-двухбуквенно. Поэтому запись (a -> b) -> c в принципе понятна, но "что конкретно ты имела в виду"?
L>Я бы всё таки начал со Scheme, очень простой язык. Ну, а так Ocaml, наверное.
Со Scheme я уже познакомился, действительно, просто и понятно. Наверное, да, буду смотреть Ocaml.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, palm mute, Вы писали:
PM>Сложные типы (например, типы функций ну очень высокого порядка) всегда выглядят страшно, это не синтаксическая сложность, а семантическая, синтаксис лишь отражает структуру типа. Решается, как и в C/C++, введением синонимов. Типы вида int (*(*(*)())[3])() нравятся больше?
Если бы я случайно и написал такое на С/С++, непременно бы переделал, скорее всего, это какая-то ошибка проектирования.
PM>Можно попробовать Caml Light.
Спасибо.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, VladD2, Вы писали:
F>>Лисп в виде scheme'ы уже, VD>Ну, и чем тебя это введение не устраивает?
Устраивает. Потихоньку продолжаю "играться" с ним, но вряд ли стану использовать в работе.
F>> Nemerle не прелагать, пока мне рано. VD>Что рано? Если ты знаком с императивным программированием и теболее с ООП, то это будет самый простой путь.
Знаком, и, наверное, неплохо (7+ лет на cpp — как раз тут это скорее минус — сложнее перестроить мышление). Но в данном случае Nemerle будет как тем самым микроскопом орехи колоть. Меня смущает обилие различных механизмов, которых я пока не понимаю, для по сути одного и того же. Хотелось бы понять весь этот "синтаксической сахар" в каком-то систематизированном порядке, и лучше бы от простого к сложному.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>Если бы я случайно и написал такое на С/С++, непременно бы переделал, скорее всего, это какая-то ошибка проектирования.
Ну, в C нечасто используют функции высшего порядка, но синтаксис для типов функций, принимающих указатели на функции и возвращающих указатели на функции гораздо страшнее, ИМХО.
В том примере ничего страшного не было. a -> b — это тип функции, принимающей a и возвращающей b.
Благодаря каррингу функции с несколькими аргументами выражаются как функции одного аргумента, возвращающие другую функцию.
Итак, для того примера имеем:
(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t
Функия возвращает t, принимает один аргумент типа
((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t
Это тоже функция, возвращает тоже t, принимает 2 аргумента:
2) t3 -> t1 -> t2 -> t3 — функция, на C ее тип выглядит как t3 (*)(t3,t1,t2)
1) (a -> b -> c) -> (a -> b) -> a -> c
функция, принимает 3 аргумента
1) a -> b -> c == c (*) (a,b)
2) a -> b — тривиально
3) a
и возвращает c
Здравствуйте, palm mute, Вы писали:
PM>В том примере ничего страшного не было. a -> b — это тип функции, принимающей a и возвращающей b. PM>Благодаря каррингу функции с несколькими аргументами выражаются как функции одного аргумента, возвращающие другую функцию.
PM>Итак, для того примера имеем: PM>(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t PM>Функия возвращает t, принимает один аргумент типа PM>((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t PM>Это тоже функция, возвращает тоже t, принимает 2 аргумента: PM>2) t3 -> t1 -> t2 -> t3 — функция, на C ее тип выглядит как t3 (*)(t3,t1,t2) PM>1) (a -> b -> c) -> (a -> b) -> a -> c PM> функция, принимает 3 аргумента PM> 1) a -> b -> c == c (*) (a,b) PM> 2) a -> b — тривиально PM> 3) a PM> и возвращает c
Это всё как раз понятно. Процесс аналогичен разбору типа в С, с чего обычно и начинается обучение. Но имхо очень не наглядно. Пусть даже с практикой разбор такого выражения будет занимать пару секунд. Но в нескольких страницах подобного кода найти отличия, например, между
(((a -> b -> c) -> (a -> b) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t
и
(((a -> b -> c) -> (a -> d) -> a -> c) -> (t3 -> t1 -> t2 -> t3) -> t) -> t
очень сложно.
А если накладывать ограничения на типы (а без этого, я так понимаю, практически не бывает), то объявление разрастётся на несколько строк.
По-моему, это сильно затрудняет написание больших программ.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>Мне казалось, что одна из задач языка облегчить понимание, что на нём написано. А вот подобные записи с моей точки зрения не совсем интуитивно понятны.
Ну так эти записи сделаны не для того, чтобы их понимать
Здравствуйте, frogkiller, Вы писали:
F>Знаком, и, наверное, неплохо (7+ лет на cpp — как раз тут это скорее минус — сложнее перестроить мышление). Но в данном случае Nemerle будет как тем самым микроскопом орехи колоть. Меня смущает обилие различных механизмов, которых я пока не понимаю, для по сути одного и того же. Хотелось бы понять весь этот "синтаксической сахар" в каком-то систематизированном порядке, и лучше бы от простого к сложному.
Дак, чудак ты человек.
У тебя основная проблема — это то что ты попадаешь в полностью другой мир. Тот же Хаскель или Схема на С++ ну соврешенно не похожи. Говорить о постепенном изучении просто не приходится.
Вот скажем с восприятем C#-кода у тебя большие проблемы?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Автор(ы): Р. В. Душкин
Лямбда исчисление я ни сном ни духом 
