Языку Haskell исполнился 21 год

Просто запомнилось, что один клоун в среди неадеквата высказал что-то разумное, а потом опять принялся поясничать.

Вас, клоунов, пруд-пруди. Что виндузятник, что ты. Вечно поясничаете.

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

Всё ради твоего блага, аноним.

> Я внимательно прочитал и осилил половину книжки Маклейна (про категории для работающего математика), прочитал кучу статей в интернетах и викибуках различной упоротости, так и не понял, зачем программисту на хацкеле теоркат. Может ты в курсе?

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

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

Пока есть датчики говорящие все о текущем состоянии. Ничего. Такая задача для него идеально подходит.

Если же датчики дают только часть нужной информации, то все зависит от объема этой информации. Если объем большой, то количество связей растет в геометрической прогрессии. Объекты позволяют обойти эту проблему. Хотя предел и тут, конечно, есть, но 5-7 объектов, это лучше 5-7 параметров. Ибо объекты можно укрупнять и укрупнять, а связи укрупняются автоматически.

В ФП можно укрупнять сами связи, но вот как изабивться от огромного числа параметров? Как я понимаю, лучше всего, эмулировать объектную систему. Чем с успехом и занимаются.

Дальше - вопрос вкуса. Кому объектная система, а кому ее эмуляция.

> Мне ответил только ты, но довольно бессодержательно. Хотя это риторический вопрос был.

Вопрос был дебильный. Но действительно, я перепутал тебя с другим идиотом.

> Если же датчики дают только часть нужной информации, то все зависит от объема этой информации. Если объем большой, то количество связей растет в геометрической прогрессии. Объекты позволяют обойти эту проблему. Хотя предел и тут, конечно, есть, но 5-7 объектов, это лучше 5-7 параметров. Ибо объекты можно укрупнять и укрупнять, а связи укрупняются автоматически.

Чушь и бред.

В ФП можно укрупнять сами связи, но вот как изабивться от огромного числа параметров? Как я понимаю, лучше всего, эмулировать объектную систему. Чем с успехом и занимаются.

но вот как изабивться от огромного числа параметров?

triplefacepalm. Внезапно функции могут работать не только с примитивными типами.

Это уже даше не смешно. Может ещё расскажешь про проблемы ФП? В то время, как космические корабли бороздят пространства, а в хаскелле появились и давно используются GADT и view, ты продолжаешь пороть такую еренду? Нет пути.

> зачем программисту на хацкеле теоркат

Для лучшего понимания широко используемых классов типов Haskell, таких как Functor, Applicative, Monad, Arrow.

Ваш К.О.

>> Если же датчики дают только часть нужной информации, то все зависит от объема этой информации. Если объем большой, то количество связей растет в геометрической прогрессии. Объекты позволяют обойти эту проблему. Хотя предел и тут, конечно, есть, но 5-7 объектов, это лучше 5-7 параметров. Ибо объекты можно укрупнять и укрупнять, а связи укрупняются автоматически.

Чушь и бред.

Спасибо. Оценка оценки - 0. Ноль информации и ноль смысла. Так что нах.

В ФП можно укрупнять сами связи, но вот как изабивться от огромного числа параметров? Как я понимаю, лучше всего, эмулировать объектную систему. Чем с успехом и занимаются.

но вот как изабивться от огромного числа параметров?

triplefacepalm. Внезапно функции могут работать не только с примитивными типами.

Это уже даше не смешно. Может ещё расскажешь про проблемы ФП? В то время, как космические корабли бороздят пространства, а в хаскелле появились и давно используются GADT и view, ты продолжаешь пороть такую еренду? Нет пути.

Честно говоря вообще не понял к чему ты тут это сказал? И как это связано тем что я говорил? В огороде бузина в Киеве Дядька? Если так то просто нах.

Проблема в том, что ты не знаешь о чем говоришь. Все твое познание о ФП строится на догадках и ЛОРовских троллях. Но и этого мало, ты даже не способен стройно сформулировать свои претензии, так что приходится догадываться, что ты там имеешь ввиду.

Пониманию таких вещей способствуют достаточно простые примеры/контрпримеры (а-ля категория Клейсли), которые мало распространены среди теоркатчиков. Зачем хацкеллисту диффеоморфизмы с леммами йонеды и категориальными пределами — вот это для меня загадка.

Да и много ли теоркатчики про Arrow рассказывают?

> Проблема в том, что ты не знаешь о чем говоришь. Все твое познание о ФП строится на догадках и ЛОРовских троллях. Но и этого мало, ты даже не способен стройно сформулировать свои претензии, так что приходится догадываться, что ты там имеешь ввиду.

Хм... У меня нет никаких претензий никому и ничему.

