Реальные проекты на экзотике (Haskell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 29.08.19 18:31
Оценка:
Вот, некоторые люди на работе пишут на Haskell. Как они до этого доходят?

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

Где вообще можно научиться Haskell? Система образования чаще всего придерживается классики (C, C++, Java и на крайняк C#). Ну да, экзотике могут посвятить несколько часов — только чтобы глаза круглыми сделали.

Курсов по нему тоже нет — курсы есть на популярные технологии.

Как до него вообще доходят?
Отредактировано 29.08.2019 18:50 Shmj . Предыдущая версия . Еще …
Отредактировано 29.08.2019 18:31 Shmj . Предыдущая версия .
Re: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Aquilaware  
Дата: 29.08.19 18:45
Оценка: -1
Здравствуйте, Shmj, Вы писали:

S>Как до него вообще доходят?


Haskell это один из представителей ML языков.

Доходят просто — в попытке расширить познание устройства вселенной и достичь большего совершенства в софтостроении.

И это дает свои плоды. Познакомившись с Haskell/OCaml/F# один раз, вы уже не будете писать на С/C++/Java/C#/JavaScript как прежде. Никогда. Качество и скорость вашей работы возрастет в разы, а плотность багов на единицу кода уменьшится в 5 раз.
Re: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Слава  
Дата: 29.08.19 18:46
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Как до него вообще доходят?


Ты, Шимжя, хоть бы научился правильно писать название языка.
Re[2]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Эйнсток Файр Мухосранск Странный реагент
Дата: 29.08.19 19:12
Оценка:
A> JavaScript
A> плотность багов на единицу кода уменьшится в 5 раз

Не может быть.
Re[2]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 29.08.19 19:20
Оценка:
Здравствуйте, Aquilaware, Вы писали:

A>И это дает свои плоды. Познакомившись с Haskell/OCaml/F# один раз, вы уже не будете писать на С/C++/Java/C#/JavaScript как прежде. Никогда. Качество и скорость вашей работы возрастет в разы, а плотность багов на единицу кода уменьшится в 5 раз.


А пример такого кода могли бы привести?
Re: Реальные проекты на экзотике (Haskell и пр.) - как?
От: placement_new  
Дата: 29.08.19 20:40
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Курсов по нему тоже нет — курсы есть на популярные технологии.


S>Как до него вообще доходят?


В Станфорде, например, есть курс функционального программирования с Haskell.
Re[2]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: nekocoder США  
Дата: 29.08.19 21:21
Оценка: +9 :))) :))) :))) :))) :))) :))
Здравствуйте, Aquilaware, Вы писали:

A>Доходят просто — в попытке расширить познание устройства вселенной и достичь большего совершенства в софтостроении.


A>И это дает свои плоды. Познакомившись с Haskell/OCaml/F# один раз, вы уже не будете писать на С/C++/Java/C#/JavaScript как прежде. Никогда. Качество и скорость вашей работы возрастет в разы, а плотность багов на единицу кода уменьшится в 5 раз.


Познакомившись с Haskell/OCaml/F#, вы перестанете писать код. Вместо этого вы будете писать посты в бложек о новом способе вычисления чисел фибоначи и проповедовать функциональное учение на форумах.
Re: Реальные проекты на экзотике (Haskell и пр.) - как?
От: nekocoder США  
Дата: 29.08.19 21:23
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Вот, некоторые люди на работе пишут на Haskell. Как они до этого доходят?


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


Единственный проект на хаскеле, который я знаю (кроме самого компилятора хаскеля) — это оконный менеджер XMonad. Но им вроде никто не пользуется.

На Ocaml пишут в Jane Street.
Re[2]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 29.08.19 21:44
Оценка:
Здравствуйте, nekocoder, Вы писали:

N>Единственный проект на хаскеле, который я знаю (кроме самого компилятора хаскеля) — это оконный менеджер XMonad. Но им вроде никто не пользуется.

N>На Ocaml пишут в Jane Street.

Scala можно назвать полноценным функциональным языком? Там монады тоже используются.
Re: Реальные проекты на экзотике (Haskell и пр.) - как?
От: alzt  
Дата: 30.08.19 06:37
Оценка:
Здравствуйте, Shmj, Вы писали:

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


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

S>Где вообще можно научиться Haskell? Система образования чаще всего придерживается классики (C, C++, Java и на крайняк C#). Ну да, экзотике могут посвятить несколько часов — только чтобы глаза круглыми сделали.


Программистов, которым для освоения языка надо, чтобы какой-нибудь профессор в ВУЗе им прочитал курс, надо сразу в биореактор. Не место таким в профессии. Языкам у нас, да думаю не только у нас, учат посредственно. И в большинстве случаев язык вообще не важен, нужны другие знания (хорошее понимание базовых алгоритмов, устройства железа, умения организовывать код и др.).
Re[2]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 30.08.19 07:03
Оценка: -2 :))
Здравствуйте, alzt, Вы писали:

A>Программистов, которым для освоения языка надо, чтобы какой-нибудь профессор в ВУЗе им прочитал курс, надо сразу в биореактор. Не место таким в профессии. Языкам у нас, да думаю не только у нас, учат посредственно. И в большинстве случаев язык вообще не важен, нужны другие знания (хорошее понимание базовых алгоритмов, устройства железа, умения организовывать код и др.).


Учить язык нужно за деньги — т.е. когда тебе за это платят — иначе мотивации никакой не будет. Т.е. начинать с Junior-а.

Если уже одну платформу освоил, то на освоение второй (родственной) уйдет 2-3 месяца. Т.е. эти 2-3 месяца нужно устроиться на позицию с меньшей оплатой и предупредить что у тебя нет опыта.

Но кто будет платить за то, что ты будешь учить Haskell ?
Re: Реальные проекты на экзотике (Haskell и пр.) - как?
От: Kswapd Россия  
Дата: 30.08.19 08:21
Оценка:
S>Вот, некоторые люди на работе пишут на Haskell. Как они до этого доходят?

Ищут на агрегаторах вакансий по ключевому слову "Haskell". И находят.
Re[3]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: Kswapd Россия  
Дата: 30.08.19 08:30
Оценка:
S>Но кто будет платить за то, что ты будешь учить Haskell ?

Ну, сколько-то надо изучить в свободное время. В резюме немного приврать и поехали. А то тебе уж совсем тепличных условий хочется.
Re: Реальные проекты на экзотике (Haskell и пр.) - как?
От: 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ൒  
Дата: 30.08.19 08:59
Оценка:
RabbitMQ — Erlang
https://en.wikipedia.org/wiki/RabbitMQ
Re[3]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Aquilaware  
Дата: 30.08.19 10:19
Оценка: +1 -3 :)
Здравствуйте, Shmj, Вы писали:

S>А пример такого кода могли бы привести?


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

Python и C# — два хороших языка. Но что их отличает — Python имеет динамическую типизацию, и следовательно наименьщую строгость компилятора. Поэтому значительная часть багов Python программы проявляется не в процессе компиляции, а во время выполнения. То есть:

Python — низкая строгость компилятора; большинство дефектов (90%) проявляется во время выполнения скомпилированной программы
C# — средняя строгость компилятора; много дефектов (50%) выявляется еще на этапе компиляции.

Теперь перейдем к ML языкам, напрмер к F# (является братом-близнецом OCaml и Haskell). F# rомпилятор обадает высокой строгостью. Поэтому 90% дефектов выявляется еще на этапе компиляции. Но уж если программа скопмилировалась, вероятность проявления дефектов во время выполнения очень низкая (всего 10%, в то время как у C# 50%). Отсюда и получается эта цифра: "багов меньше в 5 раз".
Re[3]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Aquilaware  
Дата: 30.08.19 10:21
Оценка:
Здравствуйте, nekocoder, Вы писали:

N>Познакомившись с Haskell/OCaml/F#, вы перестанете писать код. Вместо этого вы будете писать посты в бложек о новом способе вычисления чисел фибоначи и проповедовать функциональное учение на форумах.


