со стекедж2никс чегото зависимости от разных версий либ, stack2nix пытается устанавливать ghc зачем-то

блин quality software

Проблема значительной части материалов по продвинутым фишкам Haskell в том, что она пишется математиками и для математиков. И вместо того, чтобы объяснять и показывать использование, в этих материалах предмет вводится аксиоматически, а потом обсуждаются его свойства. Ну вроде такого: "Такую-то вещь мы называем Type Family и записываем вот так: blah-blah И теперь мы получаем возможность записывать на уровне типов то-то и то-то, при этом мы должны следить, чтобы типы были такими-то и такими-то, потому что механизм вывода типов имеет недостатки" Это ничуть не лучше, чем вводить понятие монады через пресловутый моноид в категории эндофункторов, а потом обсуждать, какие же у монады должны быть законы. Меня совершенно не интересует математическая постановка проблемы и следствия из аксиоматически заданных конструкций. Я хочу видеть сначала практическую задачу, которую пытаются решить другим способом, и это получается не очень. Потом я хочу видеть объяснение, почему подфича Х-1 из набора большой фичи Х здесь может помочь лучше, чем что-то другое. Потом я хочу видеть конкретно этот пример, решенный с помощью подфичи Х-1, а не изучать аксиоматически введенный набор Х-1, Х-2, Х-3, потому что уже сказано, что Х-2 и Х-3 к задаче не имеют отношения. И уж тем более мне не интересно, что там у Х-1, Х-2 или Х-3 за математические следствия, распространяющиеся на дизайн языка. Конечно, математикам такая форма подачи привычна и удобна. Даем вводную и разворачиваем следствие. Но это не то, как пишется реальный софт и решаются реальные задачи. И это не то, как мыслят большинство программистов.

Проблема значительной части материалов по продвинутым фишкам Haskell в том, что она пишется математиками и для математиков. И вместо того, чтобы объяснять и показывать использование, в этих материалах предмет вводится аксиоматически, а потом обсуждаются его свойства. Ну вроде такого: "Такую-то вещь мы называем Type Family и записываем вот так: blah-blah И теперь мы получаем возможность записывать на уровне типов то-то и то-то, при этом мы должны следить, чтобы типы были такими-то и такими-то, потому что механизм вывода типов имеет недостатки" Это ничуть не лучше, чем вводить понятие монады через пресловутый моноид в категории эндофункторов, а потом обсуждать, какие же у монады должны быть законы. Меня совершенно не интересует математическая постановка проблемы и следствия из аксиоматически заданных конструкций. Я хочу видеть сначала практическую задачу, которую пытаются решить другим способом, и это получается не очень. Потом я хочу видеть объяснение, почему подфича Х-1 из набора большой фичи Х здесь может помочь лучше, чем что-то другое. Потом я хочу видеть конкретно этот пример, решенный с помощью подфичи Х-1, а не изучать аксиоматически введенный набор Х-1, Х-2, Х-3, потому что уже сказано, что Х-2 и Х-3 к задаче не имеют отношения. И уж тем более мне не интересно, что там у Х-1, Х-2 или Х-3 за математические следствия, распространяющиеся на дизайн языка. Конечно, математикам такая форма подачи привычна и удобна. Даем вводную и разворачиваем следствие. Но это не то, как пишется реальный софт и решаются реальные задачи. И это не то, как мыслят большинство программистов.

+

Hot Kosc (0) увеличил репутацию Александр Гранин (1)

Проблема значительной части материалов по продвинутым фишкам Haskell в том, что она пишется математиками и для математиков. И вместо того, чтобы объяснять и показывать использование, в этих материалах предмет вводится аксиоматически, а потом обсуждаются его свойства. Ну вроде такого: "Такую-то вещь мы называем Type Family и записываем вот так: blah-blah И теперь мы получаем возможность записывать на уровне типов то-то и то-то, при этом мы должны следить, чтобы типы были такими-то и такими-то, потому что механизм вывода типов имеет недостатки" Это ничуть не лучше, чем вводить понятие монады через пресловутый моноид в категории эндофункторов, а потом обсуждать, какие же у монады должны быть законы. Меня совершенно не интересует математическая постановка проблемы и следствия из аксиоматически заданных конструкций. Я хочу видеть сначала практическую задачу, которую пытаются решить другим способом, и это получается не очень. Потом я хочу видеть объяснение, почему подфича Х-1 из набора большой фичи Х здесь может помочь лучше, чем что-то другое. Потом я хочу видеть конкретно этот пример, решенный с помощью подфичи Х-1, а не изучать аксиоматически введенный набор Х-1, Х-2, Х-3, потому что уже сказано, что Х-2 и Х-3 к задаче не имеют отношения. И уж тем более мне не интересно, что там у Х-1, Х-2 или Х-3 за математические следствия, распространяющиеся на дизайн языка. Конечно, математикам такая форма подачи привычна и удобна. Даем вводную и разворачиваем следствие. Но это не то, как пишется реальный софт и решаются реальные задачи. И это не то, как мыслят большинство программистов.

