уметь писать на ЯП haskell программы

Опытный работодатель, сразу видно!

иметь коммон сенс, и понимать, что фримонады - шляпа

но это не точно

не шляпа конечно, но и не панацея

я за несколько раз так и не понял, какой от них профит.

/me посмотрел на тайпкласс Backend с 30ю методами

я за несколько раз так и не понял, какой от них профит.

про них @astynax недавно голосом рассказывал

да я их вот этими самыми руками сначала в проект притаскивал

а потом выпиливал

ой

аналогичная история с turtle

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

Для комонад есть примеры с запиливанием Zipper'ов на оных. Ещё где-то была реализация Жизни конвеевской на комонадке

вопрос: какое умное название у конструкции вида: data Foo a b c construct :: Option a -> Option b -> Option c -> Option Foo ?

Э... выглядит, как liftA3

это явно работа для аппликативного функтора

Ну вот, скажем, Traversable, если аппликант не понимает его, сразу в бан?

неа

Traversable можно понять по описанию класса. Даже если ты новичок, но с тайпклассами, как концепцией знаком и про Monoid знаешь.

вопрос: какое умное название у конструкции вида: data Foo a b c construct :: Option a -> Option b -> Option c -> Option Foo ?

data Foo a b c = Foo a b c liftA3 Foo (Just 1) (Just 2) (Just 3) = Just (Foo 1 2 3) Foo <$> Just 1 <*> Just 2 <*> Just 3 = Just (Foo 1 2 3)

А у меня про работу есть вопрос как раз. Можешь сформулировать, что должен знать и уметь хаскелист для джуниор-позиции?

У меня несколько требований: 1) умение писать работающие программы на нужном ЯП. Практически любой степени (не)красивости и угловатости. Но чтобы работало. 2) уметь следовать ТЗ и правильные вопросы задавать. Если ТЗ просит написать одну функцию, то надо написать одну функцию, а не библиотеку на го. 3) всякая периферийная фигня, такая как знание средств разработки, баз данных и прочих вещей общих для всех ЯП

Traversable можно понять по описанию класса. Даже если ты новичок, но с тайпклассами, как концепцией знаком и про Monoid знаешь.

Я не согласен. Там всё-таки уровень абстракции высокий, это только опытый программист может быстро схватить.

Начинающий от f t a и t f a сдохнет сразу

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

У меня несколько требований: 1) умение писать работающие программы на нужном ЯП. Практически любой степени (не)красивости и угловатости. Но чтобы работало. 2) уметь следовать ТЗ и правильные вопросы задавать. Если ТЗ просит написать одну функцию, то надо написать одну функцию, а не библиотеку на го. 3) всякая периферийная фигня, такая как знание средств разработки, баз данных и прочих вещей общих для всех ЯП

Ага, хорошая формулировка, мне нравится

заметим, что из этих требований вообще легко удаляется слово haskell

если оно вообще в нём присутствует.

эти требования к любому ЯП применяются

ага

хаскелль тут ничем не примечателен на мой взгляд

только почему-то соискатели не всегда так думают

я старый враг примечательности хаскеля!

тут просто в чате когда начинают обсуждать высокие вещи - то новички сразу и разбегаются

соискатели пытаются пониманием комонад хвастаться?

я стараюсь избегать, ведь можно самому поплыть!

мне комонады для написания программ в жизни были нужны 0 раз

но это я наверное просто не знаю как их варить

А как же комонад костейт коалгебра?

кококо сокращенно

ку-клукс-клан

фриман вот говорит, что комонадами хорошо UI моделировать

в пурскрипте сектант каждый первый

Фриман пруф оф концепт либу так и не запилил

у них halogen самая популярная либа для UI

Галоген не такой и страшный теперь. Было хуже.

Фриман пруф оф концепт либу так и не запилил

ну как бы он ща сделал extensible effects через Day Convolution и через него же прототип линз

ну как бы он ща сделал extensible effects через Day Convolution и через него же прототип линз

А гуи?

А гуи?

в планах (на линзах же как раз можно сделать оптический gui)

разработаю ИИ чтоб на профункторах гуи