Юмор юмором, но это подобно позиции необразованного человека, который заявлял бы что: "познакомившись с алгеброй, вы забудете таблицу умножения".
Re[3]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: dsorokin Россия  
Дата: 30.08.19 10:39
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Учить язык нужно за деньги — т.е. когда тебе за это платят — иначе мотивации никакой не будет. Т.е. начинать с Junior-а.


Сильно зависит от типа личности, а мы все разные. По-моему, то, что ты описал, в одной забавной классификации называется "линейным программистом".

Как пример, Haskell применяют в компании Facebook для фильтрации сообщений, т.е. принятия решений, что можно вводить в базу сообщений, а что нельзя. Есть прослойки на С++, но основные решения принимает код на Haskell. https://www.youtube.com/watch?v=mlTO510zO78

Это что, получается, гнать менеджеров из компании Facebook?!
Re[4]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: nekocoder США  
Дата: 30.08.19 13:16
Оценка:
Здравствуйте, Aquilaware, Вы писали:

N>>Познакомившись с Haskell/OCaml/F#, вы перестанете писать код. Вместо этого вы будете писать посты в бложек о новом способе вычисления чисел фибоначи и проповедовать функциональное учение на форумах.


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


Это наблюдение необразованного человека. Которое подтверждается отсутствием проектов на всех этих суперязыках.
Re[2]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: Zhendos  
Дата: 30.08.19 16:07
Оценка:
Здравствуйте, nekocoder, Вы писали:

N>Здравствуйте, Shmj, Вы писали:


S>>Вот, некоторые люди на работе пишут на Haskell. Как они до этого доходят?


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


N>Единственный проект на хаскеле, который я знаю (кроме самого компилятора хаскеля) — это оконный менеджер XMonad. Но им вроде никто не пользуется.


В касперском насколько я знаю пишут на Haskell, генерирует С код для какого-то проекта.
Re[2]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: DenisCh Россия  
Дата: 30.08.19 16:25
Оценка:
Здравствуйте, Aquilaware, Вы писали:

A> И это дает свои плоды. Познакомившись с Haskell/OCaml/F# один раз, вы уже не будете писать на С/C++/Java/C#/JavaScript как прежде. Никогда. Качество и скорость вашей работы возрастет в разы, а плотность багов на единицу кода уменьшится в 5 раз.