+

Too fast! Try again later.

И это не то, как мыслят большинство людей :) Я хоть математике и обучался, но такой подход не люблю )

Лютобешено короче.

Зато такой подход и правда помогает авойдить саксесс эт эни кост.

Зато такой подход и правда помогает авойдить саксесс эт эни кост.

это 100%

как и сообщение выше

очевидно же, что человеку удобнее обучаться от частного к общему

разве нет?

а математические теории удобнее описывать в общем, потом доказывать для частных случаев, потому что если начать с частных, потом всё равно придётся доказывать и проходить по частным ещё раз. зачем бумагу переводить?

короче, описания теорий хороши для описания теорий и плохи для обучения навыкам

@bravit111, не так ли?

Проблема значительной части материалов по продвинутым фишкам Haskell в том, что она пишется математиками и для математиков. И вместо того, чтобы объяснять и показывать использование, в этих материалах предмет вводится аксиоматически, а потом обсуждаются его свойства. Ну вроде такого: "Такую-то вещь мы называем Type Family и записываем вот так: blah-blah И теперь мы получаем возможность записывать на уровне типов то-то и то-то, при этом мы должны следить, чтобы типы были такими-то и такими-то, потому что механизм вывода типов имеет недостатки" Это ничуть не лучше, чем вводить понятие монады через пресловутый моноид в категории эндофункторов, а потом обсуждать, какие же у монады должны быть законы. Меня совершенно не интересует математическая постановка проблемы и следствия из аксиоматически заданных конструкций. Я хочу видеть сначала практическую задачу, которую пытаются решить другим способом, и это получается не очень. Потом я хочу видеть объяснение, почему подфича Х-1 из набора большой фичи Х здесь может помочь лучше, чем что-то другое. Потом я хочу видеть конкретно этот пример, решенный с помощью подфичи Х-1, а не изучать аксиоматически введенный набор Х-1, Х-2, Х-3, потому что уже сказано, что Х-2 и Х-3 к задаче не имеют отношения. И уж тем более мне не интересно, что там у Х-1, Х-2 или Х-3 за математические следствия, распространяющиеся на дизайн языка. Конечно, математикам такая форма подачи привычна и удобна. Даем вводную и разворачиваем следствие. Но это не то, как пишется реальный софт и решаются реальные задачи. И это не то, как мыслят большинство программистов.

+++++

короче, описания теорий хороши для описания теорий и плохи для обучения навыкам

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

Я, конечно, не бравит, но опыт показывает, что нужно и то и то

Хорошо дать пример в начале как "интуицию"

Но обязательно акцентировать внимание, что эти лишь пример и теоретическое описание гораздо шире

Лучше два-три примера

Потому что та же монада-буррито ничем не лучше монады-моноида

И слишком узкое и слишком формальное понимание оба одинаково непродуктивны

Я, конечно, не бравит, но опыт показывает, что нужно и то и то

+

Alexander Vershilov (0) увеличил репутацию Oleg ℕizhnik (1)

научиться по примерам без знания теории нельзя

приму как контр-аргумент наличие человека обучившегося языку по duolingvo

без теории

в какой-то момент в дуолинго (~26%) перелом наступает, и незнание теории сильно мешает двигаться дальше.. у тебя просто нет выбора, сорри за оффтоп

> дуолинго Что это? Гугль выдает только какое-то приложение

научиться по примерам без знания теории нельзя

мне наоборот наличие теории без примера ничего не дает. я могу обучаться на теории, но когда четко понятно для чего эта абстрактная абстракция

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

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

я увы к примеру только типа пройдя 3ий курс универа и вышку

просто понял смысл функции!

это лол если честно

потому что абстарктрые абстракторы обучают заезженному материалу

> дуолинго Что это? Гугль выдает только какое-то приложение

приложение для обучения языку X на языке Y через примеры

> Конечно, математикам такая форма подачи привычна и удобна. Даем вводную и разворачиваем следствие. Но это не то, как пишется реальный софт и решаются реальные задачи. И это не то, как мыслят большинство программистов.

Упс, не ответилось

В общем, фигня это

В общем, фигня это

+

Pavel Meledin (0) увеличил репутацию Timofey Zakrevskiy (1)

могу напомнить про метод демидовича в универах

Это очень пагубное последствие школы Бурбаки

могу напомнить про метод демидовича в универах

давай

слушаем теорию и потом ручку в руки и решаем 100500 задач

Которые этот подоход и придумали

слушаем теорию и потом ручку в руки и решаем 100500 задач

+

Andrey (0) увеличил репутацию Alexander Vershilov (1)

пример хорош один перед введением, чтобы понятно о чем речь

И стали так писать учебники, а потом все стали бездумно этот подход копировать

И стали так писать учебники, а потом все стали бездумно этот подход копировать

+

Too fast! Try again later.

и я не знаю почему все бросаются в экстремумы: теория без практики, практика без теории

какой strawman

Все приличные курсы математики построены как раз "от конкретной задачи - попытка решения, от попытки решения - теория и обобщения"