Просто давно понял, что лучшее решение - это то, что строит модель предметной области.

И просто считаю, что такие модели строить в ООП удобнее, чем в ФП.

Но согласен, что кому-то может быть наооброт.

Пока есть датчики говорящие все о текущем состоянии. Ничего. Такая задача для него идеально подходит.

Если же датчики дают только часть нужной информации, то все зависит от объема этой информации. Если объем большой, то количество связей растет в геометрической прогрессии. Объекты позволяют обойти эту проблему. Хотя предел и тут, конечно, есть, но 5-7 объектов, это лучше 5-7 параметров. Ибо объекты можно укрупнять и укрупнять, а связи укрупняются автоматически.

В ФП можно укрупнять сами связи, но вот как изабивться от огромного числа параметров? Как я понимаю, лучше всего, эмулировать объектную систему. Чем с успехом и занимаются.

Дальше - вопрос вкуса. Кому объектная система, а кому ее эмуляция.

Кто-нибудь, кроме автора, что-нибудь понял?

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

> Кто-нибудь, кроме автора, что-нибудь понял?

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

Хочешь держи в голове объекты и их связи, хочешь функции и их связи. Весь вопрос в удобстве увеличения уровня абстракции для решения больших задач.

Как я уже говорил, дело вкуса.

Всем спокойной ночи!

PS: Кстати, есть какие-нибудь методологии по рефакторингу в ФП? Хоть какой-нибудь материал на эту тему?

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

http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html

> Как я уже говорил, дело вкуса.

Ты говорил какую-то ерунду про параметры функций.

В современных играх основную массу бинарников занимают ресурсы а не сам код.

Это уже особая статья расходов. Конечно, общий размер одних сцен больше размера всего кода, а там ещё модели предметов, звуки, анимация...

Незаметен, может быть, но его размазанность по процессу убивает возможность верифицировать все.

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

Это лишь твое мнение. И оно отличается от реальности.

Оно основано на опыте.

Подавляющее большинство классов в наших проектах либо не входили в иерархию вообще (т.е., не должны были быть классами, по хорошему), либо наследовались только от интерфейса.

В ФП можно укрупнять сами связи, но вот как изабивться от огромного числа параметров?

Слушай, ну почитай хоть что-нибудь про функциональное программирование, а?

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

Брат!
Мы же таки не будем тешить регистранта дракой себя самого с собой.

Единственная незначительная подробность:
символьное имя константы (как функция на пустом множестве)
возвращает числовое значение некоторого типа.
Или мы с тобой, и Хацкель тоже (пусть все живут сто двадцать лет)
не хозяева тому, что значат наши имена?!

круто

> Хм... У меня нет никаких претензий никому и ничему.

Просто давно понял, что лучшее решение - это то, что строит модель предметной области.
И просто считаю, что такие модели строить в ООП удобнее, чем в ФП.
Но согласен, что кому-то может быть наооброт.

Для того, кто в теме о цпп и совсем не в теме о фп, цпп будет удобнее, да. Это же очевидно.

Судя по тому, что ты пишешь, ты и с ООП знаком по плохим книжкам 20-летней давности. Идея о том, что объекты в программе должны моделировать объекты реального мира совершенно не работает в реальных проектах и давно закопана.

Только вот как надо написать что-то серьезнее факториалов, хаскеллисты сразу же берутся за C. Кроме нескольких самых известных Ъ-хаскеллистов, использующих хаскелль даже для реальных задач.

Т.е. того же yesod попросту не существует?

символьное имя константы (как функция на пустом множестве) возвращает числовое значение некоторого типа.

Отсыпь. Отнесу знакомому дилеру, показать, ЧТО употребляют НАСТОЯЩИЕ укурки.

>но зато функционала на строчку получается значительно больше.

Неудивительно! Функциональный же язык!

> Может ты хотел сказать, что функция — это отношение (то есть множество пар (a, b) ∊ (X, Y)) такое, что по первому элементу эти пары уникальны?

Кстати, отсюда следует, что у функции с пустой областью определения пустая область значений. И никаких функций, возвращающих 5, таким образом не сделать.

Чё-то вы ребятки совсем загнались. Давайте определим что есть функция возвращающая 5: Y(x): x -> 5, для любого x ∊ R

Давайте определим что есть функция возвращающая 5: Y(x): x -> 5, для любого x ∊ R

зачем? это тривиально и неинтересно

что касается исходного вопроса, то отображение из пустого множества есть только одно - на пустое множество; 0ⁿ = 0 для любого n ∊ ℤ \ {0}, 0⁰ = 1

>> Может ты хотел сказать, что функция — это отношение (то есть множество пар (a, b) ∊ (X, Y)) такое, что по первому элементу эти пары уникальны?