А ещё трава зеленее станет, и пиписька крепче стоять будет.
Слышали мы такие лозунги неоднократно.
[url=https://github.com/abbat/avalon1.0.449[/url]
Re: Реальные проекты на экзотике (Haskell и пр.) - как?
От: Zhendos  
Дата: 30.08.19 16:32
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Вот, некоторые люди на работе пишут на Haskell. Как они до этого доходят?


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


S>Где вообще можно научиться Haskell? Система образования чаще всего придерживается классики (C, C++, Java и на крайняк C#). Ну да, экзотике могут посвятить несколько часов — только чтобы глаза круглыми сделали.


S>Курсов по нему тоже нет — курсы есть на популярные технологии.


S>Как до него вообще доходят?



1. А какая разница чему учит или не учит система образования? Куча народа на территории ex СССР
стала программистами, хотя и не учились на них. Они естественно изучали язык с помощью книг,
статей, блогов и т.д.
По экзотическим языкам типа Haskell конечно есть книги, стать и т.д.

2. Экзотика относительна. Вот например:
https://www.theregister.co.uk/2019/08/16/dropbox_gives_up_on_sharing_c_code_between_ios_and_android/
Dropbox пришлось переписать кучу кода потому что не нашла C++ программистов.
Поэтому вполне возможно, что экзотический язык "в среднем по палате" совсем не экзотический в какой-то
предметной области. Например Rust довольно экзотический на сегодня, но довольно часто финансовые стартапы со словом
"blockchain" в описании ищут разработчиков на Rust или например Fortran, довольно экозотический язык на данный момент,
но в некоторых областях умение его понимать необходимо, и думаю еще долго так будет.
Re[3]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: alzt  
Дата: 30.08.19 20:18
Оценка: 6 (1) +2
Здравствуйте, Shmj, Вы писали:

A>>Программистов, которым для освоения языка надо, чтобы какой-нибудь профессор в ВУЗе им прочитал курс, надо сразу в биореактор. Не место таким в профессии. Языкам у нас, да думаю не только у нас, учат посредственно. И в большинстве случаев язык вообще не важен, нужны другие знания (хорошее понимание базовых алгоритмов, устройства железа, умения организовывать код и др.).


S>Учить язык нужно за деньги — т.е. когда тебе за это платят — иначе мотивации никакой не будет. Т.е. начинать с Junior-а.


Не знаю ни одного человека, кто бы "выучил язык за деньги". Большинство учило, т.к. им было интересно программировать. Желающих учить/программировать на функциональных языках много. Им не нужно оплачивать обучение, они уже сами всё выучили. Мотивация у всех внутренняя — это интересно.

Может какие-то работодатели платят за курсы по языку, но я очень сомневаюсь, что это того стоит. Я с таким никогда не сталкивался. И нормальные программисты, когда переходили на другой проект с другим для себя языком, через некоторое время хорошо САМИ изучали новый язык.
Re[4]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 31.08.19 00:56
Оценка: -1
Здравствуйте, alzt, Вы писали:

A>Может какие-то работодатели платят за курсы по языку, но я очень сомневаюсь, что это того стоит. Я с таким никогда не сталкивался. И нормальные программисты, когда переходили на другой проект с другим для себя языком, через некоторое время хорошо САМИ изучали новый язык.


Зачем курсы? Просто начинают работать и получают зарплату за то что учат язык (по факту).
Отредактировано 31.08.2019 0:56 Shmj . Предыдущая версия .
Re[2]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: AleksandrN Россия  
Дата: 31.08.19 11:01
Оценка:
Здравствуйте, Aquilaware, Вы писали:

A>И это дает свои плоды. Познакомившись с Haskell/OCaml/F# один раз, вы уже не будете писать на С/C++/Java/C#/JavaScript как прежде. Никогда. Качество и скорость вашей работы возрастет в разы, а плотность багов на единицу кода уменьшится в 5 раз.


Если серебрянная пуля уже есть, почему она мало используется?
Re[3]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Poopy Joe Бельгия  
Дата: 31.08.19 16:00
Оценка: +1
Здравствуйте, AleksandrN, Вы писали:

AN>Здравствуйте, Aquilaware, Вы писали:


A>>И это дает свои плоды. Познакомившись с Haskell/OCaml/F# один раз, вы уже не будете писать на С/C++/Java/C#/JavaScript как прежде. Никогда. Качество и скорость вашей работы возрастет в разы, а плотность багов на единицу кода уменьшится в 5 раз.


AN>Если серебрянная пуля уже есть, почему она мало используется?


Потому что люди консервативны и очень не любят менять привычки. Особенно, если новое требует поставить под сомнение весь предыдущий опыт.
Re[4]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 31.08.19 22:32
Оценка:
Здравствуйте, Poopy Joe, Вы писали:

PJ>Потому что люди консервативны и очень не любят менять привычки. Особенно, если новое требует поставить под сомнение весь предыдущий опыт.


Вы спешите с выводами.

Технология должна пройти проверку практикой. Да, есть случаи где Haskell крут — это те же парсеры всевозможные. Но жизнь не состоит только лишь из парсеров — это лишь незначительный процент.
Отредактировано 01.09.2019 2:04 Shmj . Предыдущая версия .
Re[3]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: 0xCAFEDEAD  
Дата: 01.09.19 02:52
Оценка:
Здравствуйте, AleksandrN, Вы писали:

AN>Здравствуйте, Aquilaware, Вы писали:


A>>И это дает свои плоды. Познакомившись с Haskell/OCaml/F# один раз, вы уже не будете писать на С/C++/Java/C#/JavaScript как прежде. Никогда. Качество и скорость вашей работы возрастет в разы, а плотность багов на единицу кода уменьшится в 5 раз.


AN>Если серебрянная пуля уже есть, почему она мало используется?


Да как раз именно сейчас и используется по полной. Просто немного другим путем. Haskell/OCaml — академические проекты, скорее всего ими и останутся. Но именно они и им подобные являются и вдохновителями, и донорами идей для новых фич в мейнстримовых языках. Во многих новых языках уже есть функциональные типы, паттерн матчинг, и тд. Эти же фичи активно внедряются в существующие языки по мере сил и возможностей.

И народ уже считает лямбду ругательством. Всего лишь 20-30 лет поскитались и вот в мейнстриме!
Re[4]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: AlexGin Беларусь  
Дата: 01.09.19 05:13
Оценка:
Здравствуйте, уважаемый alzt, Вы писали:

A>Не знаю ни одного человека, кто бы "выучил язык за деньги". Большинство учило, т.к. им было интересно программировать.

+100500
Да, именно потому, что интересно!
А если интересно, то будт тебе работа в радость!
Тогда-то и за оплатой твоего труда — дело не станет!

A>Желающих учить/программировать на функциональных языках много. Им не нужно оплачивать обучение, они уже сами всё выучили. Мотивация у всех внутренняя — это интересно.


Тут надо понимать, что есть люди, которые живут функциональщиной.
И их не смущает, что они далеки от майнстрима.

A>Может какие-то работодатели платят за курсы по языку, но я очень сомневаюсь, что это того стоит. Я с таким никогда не сталкивался. И нормальные программисты, когда переходили на другой проект с другим для себя языком, через некоторое время хорошо САМИ изучали новый язык.

+100500
Да, работодатели — обычно ожидают готового специалиста. Их можно (и нужно) понять. За более чем 15 лет работы в беларусском IT,
я ни разу не встречал работодателя, который оплатит человеку курсы по программированию. Если человеку интересно, то он учиться сам,
на рабочем месте.
В конце-концов именно обучение на рабочем месте — это тот фактор, что позволяет специалисту профессионально, а нередко и карьероно, расти.
Re[2]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: AlexGin Беларусь  
Дата: 01.09.19 05:25
Оценка:
Здравствуйте, уважаемый Zhendos, Вы писали:

Z> ... или например Fortran, довольно экозотический язык на данный момент,

Z> но в некоторых областях умение его понимать необходимо, и думаю еще долго так будет.

FORTRAN — древний язык.
Если его просто понимать, то ИМХО любой адекватный девелопер современного стека (C++, C# или Java, JS) его поймёт.
Другое дело, что обычно в старых проектах на FORTRAN, требовались хорошие математические познания, что имеется всё-таки весьма редко
Re[5]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Poopy Joe Бельгия  
Дата: 01.09.19 06:01
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Poopy Joe, Вы писали:


PJ>>Потому что люди консервативны и очень не любят менять привычки. Особенно, если новое требует поставить под сомнение весь предыдущий опыт.


S>Вы спешите с выводами.


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

S>Да, есть случаи где Haskell крут — это те же парсеры всевозможные. Но жизнь не состоит только лишь из парсеров — это лишь незначительный процент.


Ты начал тему с ошибочного написания названия языка, но уже через два дня даешь экспертную оценку где хаскель крут, а где не очень.
Вот это вот все вообще зачем, кроме как для оправданий? Ведь никто же на него силком не тянет.
Re: Реальные проекты на экзотике (Haskell и пр.) - как?
От: namespace  
Дата: 01.09.19 11:38
Оценка:
S>Какая мотивация в владельца бизнеса применять столь экзотический язык,
А он ни сном ни духом, ему главное — чтобы работало и пользователи не жаловались. Это уже потом, когда оценивают затраты на поддержку...

В кровавом ынтерпрайзе все еще хуже. Находится деятельный менеджер, который успешно впаривает высшему руководству полуфабрикаты наподобие 1С, но заточенные под конкретный бизнес. Затем обучают людей птичьему языку той системы.
Система растет, вокруг нее наворачивают обходные костыли, отлавливают все ее баги. Вокруг этой системы вырастает целый зоопарк.
А через >20 лет вдруг оказыается, что некому писать на ней. Ищут долго и упорно, не один год. Находят в Москве одного(!) опытного, желающего ее поддерживать, но тот просит 450тр за работу на полставки тк здоровье не позволяет больше.
Re[6]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 01.09.19 17:32
Оценка: -1 :)
Здравствуйте, Poopy Joe, Вы писали:

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

PJ>Вот это вот все вообще зачем, кроме как для оправданий? Ведь никто же на него силком не тянет.

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

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

Даже самое простое — для объявления функции нужно минимум синтаксиса. Потому что язык заточен не под данные а под функции. Но в реальной жизни все крутится вокруг данных.
Re[7]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Poopy Joe Бельгия  
Дата: 01.09.19 17:47
Оценка: +2
Здравствуйте, Shmj, Вы писали:


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




S>Даже самое простое — для объявления функции нужно минимум синтаксиса. Потому что язык заточен не под данные а под функции. Но в реальной жизни все крутится вокруг данных.



Вот про такое я и говорил.
Re[8]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 01.09.19 17:52
Оценка:
Здравствуйте, Poopy Joe, Вы писали:

PJ>Вот про такое я и говорил.


А сам то хоть одну строчку на Haskell написал?
Re[9]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Poopy Joe Бельгия  
Дата: 01.09.19 18:06
Оценка: +1
Здравствуйте, Shmj, Вы писали:

S>А сам то хоть одну строчку на Haskell написал?


Написал, не переживай за меня. Дело не в том, сколько ты строчек написал, есть люди которые ни строчки не писали на хаскеле или других фя, но понимают концепцию и могут использовать идеи в императивных языках, хоть и выходит многословно и коряво. Дело в том, что ты в принципе не понимаешь о чем говоришь, и у тебя нет ни малейшего интереса, иначе бы ты не озвучивал глупости выше. Достаточно было бы пары вводных статей или видео, чтобы это понять. Зачем этот топик трогать вообще? Вы себя пытаетесь уговорить что ли, что реальных проектов нет? А зачем?
Re[7]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 01.09.19 18:07
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Даже самое простое — для объявления функции нужно минимум синтаксиса. Потому что язык заточен не под данные а под функции. Но в реальной жизни все крутится вокруг данных.


Т.е. до главы об объявлении данных не дошел. Но выводы сделал.
Re[10]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 01.09.19 22:48
Оценка:
Здравствуйте, Poopy Joe, Вы писали:

PJ>Дело в том, что ты в принципе не понимаешь о чем говоришь, и у тебя нет ни малейшего интереса, иначе бы ты не озвучивал глупости выше.


В C# уже немало элементов функциональных, так что сказать что совсем не понимаю — я бы не сказал.

Задай вопрос — посмотрим понимаю или нет.
Re[11]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Poopy Joe Бельгия  
Дата: 02.09.19 09:24
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Poopy Joe, Вы писали:


PJ>>Дело в том, что ты в принципе не понимаешь о чем говоришь, и у тебя нет ни малейшего интереса, иначе бы ты не озвучивал глупости выше.


S>В C# уже немало элементов функциональных, так что сказать что совсем не понимаю — я бы не сказал.


Сами по себе элементы мало что дают, и уж точно не дают понимания принципов, увы.

S>Задай вопрос — посмотрим понимаю или нет.


Я не собираюсь никому устраивать экзаменов. Выше ты уже дал достаточный ответ.
Я могу предложить следующий критерий, без претензий на его полноту или формальную корректность: если монады кажутся помехой, костылем к языку, чтобы "решать проблемы которых нет в функциональных языках (с)" или "способ писать императивно на хаскеле" то ты точно не понимаешь базовых принципов.
Re[12]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 02.09.19 12:25
Оценка:
Здравствуйте, Poopy Joe, Вы писали:

PJ>Сами по себе элементы мало что дают, и уж точно не дают понимания принципов, увы.


А как узнать понял принципы или нет?

PJ>Я не собираюсь никому устраивать экзаменов. Выше ты уже дал достаточный ответ.


Зачем экзамен? Обычно достаточно задать пару наводящих вопросов. Но это хотя бы будет конкретика и толчек для человека, который позволит ему понять действительно ли есть проблема.

Пока похоже что ты просто хочешь доминировать примативным путем.

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


Если хочешь понять что такое монады — читай пост IT http://rsdn.org/forum/flame.comp/7530546.1
Автор: IT
Дата: 30.08.19


Это всего лишь способ избавиться от "служебного кода".
Re[13]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Poopy Joe Бельгия  
Дата: 02.09.19 13:20
Оценка:
Здравствуйте, Shmj, Вы писали:

S>А как узнать понял принципы или нет?


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

S>Зачем экзамен? Обычно достаточно задать пару наводящих вопросов. Но это хотя бы будет конкретика и толчек для человека, который позволит ему понять действительно ли есть проблема.

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

S>Пока похоже что ты просто хочешь доминировать примативным путем.

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

S>Если хочешь понять что такое монады — читай пост IT http://rsdn.org/forum/flame.comp/7530546.1
Автор: IT
Дата: 30.08.19

Это цитата первой строки из википедии. Так себе объяснение, честно говоря.
Вот это гораздо лучше http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html
Но я говорил не том, что такое монада, а об отношении к ним. Потому что если не понял, то вот это все будет выглядеть как "а нафига вот это всё вообще надо?".

S>Это всего лишь способ избавиться от "служебного кода".

И чем это фраза отличается от дженерики это лишь способ избавиться от служебного кода и интерфейсы это лишь способ избавиться от служебного кода итд?
Re[13]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 02.09.19 13:28
Оценка: 15 (1) +1
Здравствуйте, Shmj, Вы писали:

S>Если хочешь понять что такое монады — читай пост IT http://rsdn.org/forum/flame.comp/7530546.1
Автор: IT
Дата: 30.08.19


S>Это всего лишь способ избавиться от "служебного кода".


При всем уважении к IT, формулировка монады как способ неверна. Монада — это тройка (тип, + пара функций), удовлетворяющая определенным законам. Одним словом — паттерн. Конечно же монаду нужно отделять от синтаксиса, построенном для того, что бы укорачивать код, используя паттерн монады. Синтаксиса может не быть, но монада будет иметь место. Такое вот опровержение тезису "монада = способ избавиться".
Re[14]: монады
От: Sharov Россия  
Дата: 02.09.19 14:35
Оценка:
Здравствуйте, samius, Вы писали:

S>При всем уважении к IT, формулировка монады как способ неверна. Монада — это тройка (тип, + пара функций), удовлетворяющая определенным законам. Одним словом — паттерн. Конечно же монаду нужно отделять от синтаксиса, построенном для того, что бы укорачивать код, используя паттерн монады. Синтаксиса может не быть, но монада будет иметь место. Такое вот опровержение тезису "монада = способ избавиться".


Именно паттерн. Я когда увидел это объяснение, мне вообще показалось, что это сниппет. Но потом понял, что оченно высокоуровневый сниппет, т.е. именно паттерн.
Я особо над монадами никогда не заморачивался. Лет 10 назад пытался прочеть на этот счет работу Евгения Кирпичева, понял что ничего не понял. Потом осознал, что вероятно и
автор не очень понял (ему было на тот момент лет 20), так и оставил это дело.

Мне всегда казалось, что монады это способ обплясать отсутвивет состоянии в мире фя. Но поскольку суть вычисления в изменении состояния\side effect'ов, вот и ввели монады. Т.е. костыль.
Кодом людям нужно помогать!
Re[14]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 02.09.19 16:06
Оценка:
Здравствуйте, samius, Вы писали:

S>При всем уважении к IT, формулировка монады как способ неверна.


Там он развернуто написал — прочитай. Суть в этом, а уже детали почитай.
Re[14]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 02.09.19 16:10
Оценка:
Здравствуйте, Poopy Joe, Вы писали:

S>>Зачем экзамен? Обычно достаточно задать пару наводящих вопросов. Но это хотя бы будет конкретика и толчек для человека, который позволит ему понять действительно ли есть проблема.

PJ>Так я тебе и задал. Вместо ответа на него, ты начала разбираться кто должен быть альфой. С тобой все хорошо?

Ты не задал а отказался задавать — мол не хочешь экзамен устраивать.

S>>Если хочешь понять что такое монады — читай пост IT http://rsdn.org/forum/flame.comp/7530546.1
Автор: IT
Дата: 30.08.19

PJ>Это цитата первой строки из википедии. Так себе объяснение, честно говоря.

Там и примеры есть.

PJ>Вот это гораздо лучше http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html

PJ>Но я говорил не том, что такое монада, а об отношении к ним. Потому что если не понял, то вот это все будет выглядеть как "а нафига вот это всё вообще надо?".

Нет, ты привел фигню. Понять всегда проще на реальных примерах, чем на фигне из картинок. Тот же ассиметричный алгоритм шифрования RSA до конца понял, лишь когда реализовал свою версию, начал читать про малую теорему Ферма. А на картинках — фигня получается.

Зачем нужен этот поттерн — понятно. Но так же понятна не столько широкая область его применения и то, что на C# популярные области применения этого паттерна можно захардкодить. Потенциально на haskell ты можешь расширить и добавить простым образом новые монады — но на практике не так уж много где этот паттерн нужен.

S>>Это всего лишь способ избавиться от "служебного кода".

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

А тут смотри примеры IT — там все написано.
Re[15]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 02.09.19 16:39
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, samius, Вы писали:


S>>При всем уважении к IT, формулировка монады как способ неверна.


S>Там он развернуто написал — прочитай. Суть в этом, а уже детали почитай.


Читал перед тем, как отвечал. Мой аргумент выше и он не изменится от дальнейшего чтения деталей.
Re[15]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 02.09.19 16:46
Оценка: 5 (1)
Здравствуйте, Shmj, Вы писали:

S>Зачем нужен этот поттерн — понятно. Но так же понятна не столько широкая область его применения и то, что на C# популярные области применения этого паттерна можно захардкодить. Потенциально на haskell ты можешь расширить и добавить простым образом новые монады — но на практике не так уж много где этот паттерн нужен.


Так речь ведь не о том, что это нужно, а о том, что это удобно. Собственно, то, что делает компилятор, когда заменяет короткий монадный синтаксис на функции — он доказывает то, что монада не нужна. Так же, как и цикл for, который заменяется на оператор перехода и набор условий.
Re[15]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Poopy Joe Бельгия  
Дата: 02.09.19 16:53
Оценка: -1
Здравствуйте, Shmj, Вы писали:

S>Ты не задал а отказался задавать — мол не хочешь экзамен устраивать.

Я отказался в том смысле, что меня ответ не интересует, мне уже все понятно. Но что бы понять "если ли проблемы" как ты выразился, ты можешь сам себе ответить.

S>Нет, ты привел фигню.

Ты это понял прочитав главу из книги и запустив пару примеров? Шариковщина, прости господи.

S>Понять всегда проще на реальных примерах, чем на фигне из картинок.

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

S>Зачем нужен этот поттерн — понятно. Но так же понятна не столько широкая область его применения и то, что на C# популярные области применения этого паттерна можно захардкодить. Потенциально на haskell ты можешь расширить и добавить простым образом новые монады — но на практике не так уж много где этот паттерн нужен.

Ну это фактически ответ на вопрос, который я тебе и задал — фигня не нужная, костыль. Т.е. основных принципов ты не понял (что совершенно нормально, кстати, для большинства людей). Дальше делай с этим знанием, что хочешь. Можешь дальше копать, можешь забить, это не мое дело.
Re[16]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 02.09.19 17:08
Оценка:
Здравствуйте, Poopy Joe, Вы писали:

PJ>фигня не нужная, костыль.


Нет, не костыль а более высокий порядок абстрагирования. В теории это упрощает целый класс задач, но на практике таких задач не так уж много и в том же C#, как заметил IT, уже захардкожено решение для большинства из них.
Re[17]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 02.09.19 17:50
Оценка: 15 (2)
Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Poopy Joe, Вы писали:


PJ>>фигня не нужная, костыль.


S>Нет, не костыль а более высокий порядок абстрагирования. В теории это упрощает целый класс задач, но на практике таких задач не так уж много и в том же C#, как заметил IT, уже захардкожено решение для большинства из них.


Здесь надо все-таки разобраться, что именно в C# уже было захардкожено, а что именно появилось с помощью "оглядки" на монады.
Итак, до монад было
1) foreach. Честно, к монадам он отношения не имеет вовсе, но имеет к тому, что было до Linq query comprehension syntax, а так же foreach — именно то, чем "едят" построенное с помощью query comprehension или подобного.
2) Nullable<T>, где T — структуры. Очень кривое нечто, что в принципе позволяет на высоком уровне работать с потенциально отсутствующими значениями. А именно, сравнивать, выполнять некоторые арифметические операции. Эта поделка очень сильно не дотягивает до аналога MayBe<T>. Хотя бы уже тем, что ограничена лишь структурами.
3) Task<T>. Фактически было до Linq, но практически одновременно с ним. Task<T> по удобству до монад очень сильно не дотягивает. Я пытался их вкрутить в реальный проект. До выпуска await-ов это было больно. Но await появился уже позже Linq.

