Здравствуйте, pgregory, Вы писали:
P>Ерунда. Это не объяснение понятия коммутативного кольца, это объяснение понятия целого числа.
Это не объяснение понятия целого числа. Объяснение в предложенном вам стиле занимает 2-3 учебных года.
P>А вот про ; — это именно попытка объяснения сложной штуки под названием «монада». Фиговая.
Она лучше чем ваша попытка. Начнем с того, что аналогия с ; — законченная мысль, а вы объяснение целых чисел едва ли начали.
Целые числа и операции над ними изучают 10 лет, и в том числе изучаются все войства кольца — ведь объяснение кольца должно быть включено в объяснение целых чисел в любом случае. Это-то понятно? Какие из свойств коммутативного кольца с единицей вы не изучали в школе? Разве что только слово "кольцо" не упоминали — вот и все. А все эти группы и кольца изучаются за еденицы академических часов — просто чтобы показать общность свойств разных объектов, которую можно и самому заметить.
С монадами то же самое. Вы утверждаете, что в RWH без привлечения монад ничего не объясняется — но ведь это не правда. Там монады сначала изобретаются трижды — для IO, для Maybe и для парсеров — и только потом эта общность свойств получает название "монада" — именно так это происходит и при изучении чисел и алгебраических структур.
P>Моя мысль о том, что понятие «целые числа» != понятию «коммутативное кольцо» понятна, надеюсь?
Понятно, конечно. Мы сравниваем попытки объяснить X и объяснить Y — это не означает, что мы считаем, что между X и Y нет разницы.
K>>Можно сначала просто "считать", а потом, в институте, систематизировать разрозненные практические знания. P>То есть, наконец-то, очевидный факт, что Maybe — это просто, а монады — это сложно, признан? Ура!
Нет, признан факт, что то, что вам уже известно вы считаете простым, а то, что неизвестно — сложным. Понять что такое Maybe и не понять при этом, что такое монада невозможно, точно также как нельзя научиться считать и при этом не узнать, что a + 0 = a.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Кроме того, это противоречит вашим идеям — Схема значительно проще Питона — и для программирования и с точки зрения реализации интерпретатора.
С первым не согласен. Continuations — это жесть, по аналогии с монадами. Мне это не нравится.
P>>И это не мешает им писать программы, и делать это хорошо.
K>А вот это совсем не очевидно. А доказать вы это совершенно точно не сможете.
Думаю, при желании все-таки смогу. Мне, честно говоря, лень. Поэтому будем считать, что не смогу. Я в это просто верю.
K>С другой стороны дискретная математика включена в программу подготовки программистов не просто так. Хотя в таких пределах алгебру изучают вообще все инженеры.
И это очень хорошо.
P>>За простыми вещами должны следовать сложные, но не наоборот. Don't pay for what you don't need. Make simple things easy, but hard things possible. И так далее. Что здесь не ясно???
K>Мне не ясна ваша методика определения сложности. K>Кроме того, мне не ясно — вы предъявляете претензии к языку или к структуре образовательных курсов по этому языку? K>Ну, допустим GITH вашим требованиям не соотвествуют — а YAHT и RWH — вполне.
Я предъявляю претензию к языку. Потому, что он заставляет меня знать, что такое монада. Мне это не нравится. Заметьте, хаскель не заставляет знать, что такое коммутативное кольцо, чтобы оперировать числами. Напротив, все учебники начинаются в стиле «Смотрите, хаскель это так просто — пишем 1 + 1, а он нам пишет 2!» Только когда речь заходит об определенных (простых!) вещах, эта простота вдруг испаряется. Я об этом.
Не знаю, почему, но то, что мне не нравятся сложные языки программирования, некоторые пытаются списать на мою ограниченность, нежелание изучать ничего нового и черт знает что еще. Надеюсь, они все же не правы. Простота (и красота) — основа всего окружающего мира. И поэтому я верю, что реально хороший язык реально прост. В хаскеле куча интересных концепций, и когда для них будет найдена простая до очевидности интерпретация, они тут же промаршируют в мейнстрим. И я буду этому очень рад.
Здравствуйте, pgregory, Вы писали:
K>>Кроме того, это противоречит вашим идеям — Схема значительно проще Питона — и для программирования и с точки зрения реализации интерпретатора.
P>С первым не согласен. Continuations — это жесть, по аналогии с монадами. Мне это не нравится.
На схеме можно спокойно писать не подозревая о продолжениях.
Питон конечно прост, особенно его правила разрешения при множественном наследовании и концепция метаклассов
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, pgregory, Вы писали:
P>>А вот про ; — это именно попытка объяснения сложной штуки под названием «монада». Фиговая.
K>Она лучше чем ваша попытка. Начнем с того, что аналогия с ; — законченная мысль, а вы объяснение целых чисел едва ли начали.
Да ладно! Законченная-то законченная, только ничего не объясняющая. Иначе все монадные туториалы представляли бы из себя одну-единственную фразу.
K>Целые числа и операции над ними изучают 10 лет, и в том числе изучаются все войства кольца — ведь объяснение кольца должно быть включено в объяснение целых чисел в любом случае. Это-то понятно? Какие из свойств коммутативного кольца с единицей вы не изучали в школе? Разве что только слово "кольцо" не упоминали — вот и все.
Это принципиально. Я именно об этом и пишу.
K>А все эти группы и кольца изучаются за еденицы академических часов — просто чтобы показать общность свойств разных объектов, которую можно и самому заметить. K>С монадами то же самое. Вы утверждаете, что в RWH без привлечения монад ничего не объясняется — но ведь это не правда. Там монады сначала изобретаются трижды — для IO, для Maybe и для парсеров — и только потом эта общность свойств получает название "монада" — именно так это происходит и при изучении чисел и алгебраических структур.
Есть большая разница. После окончания нормальной школы, человек может хорошо решать кучу практических задач. При этом, он может ни разу в жизни не слышать о коммутативных кольцах.
В случае с хаскелем это неверно. Практически невозможно написать сколько-нибудь нетривиальную программу, не зная, что такое монада. That's the whole point.
K>>>Можно сначала просто "считать", а потом, в институте, систематизировать разрозненные практические знания. P>>То есть, наконец-то, очевидный факт, что Maybe — это просто, а монады — это сложно, признан? Ура!
K>Нет, признан факт, что то, что вам уже известно вы считаете простым, а то, что неизвестно — сложным. Понять что такое Maybe и не понять при этом, что такое монада невозможно, точно также как нельзя научиться считать и при этом не узнать, что a + 0 = a.
Ну неужели, печатая это, вы не поймали себя на том, что куда честнее было бы привести аналогию «точно также как нельзя научиться считать и при этом не узнать, что такое коммутативное кольцо с единицей»?!
А это ставит все на свои места, с моей точки зрения.
Еще раз. Я просто высказываю свою точку зрения. Я не считаю ее единственно правильной. Хотя и считаю, что у нее есть серьезные обоснования. Время покажет, кто прав. Вы понимаете мою точку зрения? Я вашу, думаю, понимаю.
Здравствуйте, pgregory, Вы писали:
P>Для программирования простых вещей на хаскеле необходимо знать сложное понятие монада. (Посмотри оглавление Real World Haskell, прежде чем возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном языке, чтобы оперировать числами, не требуется знать, что такое коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это опровергающую, ок?)
Вот ты можешь объяснить, почему монада в Хаскеле — это сложно, а ООП в Питоне — просто? Это возвращение к дискуссии о том, что сложность в обучении и использовании — разные вещи.
Ещё момент. Абстракция — это хорошо. Я в это верю, как ты веришь в то, что реальный язык реально прост. Аргументом для меня является тот факт, что программирование — это по большей части избавление от дублирования кода. Именно для этого служит абстракция. Абстракция может быть сложной в изучении, как ООП или монада (которая, кстати, несравненно проще). Это никак не отменяет её пользы в применении. И простоты, и лёгкости, и удобства.
Поэтому для меня простой язык — это язык, в котором есть высокоуровневые абстракции. И чем выше уровень, тем меньше зависимость от деталей реализации, а значит лучше, т.к. ближе к предметной области. При этом сложность в изучении этих абстракций (или инструментов их порождающих) не принимается во внимание Поэтому реально простой язык вполне может быть сложным в изучении.
pgregory wrote:
> Для программирования простых вещей на хаскеле необходимо знать сложное > понятие монада. (Посмотри оглавление Real World Haskell, прежде чем > возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном > языке, чтобы оперировать числами, не требуется знать, что такое > коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это > опровергающую, ок?)
Тоже не согласен. Для того, чтобы понять как использовать do, о монадах знать не требуется. А вот когда объясняешь, почему char a = 100 + 100 равно чёрт знает чему — приходится объяснять и о кольцах.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, lomeo, Вы писали:
L>Вот ты можешь объяснить, почему монада в Хаскеле — это сложно, а ООП в Питоне — просто? Это возвращение к дискуссии о том, что сложность в обучении и использовании — разные вещи.
Есть такая вещь как порог вхождения. Если для того чтобы просто начать писать даже что-то простое и легкое нужно сильно напрягать мозги, то мало кто это будет делать, независимо от того насколько сложен или прост язык в целом. Например у того же питона этот порог очень низок, хотя в нем есть и реально сложные вещи, но можно спокойно писать не подозревая о них. Другой пример рефал и Smalltalk, оба по сути очень просты, но начальный порог который нужно преодолеть достаточно высок и поэтому они малопопулярны. У Хаскеля этот порог еще выше.
Здравствуйте, ., Вы писали:
.>Тоже не согласен. Для того, чтобы понять как использовать do, о монадах знать не требуется. А вот когда объясняешь, почему char a = 100 + 100 равно чёрт знает чему — приходится объяснять и о кольцах.
Здравствуйте, ., Вы писали:
.>pgregory wrote:
>> Для программирования простых вещей на хаскеле необходимо знать сложное >> понятие монада. (Посмотри оглавление Real World Haskell, прежде чем >> возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном >> языке, чтобы оперировать числами, не требуется знать, что такое >> коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это >> опровергающую, ок?) .>Тоже не согласен. Для того, чтобы понять как использовать do, о монадах знать не требуется.
RWH о них рассказал, потому что это просто занятно, или же потому, что их реально надо знать? Что-то он про коммутативные кольца молчит. Как и Страуструп молчит о том, что шаблоны плюсов — Тьюринг-полный ФЯП. С чего бы?
Заодно, сказал раз, скажи и два. Haskell for Dummies, где нет упоминаний о монадах — в студию!
Здравствуйте, FR, Вы писали:
FR>Есть такая вещь как порог вхождения. Если для того чтобы просто начать писать даже что-то простое и легкое нужно сильно напрягать мозги, то мало кто это будет делать, независимо от того насколько сложен или прост язык в целом. Например у того же питона этот порог очень низок, хотя в нем есть и реально сложные вещи, но можно спокойно писать не подозревая о них. Другой пример рефал и Smalltalk, оба по сути очень просты, но начальный порог который нужно преодолеть достаточно высок и поэтому они малопопулярны. У Хаскеля этот порог еще выше.
Да я согласен, согласен. Только я о другом спрашивал всё же
P>>>Отсюда я делаю вывод, что хорошесть программы абсолютно ортогональна хорошести яп, на котором она написана. T>>Это если мы смотрим уже на готовые программы. T>>А если мы будем смотреть на стартовавшие и не завершённым программы, то всё будет по другому. T>>"Хорошесть" завершённой программы будет определяться языком программирования. P>Не понял мысль. Это следует читать как «когда реальные программы на хаскеле будут, наконец, написаны, они будут очень круты»? С чего вдруг? Почему, кроме GHC, таких программ сейчас нет? Если есть — примеры в студию!
В моих трёх строках нет про Хаскель. Есть про хороший язык программирования.
P>В этой презентации (от 24 сентября 2005 года) утверждается, что у darcs — 91 контрибьютор, у git — 79. На тот момент. Вот только, согласно википедии, разработка darcs началась на 3 года раньше, чем git'а. На момент презентации git'у было 4-5 месяцев.
Это какого darcs? Что на плюсах или на что Хаскеле?
T>>Популярность git определяется Линусом Торвальдсом и ничем другим. P>Чушь.
За три месяца его бы не подхватило такое количество народу, не будь он написан Линусом.
А если кто-то, кроме Линуса, написал бы такое на простых Сях, как написан git, то его бы съели без разделки тушки.
Популярность git и его язык реализации определяется популярностью Линуса Торвальдса и ничем больше.
P>Популярность git сейчас определяется только тем, что он банально лучше всех остальных. Практически по всем параметрам. Зачастую — на порядок.
Насчёт "сейчас" — отлично.
"Практические по всем" параметрам, как я понимаю, включает в себя и разнообразные возможности.
Cherry picking, anyone?
Я с него не слезу.
P>Так что разворачивай, как говориться!
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, pgregory, Вы писали:
P>>Для программирования простых вещей на хаскеле необходимо знать сложное понятие монада. (Посмотри оглавление Real World Haskell, прежде чем возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном языке, чтобы оперировать числами, не требуется знать, что такое коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это опровергающую, ок?)
L>Вот ты можешь объяснить, почему монада в Хаскеле — это сложно, а ООП в Питоне — просто? Это возвращение к дискуссии о том, что сложность в обучении и использовании — разные вещи.
Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
Лично я не могу привести таких же аналогий для фп. Можешь попробовать, я буду рад, если это возможно.
Side note: я не утверждаю, что ООП сколько-нибудь хорошо аппроксимирует реальность. На этот счет у меня самого к ООП большие претензии. Я утверждаю, что ООП — это просто и на пальцах. Это яблоки и кнопочки.
L>Ещё момент. Абстракция — это хорошо. Я в это верю, как ты веришь в то, что реальный язык реально прост. Аргументом для меня является тот факт, что программирование — это по большей части избавление от дублирования кода.
Программирование — это искусство абстракции с ограничениями.
L>Поэтому для меня простой язык — это язык, в котором есть высокоуровневые абстракции. И чем выше уровень, тем меньше зависимость от деталей реализации, а значит лучше, т.к. ближе к предметной области.
L>При этом сложность в изучении этих абстракций (или инструментов их порождающих) не принимается во внимание ;-) Поэтому реально простой язык вполне может быть сложным в изучении.
Вот здесь я не согласен. Я не вижу причины, по которой язык очень высокого уровня должен быть хоть сколько-нибудь сложным. Представь его в виде слоеной штуки, где каждый уровень выше и проще предыдущего в том же смысле, что си выше и проще ассемблера.
L>Где у меня ошибка в рассуждениях?
Нигде. Просто у нас разные мнения. Если бы существовало единственное правильное, этого спора просто не было бы.
pgregory wrote:
> RWH о них рассказал, потому что это просто занятно, или же потому, что > их реально надо знать? Что-то он про коммутативные кольца молчит. Как и
Научить пользоваться списками, do, Maybe и прочим можно и без монад. А вот взорвать мозг и сказать, что все эти на первый взгляд абсолютно разные вещи — лишь частные случаи некой штуки, которую мы называем монада. По-моему, это просто красиво.
> Страуструп молчит о том, что шаблоны плюсов — Тьюринг-полный ФЯП. С чего бы?
Далеко не все программеры, к сожалению, понимают что онзачает "Т-п ФЯП". Поэтому это упоминание ничего нового не даст. Мало того, эта Т-п шаблонов — настолько монстроидальна, что лучше об этом забыть как о страшном сне. Километровые совершенно неосымсливаемые сообщения об ошибках, время компиляции... брр.. Эстетики никакой.
> Заодно, сказал раз, скажи и два. Haskell for Dummies, где нет упоминаний > о монадах — в студию!
А ты мне C for Dummies где нет этой злобной арифметики указателей, о которую столько копий сломали.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, pgregory, Вы писали:
P>Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
P>Лично я не могу привести таких же аналогий для фп. Можешь попробовать, я буду рад, если это возможно.
функция — это отображение входных данных в выходные. к примеру, если у тебя стакан наполовину пуст, то функция id отобразит его в стакан, который наполовину полон
Как приятно отвечать, когда точно знаешь, что оппонент не прав!
Здравствуйте, thesz, Вы писали:
P>>В этой презентации (от 24 сентября 2005 года) утверждается, что у darcs — 91 контрибьютор, у git — 79. На тот момент. Вот только, согласно википедии, разработка darcs началась на 3 года раньше, чем git'а. На момент презентации git'у было 4-5 месяцев.
T>Это какого darcs? Что на плюсах или на что Хаскеле?
У тебя, извини, википедия перестала открываться?
«Darcs evolved out of David Roundy's efforts to design a new patch format for GNU arch in June 2002. These discussions didn't lead to any code being committed to arch, but did lead to his theory of patches. After writing an initial version of darcs in C++, the Haskell version was written in Autumn 2002 and released to the public in April 2003.»
«The development of Git began on 3 April 2005.[33] The project was announced on 6 April,[34] and became self-hosting as of 7 April.[33] The first merge of multiple branches was done on 18 April.[35] Torvalds achieved his performance goals; on 29 April, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second.[36] On 16 June, the kernel 2.6.12 release was managed by Git.[37]»
И да, если то, что ты писал, оказалось неверным, мне было бы очень приятно, если бы ты не просто скипал это при ответах, а писал что-то типа «да, был не прав» Со своей стороны подобное обещаю.
T>За три месяца его бы не подхватило такое количество народу, не будь он написан Линусом.
Возможно. И?
T>А если кто-то, кроме Линуса, написал бы такое на простых Сях, как написан git, то его бы съели без разделки тушки.
а) спорно
б) ни о чем
T>Популярность git и его язык реализации определяется популярностью Линуса Торвальдса и ничем больше.
Еще раз, это чушь. Список крупных проектов, использующих git, я уже приводил здесь
. Ок, вычеркнем из него git и linux. А теперь докажи свой забавный тезис о том, что оставшиеся выбрали его из-за неимоверной любви к Линусу.
T>"Практические по всем" параметрам, как я понимаю, включает в себя и разнообразные возможности.
T>Cherry picking, anyone?
T>Я с него не слезу.
Зря, очень зря — это заранее проигрышная позиция.
Для начала, cherry-pick есть и в git, и в hg. Да, безо всяких алгебр. Тупее некуда.
Но. Цитирую свой первый пост в теме:
«Уважаемые защитники ФП! Здоровы ли вы? Работали ли вы когда-нибудь с исходным кодом программ? Известно ли вам, что между патчами существуют и _более_ сложные зависимости, чем то, что два патча один за другим модифицируют одно и то же место кода? (И, более того, эти более сложные, неявные, зависимости — правило, а не исключение?)
До тех пор, пока эта мега-алгебра не сможет разрешать такие зависимости (а этого она не сможет никогда — к слову, она хоть компилируемость программы (хоть на хаскелле) гарантирует при существующем авто-черри-пике?), она будет практически бесполезна. Черри-пик всегда будет операцией, при выполнении которой надо 7 раз подумать. И никакая алгебра тут не спасет.»
Не согласен?
И далее:
«Алгебра патчей, как мы видим, это киллер фича, да? И то, что другие dvcs ее не имеют, ставит их на ступеньку ниже, так? Очевидно, что любой вменяемый разработчик должен выбрать darcs, получается. А что мы имеем на самом деле?»
Я-то писал, что я вижу. Может, у тебя на этот счет другая точка зрения, и лидеры проектов только и ждут, когда-же наконец git получит алгебру патчей?
T>http://darcs.net/ — багтрекер есть T>http://git-scm.com/ — багтрекера нет.
T>Почему так, я не знаю. Но быстро сравнить серьёзность и количество открытых ошибок я не могу.
Я помогу. Быстро сравни серьезность и количество использующих их проектов. Начни с GHC.
Здравствуйте, ., Вы писали:
.>pgregory wrote:
>> RWH о них рассказал, потому что это просто занятно, или же потому, что >> их реально надо знать? Что-то он про коммутативные кольца молчит. Как и .>Научить пользоваться списками, do, Maybe и прочим можно и без монад. А вот взорвать мозг и сказать, что все эти на первый взгляд абсолютно разные вещи — лишь частные случаи некой штуки, которую мы называем монада. По-моему, это просто красиво.
То есть, ты считаешь, что везде о монадах пишут просто для красоты изложения? Здесь наши взгляды серьезно расходятся.
>> Страуструп молчит о том, что шаблоны плюсов — Тьюринг-полный ФЯП. С чего бы? .>Далеко не все программеры, к сожалению, понимают что онзачает "Т-п ФЯП". Поэтому это упоминание ничего нового не даст. Мало того, эта Т-п шаблонов — настолько монстроидальна, что лучше об этом забыть как о страшном сне. Километровые совершенно неосымсливаемые сообщения об ошибках, время компиляции... брр.. Эстетики никакой. ;)
Согласен, но это не по теме.
>> Заодно, сказал раз, скажи и два. Haskell for Dummies, где нет упоминаний >> о монадах — в студию! .>А ты мне C for Dummies где нет этой злобной арифметики указателей, о которую столько копий сломали.
1) Арифметика указателей злобная, но простая. Она — арифметика.
2) Я первый спросил :-)
Здравствуйте, pgregory, Вы писали:
P>Лично я не могу привести таких же аналогий для фп. Можешь попробовать, я буду рад, если это возможно.
Ага! И у нас пойдёт философский спор существительные против глаголов
P>Вот здесь я не согласен. Я не вижу причины, по которой язык очень высокого уровня должен быть хоть сколько-нибудь сложным. Представь его в виде слоеной штуки, где каждый уровень выше и проще предыдущего в том же смысле, что си выше и проще ассемблера.
Я не говорил "должен", я говорил "может". Слоёная штука относится к обучению, IMHO.
P>>>Я целиком за использование хороших яп вместо плохих яп. Вопрос в том, что же такое хороший яп? Хороший яп — это тот, который позволяет тебе мыслить на более высоком уровне, чем до этого, будучи сам по себе простым до очевидности. Сорри за курсив Хороший яп должен «fit my mind». Он не должен требовать огромного багажа знаний, чтобы начать его использовать. Пример однозначно хорошего языка — питон. Или С. T>>Перевод: "хороший яп — тот, что я знаю прямо сейчас." P>Чушь. P>Можешь читать мои слова буквально, без переводов?
Да у тебя именно это и написано. Открытым текстом.
"Перевод", конечно, надо было бы заменить на "тезис высказывания", моя вина.
P>У меня есть точка зрения, что такое хороший яп, а что — нет. Основная мысль в том, что реально хороший язык реально прост. Я ее высказал и попытался обосновать. Того, что ты усмотрел, в ней и близко нет. Замечания по сути есть?
"Реально прост" чем определяется?
Хаскель реально прост теоретически. У него внутре неонка, то есть, ЛИ с нормальным порядком упрощений. Все его конструкции могут быть записаны на этом ЛИ. Да даже типы у него функции:
instance Monad m where-- m - параметр
return :: m a -- из этого следует, что m - функция из типа в тип.
...
С помощью ЛИ можно сделать всё, что есть внутри Хаскеля. if-then-else, if-then, циклы. Даже сравнение с образцом. Type safe pattern matching combinators
Coq/Agda2 ещё проще в теоретическом плане. В Coq товарищи ради прикола сделали реализацию типов классов, не выходя за рамки языка. То же самое я сделал для Agda2 после небольшого количества экспериментов.
Tcl. Надо выучить, что такое список и как он связан с синтаксисом команды. И как протаскиваются коды исключений. Далее делается сравнение с образцом на тикле и почти всё, что душе угодно. Я это использовал во внутреннем компиляторе с SQL constraints.
Пролог. Отличная штука.
Теперь смотрим на Питон. Можно ли выделить минимальное подмножество Питона, на котором можно выразить всё остальное в Питоне? Можем ли мы расширить язык новыми управляющими конструкциями?
Смотрим на Си, C++, C# или Java. Система типов совершенно не связана с моделью вычислений. В C++ этот отрыв ещё сильней.
Кто оказывается "реально прост"?
Тот, что ты знаешь прямо сейчас и похож на уже знакомое, или то, что ты можешь прогнуть под себя с минимумом усилий после изучения?
Your language is hard to learn. My language is easy to learn, because I already know it. People won’t learn what they don’t already know.
T>>Твоё высказывание прямо классическая демонстрация принципа. T>>Я думаю, что если специально стараться, так не получится. Значит, ты искренен. T>>Это хорошо. Значит, тебя можно переубедить. P>Я абсолютно искренен. Только вот того, что ты пытаешься мне пришить, руководствуясь стереотипами, во мне нет.
Перечисли стереотипы, которыми я руководствуюсь.
Мне, что-то, начали надоедать наезды ad hominem.
P>>>Проблема хаскеля в том, что он, с одной стороны, высокоуровневый (что хорошо), а с другой — взрывает мозг при попытке хотя бы освоить хороший учебник вроде «Real World Haskell». Потому, что он реально сложен. И это плохо. Конечно, возможно, проблема в моей личной глупости. Но, честно говоря, я, как и все считаю себя above average. T>>Я считаю себя above average, у меня взрывает мозг при изучении теории типов и я её намеренно изучаю: за взрывом мозга и за расширением сознания. P>Рад за тебя. Это как-то противоречит моей мысли о том, что такому не место в мейнстриме?
Да. Моя мысль вот какая: интеллектуальной трусости не место в мейнстриме.
P>>>Что ж, теперь попробую доказать «не дает ничего». Использование хорошего яп в смысле, определенном выше — это однозначно правильно. Это надо делать при любой возможности. Но. Хаскель не удовлетворяет определению однозначно хорошего языка. Поэтому, вместе с высокоуровневостью он принесет в проект свою сложность. (До сих пор помню, как в одном из популярных учебников по хаскелю monomorphism restriction встречалось чуть ли не сразу после вещей проде 1 + 1). И в этом смысле, сам по себе факт использования хаскеля не дает ничего. Ты в чем-то выигрываешь, а в чем-то (и серьезно!) проигрываешь. T>>Если мы проигрываем (и серьёзно!) в не нужной для решения наших задач области, то мы выигрываем в общем и целом. T>>Я к чему. Сейчас задачи такие, что вред от использование Хаскеля минимален. В том смысле, что да, Хаскель сильно нетороплив, но сейчас быстрые процессора, да он, еще, и параллелится легко. И дальше по аналогии. P>Ты пишешь какую-то ерунду. Где в моем сообщении упоминалась скорость? Там упоминалось другое слово на букву «с» — сложность.
Okay, mea culpa.
Но и со сложностью ты перегнул. Хаскель не сложней C++, как язык, а в использовании проще, чем Java.
Бляха муха, вот три основных части: функции + алгебраические типы + монады.
У меня 90% кода такого.
P>>>Am I clear? T>>Pretty clear. P>Боюсь, ты по-быстрому загнал меня в стереотип тупых нелюбителей хаскеля и толком даже не прочитал, что я написал. Жаль.
В этом нет ничего страшного. Являться тебе в снах и хохотать "ХА-ХА-ХА-ХАСКЕЛЬ!!!" над застывшим в ужасе тобой я не буду.
Поскольку ты уже выбрал свою синюю пилюлю, то и жалеть не о чем.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, pgregory, Вы писали:
P>Да ладно! Законченная-то законченная, только ничего не объясняющая. Иначе все монадные туториалы представляли бы из себя одну-единственную фразу.
Цель монадных тьюториалов — научить вас новой абстракции. Есть другой путь, по нему пошли Scala и C# — делать вид, что за монадами нет никакой абстракции, а просто есть некоторые удобные фичи языка. В "Programming in Scala" на 514 странице вскользь
упоминается, что "for comprehensions" — это и есть монада — дальше никто не углубляется.
abstract class C[A] {
def map[B](f: A => B): C[B]
def flatMap[B](f: A => C[B]): C[B]
def filter(p: A => Boolean): C[A]
def foreach(b: A => Unit): Unit
}
...
Concentrating on just the first three functions, the following facts are
noteworthy. In functional programming, there’s a general concept called a
monad, which can explain a large number of types with computations, ranging
from collections, to computations with state and I/O, backtracking computations,
and transactions, to name but a few. You can formulate functions
map, flatMap, and filter on a monad, and, if you do, they end up having
exactly the types given above. Furthermore, you can characterize every
monad by map, flatMap, and filter, plus a “unit” constructor that produces
a monad from an element value. In an object-oriented language, this “unit”
constructor is simply an instance constructor or a factory method. Therefore,
map, flatMap and filter can be seen as an object-oriented version of
the functional concept of monad. Because for expressions are equivalent to
applications of these three methods, they can be seen as syntax for monads
В долгосторочной перспективе первый подход лучше — как учил нас старик Перлис: Accumulate idioms. Standardize.
С точки зрения PL коммивояжера — возможно лучше второй.
Здравствуйте, pgregory, Вы писали:
P>Или ты реально считаешь, что FP так же интуитивно, как и ООП? (Чувствую, как люди с горящими глазами бросились писать «Да! Да! Да!!!»
Можно раскрыть тему интуитивности ООП?
А то у меня такое ощущение, что его почти никто не понимает (уж пользоваться точно не умеет).
Об интуитивности даже речь не идёт.
Поэтому реально простой язык вполне может быть сложным в изучении.