я спросил почему нельзя сделать такие эффекты в хаскелл (он написал) The Day convolution bit is possible, but the trick here is to represent an n-ary Day convolution using row polymorphism.

вообще я пока не могу понять на должном уровне Day Convolution

а это прокаченный Day Convolution https://github.com/paf31/purescript-smash/blob/master/src/Data/Smash.purs#L53

На PureScritp'е мы сейчас Web UI делаем с помощью портированного нашим коллегой reflex-dom: https://github.com/restaumatic/purescript-specular

хм

а зачем портировать рефлекс если есть почти такой же purescript-behaviors?

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

а вот например в halogen тоже вроде поначалу сигналы были и всякое фрп. в 0.4 вроде чому они отказались?

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

ну смотря какие требования к этой похожести на человека предъявлять

нормально собираться и собирать проекты

ставиться из каких-то источников

нормальных.

находиться под активной разработкой, работать над компактизацией кода и оптимизацией

нормально собираться и собирать проекты

так он собирается и юзается 8 ghc

web assembly ?

я что-то не уверен насчёт "нормально", у нас сборка одного проекта даже с никсом занимает часов пять

web assembly ?

так ghcjs и так собирает некую стейт машину что работает быстро

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

нормально собираться и собирать проекты

ну над этим какие-то люди вокруг рефлекса работают

короче всё это не выглядит, как что-то надежное / годное, а выглядит как маргинальное ответвление, это если еще сам ghc не считать чем-то маргинальным

не шляпа конечно, но и не панацея

Free монады - очень нужная концепция. Free-монадические языки решают ту же проблему, которую решают ООПшные интерфейсы, но в чисто функциональном стиле. Проблема называется коротко: Inversion of Control. Free-монады можно использовать в друх вариантах: - scenario-oriented eDSL - API-oriented eDSL Scenario-oriented eDSLs - это такие языки, на которых вы пишете бизнес-логику. Выражают предметную область, процессы и данные в ней. Такой DSL обычно спроектирован так, чтобы его методы были композабельные. API-oriented eDSL - это интерфейс к подсистеме. Композабельности методов относительно друг друга не требует, может представлять просто набор методов, абстрагирующих сервис.

а вот например в halogen тоже вроде поначалу сигналы были и всякое фрп. в 0.4 вроде чому они отказались?

https://github.com/MonoidMusician/purescript-halogen-behaviors

когда я их смотрел, то столкнулся с проблемой уже на уровне реализации ветвлений

находиться под активной разработкой, работать над компактизацией кода и оптимизацией

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

вот именно это и напрягает

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

когда я их смотрел, то столкнулся с проблемой уже на уровне реализации ветвлений

А в чем проблема была?

с тем, что было неочевидно, как делать ветвления в сценариях.

Ну просто if или case

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

У меня есть кой-какие примеры, да

доступны что бы посмотреть?

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

с тем, что было неочевидно, как делать ветвления в сценариях.

Если не хочется этот DSL сериализовать, то все конструкции языка валидны: myScenario :: Int -> Free MyDsl Int myScenario i = case i of 1 -> return 2 2 -> return 10 _ -> return i

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

может быть, уже есть более лучшие статьи по фримонадам, чем были год - два назад

доступны что бы посмотреть?

Да, у меня же для этого целый showcase проект есть (сопровождает книгу): https://github.com/graninas/Andromeda/blob/master/test/Test/ControlProgramSpec.hs

может быть, уже есть более лучшие статьи по фримонадам, чем были год - два назад

Два года назад case в Haskell уже был ;)

что-то тут какое-то недопонимание.

явно.

Поясните тогда

ну это надо найти статью, где описывалось применение

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

это о чем - HasFoo и подобные?

мне кажется тут про разное

@qnikst рассказывал, как они композят разные системы - это вот реализация явных API

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

Есть еще более продвинутый вариант - freer-монады. Мы их как раз сейчас в проекте используем.

т.е что решают, как решают, почему это лучше, чем решение без них

т.е то, о чем была статья - это просто реализация некоего Dsl, интерпретация которого могла меняться в зависимости от.