Все, больше в C# ничего такого монадного не было. Даже монада List до Linq отсутствовала в языке. Кроме foreach вообще ничего к ней не относилось.

Когда IT писал что "для монады List в C# уже все есть", он подразумевал то, что это уже есть в Linq-е.

С Linq C# получил некое подобие монадного синтаксиса. Почему подобие? Потому как bind/SelectMany работает с другой сигнатурой, чем это принято в функциональных языка. Связывание производится по-другому принципу. Похоже, но наизнанку по отношению к другим функциональным языкам. Обычно bind-ы кладутся один в другой через лямбду, т.е. вложенно. Внешний принимает лямбду, вызывающую вложенный bind и так далее. Но в C# SelectMany применяется к результату предыдущего SelectMany, последовательно.
Так и не знаю причины, почему это реализовано именно так.

В итоге — монады мы имеем, но монадный синтаксис построен на аналоге, не на монаде. Если говорить буквально, то в C# монады языком не поддержаны в чистом виде.

Итак, до Linq ничего годного, похожего на монады в C# не было. С Linq появилось что-то похожее. Да, монаду List можно теперь использовать не напрягаясь, но это результат внесения псевдомонад в язык вместе с Linq-ом, а не результат хардкожения "большинства" монад до появления Linq.
Re[5]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: alzt  
Дата: 02.09.19 18:57
Оценка:
Здравствуйте, Shmj, Вы писали:

A>>Может какие-то работодатели платят за курсы по языку, но я очень сомневаюсь, что это того стоит. Я с таким никогда не сталкивался. И нормальные программисты, когда переходили на другой проект с другим для себя языком, через некоторое время хорошо САМИ изучали новый язык.


S>Зачем курсы? Просто начинают работать и получают зарплату за то что учат язык (по факту).


Для работодателя это глупо. Наберёт всякий шлак, которому не интересно программировать, но они слышали, что хорошо платят.
Это не вопрос денег. Всем моим толковым квалифицированным коллегам нравится программировать. Они сами готовы платить за курсы, они готовы на понижение зарплаты, если можно поменять язык на их любимый. Но тут опять же работодатель, который не хочет увеличивать риски и предпочитает джаву.
Ещё раз — люди готовы сами снизить себе зарплату, чтобы писать проект на Хаскеле (не у всех это Хаскель). И именно работодатель на это не согласен.
Re[6]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: Poopy Joe Бельгия  
Дата: 02.09.19 19:52
Оценка:
Здравствуйте, alzt, Вы писали:

A>Ещё раз — люди готовы сами снизить себе зарплату, чтобы писать проект на Хаскеле (не у всех это Хаскель).

Кто эти странные люди?
https://insights.stackoverflow.com/survey/2018/#technology-_-what-languages-are-associated-with-the-highest-salaries-worldwide

Работодатели не любят менять технологии, потому что они слабо в них разбираются и, часто, есть обросший мхом местный авторитет, который рассказывает, что в и c# все есть, а чего нет, того и не надо. Но если просто взять и показать разницу в эффективности. Для чего конечно приходится делать дополнительную работу, это верно. То работодатель разумный к команде прислушивается и команду поддерживает, да и курсы оплачивают. Хотя, признаться, чаще самому приходится делать внутреннее обучение. А если он упертый, занимается микро-менеджментом, то зачем там сидеть и фигней страдать?
Отредактировано 02.09.2019 20:03 Poopy Joe . Предыдущая версия .
Re[18]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Shmj Ниоткуда  
Дата: 02.09.19 23:35
Оценка:
Здравствуйте, samius, Вы писали:

S>2) Nullable<T>, где T — структуры. Очень кривое нечто, что в принципе позволяет на высоком уровне работать с потенциально отсутствующими значениями. А именно, сравнивать, выполнять некоторые арифметические операции. Эта поделка очень сильно не дотягивает до аналога MayBe<T>. Хотя бы уже тем, что ограничена лишь структурами.


Есть оператор ?. Наверное не сталкивались...

Это я и называю захардкожено.

S>но это результат внесения псевдомонад в язык вместе с Linq-ом, а не результат хардкожения "большинства" монад до появления Linq.


А кто говорил про "до появления Linq"?
Отредактировано 02.09.2019 23:39 Shmj . Предыдущая версия .
Re[19]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 03.09.19 02:48
Оценка: 5 (1) +1
Здравствуйте, Shmj, Вы писали:

S>Есть оператор ?. Наверное не сталкивались...

Сталкивался, конечно. Забыл о нем. Не так много приходилось пользоваться, не во всех проектах версия языка позволяет его задействовать.
Но опять-таки, похоже на монаду внешне. Но лишь похоже в некоторых обстоятельствах. Когда встает задача типа "заменить в строке a все вложения b если a и b не null", как становится понятно что одним оператором ?. и штатным методом Replace не обойтись.

S>Это я и называю захардкожено.

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

S>>но это результат внесения псевдомонад в язык вместе с Linq-ом, а не результат хардкожения "большинства" монад до появления Linq.


S>А кто говорил про "до появления Linq"?

Никто в теме не говорил. Но я работаю с C# начиная с первой беты первой версии и вижу изменения в языке, сделанные благодаря функциональщине, функциональщикам и языку Haskell в частности. Отдельное спасибо Эрику Мейеру за Linq.
Потому и призываю в контексте исторического процесса оценить, чем бы был C#, если бы не влияние Haskell и монад. Что бы там было захардкожено, а что — нет.

Т.е. возвращаясь к фразе

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

осмелюсь утверждать, что если бы не Haskell и монады, скорее всего, этих захардкоженных решений бы не было. Как минимум, не всех.
И конечно, жду, когда же MS захардкодит в C# парсеры. Особо не рассчитываю.
Re[7]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: alzt  
Дата: 03.09.19 06:00
Оценка:
Здравствуйте, Poopy Joe, Вы писали:

A>>Ещё раз — люди готовы сами снизить себе зарплату, чтобы писать проект на Хаскеле (не у всех это Хаскель).

PJ>Кто эти странные люди?
PJ>https://insights.stackoverflow.com/survey/2018/#technology-_-what-languages-are-associated-with-the-highest-salaries-worldwide

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

Не стоит забывать, что во многих областях наибольшие успехи (и как следствие деньги) будут у тех, кому интересно заниматься этим делом. Они программируют, т.к. любят, а не для того, чтобы заработать деньги. Т.е. в целом деньги мотиватор более слабый, чем интерес. Не знаю, может просто более квалифицированные и заинтересованные люди хотят программировать на Хаскеле, и естественно они получают больше среднего по больнице. Но их коллеги с такой же квалификацией на Java или JavaScript будут зарабатывать больше.