я понимаю, что вы очень хотите доказать, что я прав, спасибо за это

и я не знаю почему все бросаются в экстремумы: теория без практики, практика без теории

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

Хм, это не _blah, сорри. Просто я преподавал несколько лет математику на родине подхода Бурбаки, наболело

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

в основном сначала описывается решаемая задача

единственное место к которому может быть претензия это к ghc users guide

Проблема значительной части материалов по продвинутым фишкам Haskell в том, что она пишется математиками и для математиков. И вместо того, чтобы объяснять и показывать использование, в этих материалах предмет вводится аксиоматически, а потом обсуждаются его свойства. Ну вроде такого: "Такую-то вещь мы называем Type Family и записываем вот так: blah-blah И теперь мы получаем возможность записывать на уровне типов то-то и то-то, при этом мы должны следить, чтобы типы были такими-то и такими-то, потому что механизм вывода типов имеет недостатки" Это ничуть не лучше, чем вводить понятие монады через пресловутый моноид в категории эндофункторов, а потом обсуждать, какие же у монады должны быть законы. Меня совершенно не интересует математическая постановка проблемы и следствия из аксиоматически заданных конструкций. Я хочу видеть сначала практическую задачу, которую пытаются решить другим способом, и это получается не очень. Потом я хочу видеть объяснение, почему подфича Х-1 из набора большой фичи Х здесь может помочь лучше, чем что-то другое. Потом я хочу видеть конкретно этот пример, решенный с помощью подфичи Х-1, а не изучать аксиоматически введенный набор Х-1, Х-2, Х-3, потому что уже сказано, что Х-2 и Х-3 к задаче не имеют отношения. И уж тем более мне не интересно, что там у Х-1, Х-2 или Х-3 за математические следствия, распространяющиеся на дизайн языка. Конечно, математикам такая форма подачи привычна и удобна. Даем вводную и разворачиваем следствие. Но это не то, как пишется реальный софт и решаются реальные задачи. И это не то, как мыслят большинство программистов.

да нет такой проблемы у значительной части материалов, к примеру, в реальном пейпере про семейства типов все не так как в этом описании гипотетического пейпера https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jones/typefun.pdf

ERROR: S client not available

в пейперах, особенно если там в соавторах спж, пример есть всегда

более того в его докладах как делать доклады и как писать пейперы это первый пункт - начинать с примера

не обязательно спж, вообще в типичном пейпере есть и неформальное описание с примерами и формальное. Если уж на то пошло второго может не быть чаще, чем первого

(если речь про хаскельные пейперы)

Это как монады учить -- если по туториалам, то нифига не понятно, а если по Typeclassopedia -- всё ясно

мне пришло осознание именно во время туториала по написанию своей стейт-монады

А должно было - во время чтения Typeclassopedia!

you may have already invested Monad клевое было

и я не знаю почему все бросаются в экстремумы: теория без практики, практика без теории

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

теория о том, что теория не предваряется примерами в хаскельных пейперах должна предваряться примерами пейперов в которых не предваряется

я вот посмотрел три пейпера про семейства, все с примерами Ж(((

Вот к примеру линзы. Там чего больше: теории или примеров?

примеров наверное

пейперы про линзы еще найти надо

я помню пару пейперов, причем ни один из них не по ван-лаарховенским, так что даже если там одна теория, то можно сказать что по линзам в основном только примеры

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

факт в том, что нету примеров, где она даётся без практики

какой-то придуманную башню ломаем

факт в том, что нету примеров, где она даётся без практики

@graninas, расскажи, чем у тебя вызвано возгорание?

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

т.е. я так понял, что возможно проблема в том что в мануалах больно много теории, и лучше бы ее не было, а была практика

@graninas, расскажи, чем у тебя вызвано возгорание?

Не, не расскажу, потому что мое видение, как должна быть устроена обучающая документация, противоречит тому, как ее видите вы, топовые хаскеллисты.

Это что-то вроде профессиональной деформации

Не, не расскажу, потому что мое видение, как должна быть устроена обучающая документация, противоречит тому, как ее видите вы, топовые хаскеллисты.

в чем противоречие-то? Вы можете на реальной документации продемонтрировать?

Могу но не стану

Может, позже. Сейчас лень искать

значит, нет и противоречия

И новички с тобой тоже согласятся?

И новички с тобой тоже согласятся?

почему со мной? ты сделал утверждение, и отказываешься его доказывать

почему со мной? ты сделал утверждение, и отказываешься его доказывать

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

пейперы про линзы еще найти надо

во, нашёл! но да, маловато на эту тему. https://dl.acm.org/citation.cfm?id=3236779 вот ещё, но этот закрыт :( https://dl.acm.org/citation.cfm?doid=2784731.2784750

Хорошо дать пример в начале как "интуицию"

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

В приведенной доке по TF, например, первый же пункт (2.1) - не дожимает мысль до конца. Где пример того, как изменится функция readAndPrint после введения новой конструкции? Ну ввели, а использовать-то как? Что мне писать нужно в определении типа? Как задачу-то основную решили?