
Akhmed
28.02.2017
17:50:17
а если нужно разруливать разные инстансы то тут масса вариантов

Roman
28.02.2017
17:50:26

Akhmed
28.02.2017
17:51:00
или регистрировать отдельные интерфейсы или же декоратор или еще лучше декоратором разруливать реализацию а саму работу компоненты выделить и держать в чистом виде
ну собственно эти же принципы и касаются при проектировании в функциональном подходе

Google

Akhmed
28.02.2017
17:51:28
должна быть чистая логика с чистыми функциями
все что можно сделать чистыми
а все остальное - работа с запросом, веб апи и т.п - что уже не может быть чистыми отдельно компоновать
в любом случае мелкие домашние проекты на F# пока получается сделать с теми ссылками что вы кидали без проблем

Roman
28.02.2017
17:53:25

Akhmed
28.02.2017
17:53:32
я пока еще не до конца разобрался как в огромных enterpise проектах компоновать код
в функциональном стиле
мне самом не нравится этот мусорный код с интерфейсами

Roman
28.02.2017
17:54:19
точно без DI Контейнеров
ща покажу все же

Akhmed
28.02.2017
17:54:42
но C# разработчики отравлены Resharper который весь этот мусор самостоятельно генерирует

Roman
28.02.2017
17:55:01
https://github.com/louthy/csharp-monad/blob/master/CSharpMonad/src/Reader.cs

Akhmed
28.02.2017
17:55:13
а с ними реально проще очень быстро рефакторить огромный проект так что бы тесты не ломались на каждый чих

Google

Roman
28.02.2017
17:55:21
или вот
https://gist.github.com/vmarquez/4640678

Akhmed
28.02.2017
17:55:55
ну вот надо подучиться - буду учить

Roman
28.02.2017
17:56:00

Akhmed
28.02.2017
17:56:22
мы сидим на игле с интерфейсами из за того что мы очень быстро штампуем новые фичи и проект при этом не разваливается в хлам

Igor
28.02.2017
17:56:37

Akhmed
28.02.2017
17:57:46
например в один прекрасный день к нам пришли серверщики и сказали что им наша читалка клиентская нужна на сервере что бы он валидировал пакеты до того как их загрузят в основную систему
так я выкинул полностью текущий UI налепил сверху новый UI который кушает пакет и выдает список ошибок и сделал отдельный вебсервис который аплоадит файл и выдает список багов в течении одного дня
и это в проекте почти с 3к классами

Igor
28.02.2017
17:59:16

Akhmed
28.02.2017
17:59:25
так уже выделено

Roman
28.02.2017
17:59:30
интерфейсы нужны для абстрации. Абстракции можно реализовывать не толкьо с помощью интерфейсов, сигнаитуры гораздо лушче в этом плане

Akhmed
28.02.2017
17:59:31
в PCL И есть эта логика
и эта логика используется в Android, iOS, Windows
вот я и хочу научится получать такую же гибкость в функциональном стиле

Roman
28.02.2017
18:00:54
статью выше посмотри.

Akhmed
28.02.2017
18:01:03
что бы не генерировать столько мусорного кода с интерфейсами
Статью видел но надо попробовать на практике сделать проект и опробовать. А то до меня так не дойдет пока не попробую руками на каком нибудь приличном проекте )
кстати новая статья вышла .net week
https://blogs.msdn.microsoft.com/dotnet/2017/02/28/the-week-in-net-on-net-with-eric-mellino-happy-birthday-from-scott-hunter-ozcode/

Google

Roman
28.02.2017
19:02:40
у меня тут восхищение оптимизатором .нет при дебаге три сервиса отрабатывают 1000 задач за 30 минут. со средним временм исполнения задачи в 83 секунды(параллельно исполняется)
но без дебага эта тысяча здача исполняется меньше чем за минуту.
со средним временем исполнения задачаи 0.7 секунды

Igor
28.02.2017
19:06:52

Roman
28.02.2017
19:07:07
?
это dotnet framework

Igor
28.02.2017
19:08:21

Roman
01.03.2017
10:00:35
https://youtu.be/2QQUiOjPit8
Чем фп хорошо, так это тем что нет привязка к фоннеейманской архитектуре
И не важно какой у тебя компьютер: биокомпьютер или квантовый или классический, ты можешь использовать функции.
Кстати, как догадка, одна из причин почему в райдере сначала не планировалось f#, как раз потому что решарпер для f# не нужен.
@SherievAkhmed это если продолжать наш разговор из соседнего хамарин чата)