PJ>Работодатели не любят менять технологии, потому что они слабо в них разбираются и, часто, есть обросший мхом местный авторитет, который рассказывает, что в и c# все есть, а чего нет, того и не надо. Но если просто взять и показать разницу в эффективности. Для чего конечно приходится делать дополнительную работу, это верно. То работодатель разумный к команде прислушивается и команду поддерживает, да и курсы оплачивают.


Выбор языка это не микроменеджмент. Если проект будет жить более 3х лет, то язык очень сильно на всё влияет. Это и платформа и ограничения и зависимости, а кроме этого достпуные разработчики. С мейнстримом в целом рисков будет сильно меньше.
Re[2]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: pagid Россия  
Дата: 03.09.19 06:55
Оценка:
Здравствуйте, Aquilaware, Вы писали:

A>Качество и скорость вашей работы возрастет в разы, а плотность багов на единицу кода уменьшится в 5 раз.

А волосы станут мягкими и шелковистыми.
Re[8]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: Poopy Joe Бельгия  
Дата: 03.09.19 06:58
Оценка: +1
Здравствуйте, alzt, Вы писали:

A>Со статистикой всегда надо аккуратно обращаться. Вообще не очень верится, т.к. Хаскель чаще будут использовать в академической среде, где зарплаты в среднем ниже. Может я пропустил широкое внедрение Хаскеля в бизнесе.


С верой это к культам и религиям, я лишь привел сухие цифры. И да, на хаскеле зарплата ниже, чем на допустим, f#, который широко используется в банковской среде, где денег больше.

A>Не стоит забывать, что во многих областях наибольшие успехи (и как следствие деньги) будут у тех, кому интересно заниматься этим делом. Они программируют, т.к. любят, а не для того, чтобы заработать деньги. Т.е. в целом деньги мотиватор более слабый, чем интерес. Не знаю, может просто более квалифицированные и заинтересованные люди хотят программировать на Хаскеле, и естественно они получают больше среднего по больнице. Но их коллеги с такой же квалификацией на Java или JavaScript будут зарабатывать больше.


Я не понимаю почему то что нравится не должно еще и доход приносить? Какая тут связь вообще?

A>Выбор языка это не микроменеджмент. Если проект будет жить более 3х лет, то язык очень сильно на всё влияет. Это и платформа и ограничения и зависимости, а кроме этого достпуные разработчики. С мейнстримом в целом рисков будет сильно меньше..

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


Если это все не создает риски для бизнеса, то у нас явно разное понимание рисков.
Понятно, что в виртуальном мире rsdn все все сдают в срок и с высочайшим качеством, но вот лично мне приходится жить в реальном мире.
Re[18]: Об монады.
От: Sharov Россия  
Дата: 03.09.19 10:12
Оценка:
Здравствуйте, samius, Вы писали:

S>3) Task<T>. Фактически было до Linq, но практически одновременно с ним. Task<T> по удобству до монад очень сильно не дотягивает. Я пытался их вкрутить в реальный проект. До выпуска await-ов это было больно. Но await появился уже позже Linq.


Не было Task<T> до Linq, были только потоки. Таски появились уже в fw 4.0, а Linq в 3.5

S>Все, больше в C# ничего такого монадного не было. Даже монада List до Linq отсутствовала в языке. Кроме foreach вообще ничего к ней не относилось.


А почему рассмативается List, а не IEnumerable<T>?


S>С Linq C# получил некое подобие монадного синтаксиса. Почему подобие? Потому как bind/SelectMany работает с другой сигнатурой, чем это принято в функциональных языка. Связывание производится по-другому принципу. Похоже, но наизнанку по отношению к другим функциональным языкам. Обычно bind-ы кладутся один в другой через лямбду, т.е. вложенно. Внешний принимает лямбду, вызывающую вложенный bind и так далее. Но в C# SelectMany применяется к результату предыдущего SelectMany, последовательно.


А чем так примечателен SelectMany в контексте монад?

S>Так и не знаю причины, почему это реализовано именно так.


А как должно?
Кодом людям нужно помогать!
Re: Реальные проекты на экзотике (Haskell и пр.) - как?
От: EreTIk EreTIk's Box
Дата: 03.09.19 10:18
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Вот, некоторые люди на работе пишут на Haskell. Как они до этого доходят?


Нравится им на нем писать. Из первого что приходит в голову (так как сам пользуюсь) — BazQux

Is BazQux Reader re­ally writ­ten in Haskell and Ur/Web?
Yes. I love to use the best tools avail­able.

Re[19]: Об монады.
От: samius Япония http://sams-tricks.blogspot.com
Дата: 03.09.19 11:12
Оценка: 10 (1)
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, samius, Вы писали:


S>>3) Task<T>. Фактически было до Linq, но практически одновременно с ним. Task<T> по удобству до монад очень сильно не дотягивает. Я пытался их вкрутить в реальный проект. До выпуска await-ов это было больно. Но await появился уже позже Linq.


S>Не было Task<T> до Linq, были только потоки. Таски появились уже в fw 4.0, а Linq в 3.5

Верно.
И все-таки Task<T> не был интегрирован в Linq и без await использовать его в коде было тяжело.

S>>Все, больше в C# ничего такого монадного не было. Даже монада List до Linq отсутствовала в языке. Кроме foreach вообще ничего к ней не относилось.


S>А почему рассмативается List, а не IEnumerable<T>?

Да просто взял название монады из Haskell.
Сейчас с Linq-ом IEnumerable<T> выглядит монадой с точностью до реализации связывания. Но до Linq-а невзирая на foreach + yield, я бы не говорил о наличии монады IEnumerable<T> в языке. Руками, вероятно, можно было бы запилить ее. Но мы же не об этом все-таки.

S>>С Linq C# получил некое подобие монадного синтаксиса. Почему подобие? Потому как bind/SelectMany работает с другой сигнатурой, чем это принято в функциональных языка. Связывание производится по-другому принципу. Похоже, но наизнанку по отношению к другим функциональным языкам. Обычно bind-ы кладутся один в другой через лямбду, т.е. вложенно. Внешний принимает лямбду, вызывающую вложенный bind и так далее. Но в C# SelectMany применяется к результату предыдущего SelectMany, последовательно.


S>А чем так примечателен SelectMany в контексте монад?

диковинной для bind формой
class C<T>
{
    public C<V> SelectMany<U,V>(Func<T,C<U>> selector,
        Func<T,U,V> resultSelector);
}

return зашит в самом SelectMany, кроме этого у него два аргумента-функции.

S>>Так и не знаю причины, почему это реализовано именно так.


S>А как должно?

Я же написал выше. Связывание вычислений по нескольким контейнерам в Haskell, F#, Scala — вложенное. Есть внешний bind, в который передается функция, использующая следующий bind:
bind(...,x => bind(...))

Но в C# мы имеем:
a.SelectMany(...).SelectMany(...)
Re[20]: Об монады.
От: Sharov Россия  
Дата: 03.09.19 11:32
Оценка:
Здравствуйте, samius, Вы писали:

S>>Не было Task<T> до Linq, были только потоки. Таски появились уже в fw 4.0, а Linq в 3.5

S>Верно.
S>И все-таки Task<T> не был интегрирован в Linq и без await использовать его в коде было тяжело.

А в чем проблема вызвать Task.Wait() или Task.ContinueWhen()?

S>>А чем так примечателен SelectMany в контексте монад?

S>диковинной для bind формой
S>return зашит в самом SelectMany, кроме этого у него два аргумента-функции.

А почему именно две ф-ия аргумента важны? Почему просто Select не подходит. Я реально в этом(монадах) не понимаю ничего, вот и спрашиваю. Тут, вероятно, надо понять как bind работает...

S>>>Так и не знаю причины, почему это реализовано именно так.


S>Я же написал выше. Связывание вычислений по нескольким контейнерам в Haskell, F#, Scala — вложенное. Есть внешний bind, в который передается функция, использующая следующий bind:

S>
S>bind(...,x => bind(...))
S>

S>Но в C# мы имеем:
S>
S>a.SelectMany(...).SelectMany(...)
S>