Кстати, отсюда следует, что у функции с пустой областью определения пустая область значений. И никаких функций, возвращающих 5, таким образом не сделать.

Чё-то вы ребятки совсем загнались. Давайте определим что есть функция возвращающая 5: Y(x): x -> 5, для любого x ∊ R

Речь шла о функциях от пустого множества, возвращающих 5.

Если вы загляните чуть выше, то вы поймёте, что речь шла о константе как о функции. (Кто-то заявил, что константа не может быть функцией).

> Если вы загляните чуть выше, то вы поймёте, что речь шла о константе как о функции. (Кто-то заявил, что константа не может быть функцией).

Я прекрасно знаю, о чём там шла речь. Кто-то сказал глупость, что в хаскеле нет значений, и пытался развить эту мысль, представляя их в виде 0-арных функций, функций от пустого множества и прочей ереси.

> Речь шла о функциях от пустого множества, возвращающих 5.

А, ну да, тогда так: y(x): x -> 5, x ∊ X \ {перечёркнутый ноль}, где X - произвольное множество.

>> Речь шла о функциях от пустого множества, возвращающих 5.

А, ну да, тогда так: y(x): x -> 5, x ∊ X \ {перечёркнутый ноль}, где X - произвольное множество.

Функция как функция. Главное, чтоб значения никуда не девались. 5 ведь — значение?

Да. Т.е. у меня - да, не знаю как в хацкеле.

> Да. Т.е. у меня - да, не знаю как в хацкеле.

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

А почему нельзя ввести класс функций f_n: 1 -> Z, где каждая функция f_n отображает множество из 1 элемента на множество целых чисел, а конкретно на число n? Ведь каждая такая f в отдельности будет однозначна.

Разумеется, можно так же определить любую f_x: 1 -> X.

P.S. Конкретно в Haskell 1 можно заменить на ().

А почему нельзя ввести класс функций f_n: 1 -> Z, где каждая функция f_n отображает множество из 1 элемента на множество целых чисел

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

> А почему нельзя ввести класс функций f_n: 1 -> Z, где каждая функция f_n отображает множество из 1 элемента на множество целых чисел, а конкретно на число n? Ведь каждая такая f в отдельности будет однозначна.

Разумеется, можно так же определить любую f_x: 1 -> X.

P.S. Конкретно в Haskell 1 можно заменить на ().

В хаскеле такие функции уже есть: const 1, const 5.

Ну вот и проблема решена.

5 :: Int <=> (n5 :: () -> Int) ()

Или я что-то пропустил?

> Ну вот и проблема решена.

А какая была проблема?

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

отображение из пустого множества есть только одно

я, кстати, неправ - ровно одно отображение (пустая функция) есть на пустое множество

пустое множество является инициальным объектом, одноэлементное - терминальным

впрочем, какая кому разница

эквивалентна выбору элемента из ℤ

как-то так

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

Лично я спорил с утверждением, что в Хацкеле нет значений (не являющихся функциями), а не с существованием const. (const 5 :: a -> Int) ведь значение возвращает?

Кстати, как вообще может пустое множество участвовать в отображениях?

Ведь там нет элементов вообще, поэтому нечего отображать и не на что отображать.

> Лично я спорил с утверждением, что в Хацкеле нет значений (не являющихся функциями), а не с существованием const. (const 5 :: a -> Int) ведь значение возвращает?

Ну, Haskell Report говорит о том, что значения есть. Однако, в GHC и значения. и ф-ции представлены thunk'ами, которые работают примерно как ф-ции.

> Кстати, как вообще может пустое множество участвовать в отображениях?

Ведь там нет элементов вообще, поэтому нечего отображать и не на что отображать.

Видимо, тогда отображение само будет пустым множеством.

>> Лично я спорил с утверждением, что в Хацкеле нет значений (не являющихся функциями), а не с существованием const. (const 5 :: a -> Int) ведь значение возвращает?

Ну, Haskell Report говорит о том, что значения есть. Однако, в GHC и значения. и ф-ции представлены thunk'ами, которые работают примерно как ф-ции.

Unboxed значения thunk'ов не создают. Да и вообще, это другой уровень совсем, там и функции не в математическом понимании используются, и побочные эффекты присутствуют.

Или я что-то пропустил?

пропустил. если 5 имеет тип () -> Int, т.е. это константная функция, возвращающая 5, то какой тип у её возвращаемого значения? Int? но мы ведь только что решили, что у нас всё есть функция, и значит возвращать мы можем только 5 :: () -> Int, итого () -> () -> Int. и так далее ad infinum, как и проиллюстрировано по ссылке, мелькавшей здесь уже дважды

таким образом ты получил не унарную константную функцию, а ∞-арную. Haskell бесконечных типов не поддерживает, если что