Akhmed
01.03.2017
17:49:34
Ну я бы безоговорочно заставил бы команду перейти на f# не будь у нас r# ))

Roman
01.03.2017
17:50:16
Какое значительное кол-во людей пришло. Если не секрет откуда?

Arseniy
01.03.2017
17:51:32
из сишарпа. всё как всегда. откуда ж ещё в f# перекатываются

Roman
01.03.2017
17:52:00

Arseniy
01.03.2017
17:53:02

Igor
01.03.2017
18:12:52
Виновен ?

Google

GNU/Patchouli
01.03.2017
18:20:02
Только сейчас обратила внимание, что на скриншоте в гитхабе gentoo/dotnet
https://camo.githubusercontent.com/237d0944b852d8868335f1ddb525b5076065dbde/687474703a2f2f692e696d6775722e636f6d2f344f6d794735642e6a7067
Шахматы на F# ??

Vasily
01.03.2017
20:36:21
О,чатик по фшарпу.То,шо надо

Женя Зэ
01.03.2017
21:40:14
Василий, как дела у фшарпа на линуксах?

Igor
01.03.2017
21:45:14

Женя Зэ
01.03.2017
21:47:32

Igor
01.03.2017
21:49:16

Женя Зэ
01.03.2017
21:50:52
Да я где-то натыкался что у фшарпа из окамла ноги растут

Igor
01.03.2017
21:52:42

Arseniy
01.03.2017
21:52:55
https://github.com/fsprojects/FSharp.Compatibility
емнип компилятор F* пишется на F# c вот этими библиотеками совместимости, чтобы можно было собрать компилятором ocaml

Akhmed
01.03.2017
21:55:02
F# далеко не случайно похож на OCaml
он ведь был разработан Доном Саймом

Женя Зэ
01.03.2017
21:55:25

Akhmed
01.03.2017
21:55:48

Roman
01.03.2017
21:55:56

Akhmed
01.03.2017
21:57:19
https://www.slant.co/topics/485/~best-languages-for-learning-functional-programming

Arseniy
01.03.2017
21:57:20
это не так
а как? я знаю про окамал только в джейн стрит. это финансы, фишарп в принципе там же более-менее зашел.

Igor
01.03.2017
21:57:28

Google

Roman
01.03.2017
21:57:35

Igor
01.03.2017
21:59:55
Лучше расскажите чем OCaml отличается от F# (кроме того что второй на .net).


Akhmed
01.03.2017
22:01:17
я не знаю в чем отличия но что точно знаю это то что F# проектировался Доном с оглядкой на OCaml
Вот перевод интервью с автором F#
http://www1.fcenter.ru/forprint.shtml?online/articles/software/interview/7346
Дон Сайм: Я работал над F# в течение последних 18 месяцев прямо здесь, в Microsoft Research в Кембридже. Хотя функциональные языки известны уже давно, аж с 1970-ых, программистам всегда не хватало таких прагматических возможностей, как библиотеки и поддержка времени выполнения. Одним из лучших функциональных языков является Caml, разработанный INRIA во Франции в 1990-ых годах. Но у Caml другая проблема - он до сих пор борется за совместимость с популярными библиотеками, доступными сегодня для таких платформ как Java и .NET.
Структура F# во многом схожа со структурой Caml с той лишь разницей, что первая реализована поверх библиотек и среды исполнения .NET. Такой подход в корне решает проблему совместимости библиотек и проблему взаимодействия языков между собой: не забывайте, что .NET разрабатывалась еще и для того, чтобы разные языки могли легко взаимодействовать друг с другом, вот и сейчас код на F# может быть легко использован в С# и наоборот.
не забывайте только что статья 2003 года когда F# был все таки заметно победнее чем то что есть сейчас


Женя Зэ
01.03.2017
22:04:39
А Скала когда вышла?
2010-2009?

Akhmed
01.03.2017
22:05:16
чего не знаю того не знаю )
но я знаю что с интерпорабольностью типов в Scala не все так гладко как F# c C# .net

Женя Зэ
01.03.2017
22:06:16
Ну скала наверное самый прямой конкурент же, да?