Не очень помогло, ибо по-прежнему не пониаю сути bind...
Кодом людям нужно помогать!
Re[21]: Об монады.
От: samius Япония http://sams-tricks.blogspot.com
Дата: 03.09.19 13:47
Оценка: 7 (2)
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, samius, Вы писали:


S>>И все-таки Task<T> не был интегрирован в Linq и без await использовать его в коде было тяжело.


S>А в чем проблема вызвать Task.Wait() или Task.ContinueWhen()?

Вызвать эти методы не проблема. Проблема скомбинировать результаты выполнения нескольких тасков в одном выражении, как это делается в монадном сахаре.

S>>return зашит в самом SelectMany, кроме этого у него два аргумента-функции.


S>А почему именно две ф-ия аргумента важны? Почему просто Select не подходит. Я реально в этом(монадах) не понимаю ничего, вот и спрашиваю. Тут, вероятно, надо понять как bind работает...

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

S>>>>Так и не знаю причины, почему это реализовано именно так.


S>>Я же написал выше. Связывание вычислений по нескольким контейнерам в Haskell, F#, Scala — вложенное. Есть внешний bind, в который передается функция, использующая следующий bind:

S>>
S>>bind(...,x => bind(...))
S>>

S>>Но в C# мы имеем:
S>>
S>>a.SelectMany(...).SelectMany(...)
S>>


S>Не очень помогло, ибо по-прежнему не пониаю сути bind...

Как Select/map в функторе проецирует контейнер с помощью указанного преобразования для значений в контейнере, так bind показывает как связывать вычисление из двух контейнеров одного монадного типа в третий. Именно он определяет что результат связывания вычислений по двум спискам основан на декартовом произведении, что для MayBe<T> нужно проверить наличие обоих значений, для двух тасков — создать таск, который скомбинирует результаты двух данных по мере получения результатов.
Именно этого и не хватало в C# для комбинирования двух тасков.
Re[22]: Об монады.
От: Sharov Россия  
Дата: 03.09.19 14:41
Оценка:
Здравствуйте, samius, Вы писали:

S>Здравствуйте, Sharov, Вы писали:


S>>Здравствуйте, samius, Вы писали:


S>>>И все-таки Task<T> не был интегрирован в Linq и без await использовать его в коде было тяжело.


S>>А в чем проблема вызвать Task.Wait() или Task.ContinueWhen()?

S>Вызвать эти методы не проблема. Проблема скомбинировать результаты выполнения нескольких тасков в одном выражении, как это делается в монадном сахаре.


S>Как Select/map в функторе проецирует контейнер с помощью указанного преобразования для значений в контейнере, так bind показывает как связывать вычисление из двух контейнеров одного монадного типа в третий. Именно он определяет что результат связывания вычислений по двум спискам основан на декартовом произведении, что для MayBe<T> нужно проверить наличие обоих значений, для двух тасков — создать таск, который скомбинирует результаты двух данных по мере получения результатов.

S>Именно этого и не хватало в C# для комбинирования двух тасков.

TaskFactory.ContinueWhenAll
Кодом людям нужно помогать!
Re[23]: Об монады.
От: samius Япония http://sams-tricks.blogspot.com
Дата: 03.09.19 15:39
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, samius, Вы писали:


S>>Именно этого и не хватало в C# для комбинирования двух тасков.


S>TaskFactory.ContinueWhenAll


Хотелось бы увидеть пример применения ContinueWhenAll, не сильно далекий от следующего:

var task3 = from string a in task1
            from int b in task2
            select $"{a}:{b}";
Re[5]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: jamesq Россия  
Дата: 03.09.19 15:46
Оценка:
Здравствуйте, AlexGin, Вы писали:

AG>Здравствуйте, уважаемый alzt, Вы писали:


A>>Не знаю ни одного человека, кто бы "выучил язык за деньги". Большинство учило, т.к. им было интересно программировать.

AG>+100500
AG>Да, именно потому, что интересно!
AG>А если интересно, то будт тебе работа в радость!
AG>Тогда-то и за оплатой твоего труда — дело не станет!

<offtopic>
К сожалению, такие заявления разбиваются о прозу реальности.
Некоторые считают, что коли сотруднику интересно, можно особо ему не платить. Он на голом интересе работать будет.
</offtopic>
Re[24]: Об монады.
От: Sharov Россия  
Дата: 03.09.19 17:54
Оценка:
S>>TaskFactory.ContinueWhenAll
S>Хотелось бы увидеть пример применения ContinueWhenAll, не сильно далекий от следующего:

S>
S>var task3 = from string a in task1
S>            from int b in task2
S>            select $"{a}:{b}";
S>


var rand = new Random();
            Task<int> task1 = Task<int>.Factory.StartNew((() =>
            {
                Thread.Sleep(rand.Next(2000));
                return 9;
            }));

            var task2 = Task<string>.Factory.StartNew((() =>
            {
                Thread.Sleep(rand.Next(2000));
                return "asdsa";
            }));

           var cont = Task.Factory.ContinueWhenAll(new Task[]{task1, task2}, (tasks) =>
           {
               int i = tasks.OfType<Task<int>>().First().Result;
               string str = tasks.OfType<Task<string>>().First().Result;
               var temp = $"{i}:{str}";
               return temp;
            });


Я понимаю, что енто мягко говоря не айс. Еще можно использовать сами таски task1 и task2 в самом continuationэ'е и взять результат без приседаний. Либо чуть более изящный варинат,
но не эффективный -- всюду использовать Task<object>. Но теряем в типизации и boxing.
Кодом людям нужно помогать!
Re[25]: Об монады.
От: samius Япония http://sams-tricks.blogspot.com
Дата: 03.09.19 19:52
Оценка:
Здравствуйте, Sharov, Вы писали:

S>>Хотелось бы увидеть пример применения ContinueWhenAll, не сильно далекий от следующего:


S>>
S>           var cont = Task.Factory.ContinueWhenAll(new Task[]{task1, task2}, (tasks) =>
S>           {
S>               int i = tasks.OfType<Task<int>>().First().Result;
S>               string str = tasks.OfType<Task<string>>().First().Result;
S>               var temp = $"{i}:{str}";
S>               return temp;
S>            });
S>

На выражение не похоже, но можно без особого труда заинлайнить все переменные... В ущерб читаемости кода.
Кстати, можно сделать
int i = task1.Result;


S>Я понимаю, что енто мягко говоря не айс. Еще можно использовать сами таски task1 и task2 в самом continuationэ'е и взять результат без приседаний. Либо чуть более изящный варинат,

S>но не эффективный -- всюду использовать Task<object>. Но теряем в типизации и boxing.

А теперь представим, что некоторую задачу task3 нужно запустить только в случае если сошлись звезды (выполнились условия над результатами первых двух задач), и в свою очередь к его Continuation передать результат вычисления первого ContinueWhenAll...
При этом, если части задач указать, что они должны быть выполнены синхронно (не требуют ожидания, т.к. входящие таски выполнены), прописать, что нужно делать при каких исключениях, станет понятно что простая идея кода будет превращена в лапшу. Здесь await-ы (не являясь, фактически, монадами) подходят лучшим образом.
Re[13]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: dsorokin Россия  
Дата: 04.09.19 04:59
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Poopy Joe, Вы писали:


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


S>Если хочешь понять что такое монады — читай пост IT http://rsdn.org/forum/flame.comp/7530546.1
Автор: IT
Дата: 30.08.19


S>Это всего лишь способ избавиться от "служебного кода".


Поддерживаю здесь коллегу Poopy Joe. Правильно написал. Может быть, только должно быть: "решать проблемы которых нет в функциональныхимперативных языках (с)"

И тут как с обычной математикой. Есть такой парадокс. Чем вещь проще и абстрактнее, тем ее обычно сложнее понять и оценить. Хаскель в своей основе довольно прост, лаконичен и изящен как сама математика.

