LINUX.ORG.RU

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чушь и бред.

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

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

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

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

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

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

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

Ваш К.О.

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

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

Чушь и бред.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

pitekantrop ★★★ ()

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

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

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

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

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

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

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

X-Pilot ★★★★★ ()
Ответ на: комментарий от sanuda

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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