Я в эту сторону не ходил ) но надо попробовать

Думаю, жизнеспособный подход, но не раньше, чем появятся implicit function types

Я в эту сторону не ходил ) но надо попробовать

вот, полчаса гуглил, как это правильно называется, в хачкеле есть https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/constraint-kind.html

type Monad[F] = (Pure[F], FlatMap[F])

о да

т.е. проецируя на скалу ты мог бы сказать type Monad[F] = (FlatMap[F] , Apply[F], Pure[F]) и потом просто заюзать

прикольно

Почему в мониксе Task[Throwable] бросает исключение ?

в какой момент? :)

забавно )

Есть такое val k = for(i<-0 until 100) yeild Task { что -то там }.timeout(100 miliseconds).flatmap(Task(1)) val task = Task .gatherUnordered(k) .runAsync .flatMap(x => Future(x.sum)) Await.result(task, Duration.Inf) task.foreach(println)

Я правда спал час, поэтому не кидайтесь камнями сильно

Интересная статья о том как называть типы и переменные - http://degoes.net/articles/insufficiently-polymorphic Юрий

недостаточно полиморфный юрий

недостаточно полиморфный юрий

?

Интересная статья о том как называть типы и переменные - http://degoes.net/articles/insufficiently-polymorphic Юрий

"как сделать код неподдерживаемым"

вроде же полгода назад уже об этом говорили)

Интересная статья о том как называть типы и переменные - http://degoes.net/articles/insufficiently-polymorphic Юрий

спасибо большое за ссылку на статью, лично для меня она расставила некоторые важные вещи на свои места, сначала я был скептично настроен, но почитав - проникся, а от комментов стало еще понятнее (http://disq.us/p/1f5mcj2). Видимо где-то на пути мне в голову вдолбилось что делать очень абстрактные/общие решения - это как раз зря тратить время и решать больше проблем чем тебе нужно (+ как правило еще и дольше), в сравнении более конкретным решением, и такая интуиция продержалась во мне дольше чем нужно... а эта статья показала совсем обратное. теперь надо следить за реальными примерами в работе, искать правильное время/место для использования подобных абстракций. Есть ли какие-то ссылки на примеры из этой темы? ну типа есть такая-то фича, берем выкидываем ее детали, остается суть которая мапится на какой-то концепт из ФП

Хеййоу, есть кто на скаладейз едет? Может скооперируемся на месте? Толпой явно веселее город смотреть

В Копенгаген?

Блин она сегодня началась лол

Ну не совсем сегодня но да

спасибо большое за ссылку на статью, лично для меня она расставила некоторые важные вещи на свои места, сначала я был скептично настроен, но почитав - проникся, а от комментов стало еще понятнее (http://disq.us/p/1f5mcj2). Видимо где-то на пути мне в голову вдолбилось что делать очень абстрактные/общие решения - это как раз зря тратить время и решать больше проблем чем тебе нужно (+ как правило еще и дольше), в сравнении более конкретным решением, и такая интуиция продержалась во мне дольше чем нужно... а эта статья показала совсем обратное. теперь надо следить за реальными примерами в работе, искать правильное время/место для использования подобных абстракций. Есть ли какие-то ссылки на примеры из этой темы? ну типа есть такая-то фича, берем выкидываем ее детали, остается суть которая мапится на какой-то концепт из ФП

У меня есть пример недавний. Была функция, которая работала с набором бизнес специфик сущностей (вытащить задачи в соответствии с разными условиями). Добавляя новый код я заметил, что в нескольких местах делаются похожие вещи. Я это вытащил в отдельные функции и получил набор типовых "алгоритмов" работающих с множествами. Сами эти "алгоритмы" были довольно простыми и понятными. Т.е. в условной функции getIssue(params) вместо case specific кода были другие функции которые дергали всякие intersect и проч.

Правда это не совсем про ФП.

Правда это не совсем про ФП.

Whether in OOP or FP, the effect is the same: making the code more polymorphic reduces the space of possible implementations.

Whether in OOP or FP, the effect is the same: making the code more polymorphic reduces the space of possible implementations.

Никита просил пример про то, как что-нибудь "мапится на какой-то концепт из ФП".

99% статей в этих ваших интернетах про фп с абстрактными примерами надуманных нереалистичных проблем, которые авторы героически решают манатками, вот у людей вопросы и возникают само собой

Никита просил пример про то, как что-нибудь "мапится на какой-то концепт из ФП".

Ну я полагаю, что он имел что-то вроде ClientProductBuilderFactoryObserver превратившегося в какой-то Traverse + Iso + State с инстансами к кейзклассикам

99% статей в этих ваших интернетах про фп с абстрактными примерами надуманных нереалистичных проблем, которые авторы героически решают манатками, вот у людей вопросы и возникают само собой

Ну надо иметь воображение, вашу проблему никто в статьях решать не будет )

99% статей в этих ваших интернетах про фп с абстрактными примерами надуманных нереалистичных проблем, которые авторы героически решают манатками, вот у людей вопросы и возникают само собой

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

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

я ничего не понял, одно длинное предложение с кучей знаков препинания и непонятно расставленными акцентами :)

Ну я полагаю, что он имел что-то вроде ClientProductBuilderFactoryObserver превратившегося в какой-то Traverse + Iso + State с инстансами к кейзклассикам

Именно. Я пока такой не нашёл.

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

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

Ну надо иметь воображение, вашу проблему никто в статьях решать не будет )

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

я ничего не понял, одно длинное предложение с кучей знаков препинания и непонятно расставленными акцентами :)