Здесь надо просто читать книги по хаскелю, писать на нем код. На тех же Java, C#, C++ нужно делать ровно то же самое. Просто последние языки похожи во многом друг на друга (без учета GC). Поэтому опыт в одном из них идет в копилку знаний для другого. Так и накапливается совокупный опыт со школьных ученических лет. Поэтому студенты уже могут писать вполне неплохой код на последних языках.

Хаскель же другой, но в принципе позволяет решать те же проблемы, кроме системных задач, для которых годятся лишь немногие: C++ там, С, Ada, Rust, Forth, асемблер, но их в наше время осталось совсем немного таких.

Может быть, только хаскель лучше подходит тем, у кого есть способности к математике, но таких программистов довольно много, и даже среди не-программистов. Диплом вуза это не репрезентативный критерий.
Отредактировано 04.09.2019 5:03 dsorokin . Предыдущая версия .
Re[14]: Реальные проекты на экзотике (Hascell и пр.) - как?
От: Poopy Joe Бельгия  
Дата: 04.09.19 06:50
Оценка:
Здравствуйте, dsorokin, Вы писали:

D>Поддерживаю здесь коллегу Poopy Joe. Правильно написал. Может быть, только должно быть: "решать проблемы которых нет в функциональныхимперативных языках (с)"

О, конечно императивных, спасибо за исправление.

D>И тут как с обычной математикой. Есть такой парадокс. Чем вещь проще и абстрактнее, тем ее обычно сложнее понять и оценить. Хаскель в своей основе довольно прост, лаконичен и изящен как сама математика.

Странные доводы критиков ФЯ, хаскель тут лишь один из множества, в том, что все эти абстракции нужны редко. Но тут перепутаны причина и следствие. Это не абстракции нужны редко, это их наличие позволяет их использовать в своих решениях. Тут подойдет сравнение не только с математикой, но и с обычным языком. Можно разговаривать исключительно матом, вставляя "абстракции" только в крайнем случае. Многословно да, не особенно внятно и нет гарантии, что поймут верно. Но ведь поймут, при должном старании. А можно выучить язык и использовать всю его мощь, для краткого и точного выражения мыслей. И для этого не надо быть математиком или филологом.
Re[26]: Об монады.
От: Sharov Россия  
Дата: 04.09.19 09:26
Оценка:
Здравствуйте, samius, Вы писали:


S>Кстати, можно сделать

S>
S>int i = task1.Result;
S>


Я ровно ентот способ и описал:

Еще можно использовать сами таски task1 и task2 в самом continuationэ'е и взять результат без приседаний.


S>А теперь представим, что некоторую задачу task3 нужно запустить только в случае если сошлись звезды (выполнились условия над результатами первых двух задач), и в свою очередь к его Continuation передать результат вычисления первого ContinueWhenAll...

S>При этом, если части задач указать, что они должны быть выполнены синхронно (не требуют ожидания, т.к. входящие таски выполнены), прописать, что нужно делать при каких исключениях, станет понятно что простая идея кода будет превращена в лапшу. Здесь await-ы (не являясь, фактически, монадами) подходят лучшим образом.

Не очень понял постановку задачи, но не суть. А вот чем await лучше ContinueWith, учитывая что первое есть синтаксический сахар для второго?
Я не вижу, что можно сделать с помощью await чего нельзя с помощь ContinueWith.
Кодом людям нужно помогать!
Re[6]: Реальные проекты на экзотике (Haskell и пр.) - как?
От: AlexGin Беларусь  
Дата: 04.09.19 14:22
Оценка:
Здравствуйте, уважаемый jamesq, Вы писали:

AG>>Да, именно потому, что интересно!

AG>>А если интересно, то будт тебе работа в радость!
AG>>Тогда-то и за оплатой твоего труда — дело не станет!

J><offtopic>

J>К сожалению, такие заявления разбиваются о прозу реальности.
J>Некоторые считают, что коли сотруднику интересно, можно особо ему не платить. Он на голом интересе работать будет.
J></offtopic>

Ну если же за оплатой твоего труда всё-таки дело станет, то человеку увлеченному и знающему — легко сменить работодателя.
Тем более, что увлечённость и интерес — предполагает постоянный и непрерывный професиональный рост.
В этом случае, поиск новой работы и прохождение собеседований — рассматривается профессионалом как ещё один (очередной) вариант повышения квалификации.
Отредактировано 04.09.2019 14:26 AlexGin . Предыдущая версия .
Re: Реальные проекты на экзотике (Haskell и пр.) - как?
От: _AND Российская Империя За Русский мир! За Русь святую!
Дата: 04.09.19 17:01
Оценка:
S>Вот, некоторые люди на работе пишут на Haskell. Как они до этого доходят?

Я вот писал на с++. Пришёл в контору, которой нужен был программист на экзотическом языке, но где понимали что его не найти и искали сишников что-бы потом переучить. Пару месяцев почитал книжки, поразбирался с проектом и вперёд. Так и дошёл.
Re[27]: Об монады.
От: samius Япония http://sams-tricks.blogspot.com
Дата: 04.09.19 21:44
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, samius, Вы писали:


S>>При этом, если части задач указать, что они должны быть выполнены синхронно (не требуют ожидания, т.к. входящие таски выполнены), прописать, что нужно делать при каких исключениях, станет понятно что простая идея кода будет превращена в лапшу. Здесь await-ы (не являясь, фактически, монадами) подходят лучшим образом.


S>Не очень понял постановку задачи, но не суть. А вот чем await лучше ContinueWith, учитывая что первое есть синтаксический сахар для второго?

Код более читаемый, значит, в него легче въехать и изменить либо исправить.

S>Я не вижу, что можно сделать с помощью await чего нельзя с помощь ContinueWith.

Точно так же ничего такого нельзя сделать на C#/C++/Haskell, чего нельзя на ассемблере. Вопрос удобства, скорости разработки, стоимости, легкости поиска замены специалистов. Ответ на вопрос "чем лучше" лежит в плоскости нефункциональных требований.
Re[28]: Об монады.
От: Sharov Россия  
Дата: 06.09.19 13:00
Оценка:
Здравствуйте, samius, Вы писали:

S>>Не очень понял постановку задачи, но не суть. А вот чем await лучше ContinueWith, учитывая что первое есть синтаксический сахар для второго?

S>Код более читаемый, значит, в него легче въехать и изменить либо исправить.

Воможно. У меня в коде полно коснтрукций типа

     var task1 = TaskFactory.StartNew(() =>
                    {
               //do smth
                    }, TaskCreationOptions.LongRunning|TaskCreationOptions.PreferFairness);



            var reserveTask = task1 (
                    t => { //do smth},
                    TaskContinuationOptions.NotOnRanToCompletion|TaskContinuationOptions.PreferFairness);



Я четко контролирую параметры continuation'а. С awiat'ом как это можно получить? А так на все случаи жизни я прописыаю соотв continuation с соотв параметрами.
Кодом людям нужно помогать!
Re[29]: Об монады.
От: samius Япония http://sams-tricks.blogspot.com
Дата: 07.09.19 03:05
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, samius, Вы писали:


S>>>Не очень понял постановку задачи, но не суть. А вот чем await лучше ContinueWith, учитывая что первое есть синтаксический сахар для второго?

S>>Код более читаемый, значит, в него легче въехать и изменить либо исправить.

S>Воможно. У меня в коде полно коснтрукций типа


S>
S>     var task1 = TaskFactory.StartNew(() =>
S>                    {
S>               //do smth
S>                    }, TaskCreationOptions.LongRunning|TaskCreationOptions.PreferFairness);



S>            var reserveTask = task1 (
S>                    t => { //do smth},
S>                    TaskContinuationOptions.NotOnRanToCompletion|TaskContinuationOptions.PreferFairness);
S>



S>Я четко контролирую параметры continuation'а. С awiat'ом как это можно получить? А так на все случаи жизни я прописыаю соотв continuation с соотв параметрами.


await-ы не отменяют параметры тасков, continuation-ов. Они меняют форму получения и обработки значений. Склеивают воедино те места кода (примера) где написано

//do smth
//do smth
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.