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

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

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

в 0 нечего складывать, а в 1 - умножать, но это ведь тебя не смущает? есть хорошая заметка на эту тему, рекомендую

А, так вы о возможности проделать такое для всех значений... Sorry, не понял. Ну тогда конечно невозможно :)

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

да. это, в частности, позволяет сделать из множеств категорию

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

[i]>5 :: Int <=> (n5 :: () -> Int) ()[/i]

[i]>Или я что-то пропустил?[/i]

Функция может возвращать каждый раз новые thunk'и. Поэтому, например, мемоизация работать не будет так, как это было бы возможно в случае обычных значений, thunk которых всегда один и тот же.

я слегка обалдел когда увидел это:
http://paste.debian.net/113186/
ну-с мои поздравления хаскелистам с юбилеем, «колбаску нарезали уже»))

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

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

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

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

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

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

По поподу ваших проектов сказать ничего не могу.

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

Как я понимаю, пошли вещи чисто субъективные.

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

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

Кто бы спорил что никто не будет создавать объект автомобиль. Но вот объект пакета данных от компьютера к контроллеру, он реален?

> Но вот объект пакета данных от компьютера к контроллеру, он реален?

Какая-то странная постановка вопроса. Пакет данных — реален. В ООП он будет представлен объектом класса. В ФП — значением типа.

Но это не может говорить о ненужности использования объектов.

Объекты (наследующие от интерфейса) нужны только тогда, когда управление памятью ручное. В остальных случаях замыкания проще.

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

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

>> Но вот объект пакета данных от компьютера к контроллеру, он реален?

Какая-то странная постановка вопроса. Пакет данных — реален. В ООП он будет представлен объектом класса. В ФП — значением типа.

Вообще-то я отвечал на:

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

>> Но это не может говорить о ненужности использования объектов.

Объекты (наследующие от интерфейса) нужны только тогда, когда управление памятью ручное. В остальных случаях замыкания проще.

Проще? Да. Но хуже приспособлены к полному циклу разработки с множеством рефакторингов и длинным периодом поддержки. То что прописано явно - легче изменять и поддерживать.

> Хм... является ли объектом реального мира управляющее воздействие, которое должен сформировать алгоритм?

Ты ещё задачу не сформулировал, а уже модель строишь. Вот этим все хреновые ООП-шники и страдают.

Метод объекта является объектом? А вызов этого метода?

(Это что бы функциональщику легче понять было :)

Я на объектно-ориентированных языках пишу с 1995 года и по сей день.

Кто бы спорил что никто не будет создавать объект автомобиль.

А ну ка напиши программу для автоматизации продаж автомобилей. Или для отслеживания движения автомобилей с помощью GPS. Или игру-автогонки. Там объектов-автомобилей не будет?

Но вот объект пакета данных от компьютера к контроллеру, он реален?

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

Но хуже приспособлены к полному циклу разработки с множеством рефакторингов и длинным периодом поддержки.

Чушь.

То что прописано явно - легче изменять и поддерживать.

А это тут при чём???

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

Тогда чем это отличается от условно структуры+функции?

> Короче, идите и учите мат.часть. В Haskell любое значение можно считать функцией. Т.к. функции могут быть без агрументов. А любая фунцкия - значение.

Неплохой у меня получился вброс. :) Легкое движение пальцев и несколько страниц искреннего бешенства в результате.

Ну забыл ты, что такое функция, не беда, бывает; ну сказал чушь, тоже не беда, тоже бывает. Зачем пытаться оправдать себя мифическим вбросом?

> Ну забыл ты, что такое функция, не беда, бывает; ну сказал чушь, тоже не беда, тоже бывает. Зачем пытаться оправдать себя мифическим вбросом?

Что, жалко времени, убитого на жаркие дебаты?

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

>> Хм... является ли объектом реального мира управляющее воздействие, которое должен сформировать алгоритм?

Ты ещё задачу не сформулировал, а уже модель строишь. Вот этим все хреновые ООП-шники и страдают.

Но вот объект пакета данных от компьютера к контроллеру, он реален?

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

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

>> Но хуже приспособлены к полному циклу разработки с множеством рефакторингов и длинным периодом поддержки.

Чушь.

Хм... Без аргументации?

То что прописано явно - легче изменять и поддерживать.

А это тут при чём???

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

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

То есть ты признаешься, что нес бред?

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

Тогда чем это отличается от условно структуры+функции?

Если я понял правильно, то слово «условно» здесь относится к структурам.

Как я уже говорил, только вкусами, кому с чем нарвится работать.

Рефакторить и масштабировать функции легче чем объекты.

ООП облегчает рефакторинг и массшатибрование объектов.

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

Это могли быть, например:

1. программа управляющая устройством, драйвер устройства.

2. эмулятор устройства, система автоматизированного проектирования электроники.

Так что не петушись, а чётче выражай свои мысли.

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

То есть ты признаешься, что нес бред?

Естественно.

>> То есть ты признаешься, что нес бред?

Естественно.

Что, впрочем, не отменяет того факта, что я был дико удивлен обилием взметнувшегося кала. Почти что как в open vs proprietary или Linux vs Windows. В общем, ЛОР давно уже не платформа для спокойного и интеллектуального обсуждения чего бы то ни было.

>> То есть ты признаешься, что нес бред?

Естественно.

Ну, хоть один раз признался.

В общем, ЛОР давно уже не платформа для спокойного и интеллектуального обсуждения чего бы то ни было.

В том числе и усилиями гвнометов типа тебя.

То же самое замыкание заменяется объектом-функцией и все связи прописываются явно,

Что неявного в замыкании?

ООП облегчает рефакторинг

ООП сильно затрудняет рефакторинг.

> Что, жалко времени, убитого на жаркие дебаты?

Какие усилия? Я ровно один пост написал про функции.

Видимо задел за живое? Пардон.

Да, мне очень жаль, что физтех не может признать свой фейл.

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

Много людей следит за тредом (ибо хацкель), поэтому даже бред выживает. И никакой «самоподдержки» нет, просто побочный эффект от присутствия большого числа людей. А люди эти заинтересованы отнюдь не тобой или твоим бредом.

>> ООП облегчает рефакторинг

ООП сильно затрудняет рефакторинг.

Это как раз субъективно.

Рефакторинг «структур» в ФП я не представляю. Рефакторинг в ООП - лекго.

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

Рефакторинг «структур» в ФП я не представляю. Рефакторинг в ООП - лекго.

Не вижу разницы.

http://www.cs.kent.ac.uk/projects/refactor-fp/publications/tool-support-for-r...

> http://www.cs.kent.ac.uk/projects/refactor-fp/publications/tool-support-for-r...

Спасибо.

Интересно. Особенно подборка ссылок.

Правда смущает, что говорят о том что им надо еще много всего реализовать, дата документа 2003. Забили?

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

Ну если брать не Int, а настоящий Nat, то 0 будет принадлежать универсуму значений и будет ассоциирован со стрелкой 1 -> Nat из универсума типов (где 1 это терминальный объект категории (и единица произведения в категории), можно считать что это ()), а все остальные числа будут композициями стрелок вида Nat -> Nat.

  (1 : U') -- (0 : U) --> (Nat : U') ------\
                            ^              |
                            |              |
                            |              |
                            `-- (+1 : U) --^

Т.е. все конструкторы без аргументов ([], True, False, Nothing, ...) имеют тип (1 -> что-то) («иметь тип» это объект-значение из U ассоциирован (::) с объектом-типом (стрелкой) из U').

А с точки зрения системы типов ничего кроме настоящих типов и их конструкторов и нет.