>>> Был код >>> Сделал код лучше >>> Написал статью про основную идею >>> Куча кода, никак не относящегося к идее >>> Убрал лишний код .... >>> Anonymous commenter : Абстрактно и надумано!

плюсую вот это

99% статей в этих ваших интернетах про фп с абстрактными примерами надуманных нереалистичных проблем, которые авторы героически решают манатками, вот у людей вопросы и возникают само собой

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

>>> Был код >>> Сделал код лучше >>> Написал статью про основную идею >>> Куча кода, никак не относящегося к идее >>> Убрал лишний код .... >>> Anonymous commenter : Абстрактно и надумано!

Во, так бы сразу, спасибо. ну да, по большей части согласен с тобой, что люди часто переоценивают статьи, но обычно попадаются статьи, где начинается с "давайте рассмотрим монаду XXX, чтобы её применить, мы реализуем, например, YYY, ....., profit, монада XXX просто супер!" То есть пример именно что придумывается и подгоняется именно чтобы написать статью про монаду XXX, а не как ты сказал - решение реальной проблемы.

Во, так бы сразу, спасибо. ну да, по большей части согласен с тобой, что люди часто переоценивают статьи, но обычно попадаются статьи, где начинается с "давайте рассмотрим монаду XXX, чтобы её применить, мы реализуем, например, YYY, ....., profit, монада XXX просто супер!" То есть пример именно что придумывается и подгоняется именно чтобы написать статью про монаду XXX, а не как ты сказал - решение реальной проблемы.

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

>>> Был код >>> Сделал код лучше >>> Написал статью про основную идею >>> Куча кода, никак не относящегося к идее >>> Убрал лишний код .... >>> Anonymous commenter : Абстрактно и надумано!

?

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

Да в целом в статьях не любят вещать про область применимости технологии, не только про фп так

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

??

У меня есть пример недавний. Была функция, которая работала с набором бизнес специфик сущностей (вытащить задачи в соответствии с разными условиями). Добавляя новый код я заметил, что в нескольких местах делаются похожие вещи. Я это вытащил в отдельные функции и получил набор типовых "алгоритмов" работающих с множествами. Сами эти "алгоритмы" были довольно простыми и понятными. Т.е. в условной функции getIssue(params) вместо case specific кода были другие функции которые дергали всякие intersect и проч.

спасибо больше, я понял твой пример, похожие случаи у меня тоже были :)

Ну я полагаю, что он имел что-то вроде ClientProductBuilderFactoryObserver превратившегося в какой-то Traverse + Iso + State с инстансами к кейзклассикам

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

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

чувак психанул https://habrahabr.ru/company/tinkoff/blog/323682/#comment_10240590

прямо мои мысли, только он все развернул)

+1

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

Ниче не понял

Это как давний спор про номинальные и структурные типы. Что лучше использовать — (Double, Double, Double) или final case class Gas(pressure: Double, temperature: Double, volume: Double). Сторонники ФП предпочитают первый тип,

ок

какие такие?

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

эт отсылка к той статье про имена от Де Гоеза

эт отсылка к той статье про имена от Де Гоеза

Вообще и близко там этого не упоминается

Это какая-то вырезка из дзен питона

какие такие?

прошу на хабр :)

*мне кажется, что* ...

ну вобщем далеко не всё, что он написал - херня

Об этом можно судить по столь нежно любимым всеми функциональщиками коммутативным диаграммам. Там есть пунктирный подвид стрелочек — «существует единственный морфизм». На этом единстве и построена вся теория. Произведение и копроизведение типов так и определяется — через единственность (с точностью до изоморфизмов). и что?

:q!

Каждый абзац - нелепый вброс

даже на хабр кинул

о чем наверное пожалею

уже :)

У меня ощущение, что я должен знать этого человека, но...

Рисковый вы парень, делать import сats._

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

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

Мне вот всегда подобное страшно, каких ещё имплиситных трансформацией принесёт с собой библиотека.

Что день грядущий нам готовит )

ответьте ему там, чего тут-то байты гонять

+

ответьте ему там, чего тут-то байты гонять

Сраться на хабре?

Сраться на хабре?

а что ещё там делать?

тем более под статьей про скалу, пффф

а что ещё там делать?

ничего, плюсовать чуваков из той же компании

писать и кидать ссылки в чат

:)

ничего, плюсовать чуваков из той же компании

ну мы же не в мэил ру работаем, к чему вот это =)

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

почти статья

И неочем

основных тезисов я так и не понял

я тоже не очень всек. особенно про тапл и кейс класс насмешило

основных тезисов я так и не понял

ФП - фашистская слишком строгая идеология, и в скале всё равно нормального ФП нет, поэтому всё норм

1. скала не FP 2. Он знает про universal construction 3. Юзал какую то ужасную либу 4. ООП лучше в REPL 5. Не понимает разницы между туплами и кейс классами 6. Скала не FP

2 - 5 можно убирать

и капсом остальное

1. скала не FP 2. Он знает про universal construction 3. Юзал какую то ужасную либу 4. ООП лучше в REPL 5. Не понимает разницы между туплами и кейс классами 6. Скала не FP

про туплы я думаю, та же фишка, что crafted monad vs transformers stack. Типа для туплов инстансы сами выводятся, а для кейзклассов надо ручками либо kittens

Поэтому автор полагает, что любителям ФП больше нравятся туплы

ответьте ему там, чего тут-то байты гонять

можно наоборот его сюда засумонить

У меня ощущение, что он здесь есть

Вполне

Ребзя, а что Java правда поддерживает Polymorphic SAM ?

https://issues.scala-lang.org/browse/SI-9916