а если нужно разруливать разные инстансы то тут масса вариантов

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

всего не продумать.

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

ну собственно эти же принципы и касаются при проектировании в функциональном подходе

должна быть чистая логика с чистыми функциями

все что можно сделать чистыми

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

в любом случае мелкие домашние проекты на F# пока получается сделать с теми ссылками что вы кидали без проблем

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

Так о чем и речь, фактически все это реализуется с помощью Reader.

я пока еще не до конца разобрался как в огромных enterpise проектах компоновать код

в функциональном стиле

мне самом не нравится этот мусорный код с интерфейсами

точно без DI Контейнеров

ща покажу все же

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

https://github.com/louthy/csharp-monad/blob/master/CSharpMonad/src/Reader.cs

а с ними реально проще очень быстро рефакторить огромный проект так что бы тесты не ломались на каждый чих

или вот

https://gist.github.com/vmarquez/4640678

ну вот надо подучиться - буду учить

https://gist.github.com/vmarquez/4640678

и работа с зависимостями и в жопу интерфейсы

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

я пока еще не до конца разобрался как в огромных enterpise проектах компоновать код

Где-то пролетала мысль "использовать модули", вместо классов/интерфейсов, в которых есть небольшой набор публичных функций/типов (можно наверное даже инкапсулить их в отдельных проектах). Уровень абстракции взлетает в небеса ?

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

так я выкинул полностью текущий UI налепил сверху новый UI который кушает пакет и выдает список ошибок и сделал отдельный вебсервис который аплоадит файл и выдает список багов в течении одного дня

и это в проекте почти с 3к классами

так я выкинул полностью текущий UI налепил сверху новый UI который кушает пакет и выдает список ошибок и сделал отдельный вебсервис который аплоадит файл и выдает список багов в течении одного дня

А почему это кусок не выделить в отдельную PCL библиотеку?

так уже выделено

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

в PCL И есть эта логика

и эта логика используется в Android, iOS, Windows

вот я и хочу научится получать такую же гибкость в функциональном стиле

статью выше посмотри.

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

Статью видел но надо попробовать на практике сделать проект и опробовать. А то до меня так не дойдет пока не попробую руками на каком нибудь приличном проекте )

кстати новая статья вышла .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/

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

но без дебага эта тысяча здача исполняется меньше чем за минуту.

со средним временем исполнения задачаи 0.7 секунды

со средним временем исполнения задачаи 0.7 секунды

Это полный Windows .NET?

?

это dotnet framework

это dotnet framework

Просто интересно, как это было бы на MONO или CORE

https://youtu.be/2QQUiOjPit8

Чем фп хорошо, так это тем что нет привязка к фоннеейманской архитектуре

И не важно какой у тебя компьютер: биокомпьютер или квантовый или классический, ты можешь использовать функции.

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

@SherievAkhmed это если продолжать наш разговор из соседнего хамарин чата)

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

*В райдере

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

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

Думаю они бы сами ппроили.)

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

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

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

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

Виновен ?

Только сейчас обратила внимание, что на скриншоте в гитхабе gentoo/dotnet https://camo.githubusercontent.com/237d0944b852d8868335f1ddb525b5076065dbde/687474703a2f2f692e696d6775722e636f6d2f344f6d794735642e6a7067

Шахматы на F# ??

О,чатик по фшарпу.То,шо надо

Василий, как дела у фшарпа на линуксах?

Василий, как дела у фшарпа на линуксах?

Вроде норм, он всегда официально поддерживал mono, а теперь и core. Как IDE можно использовать VSCode или MonoDeveloper.

Вроде норм, он всегда официально поддерживал mono, а теперь и core. Как IDE можно использовать VSCode или MonoDeveloper.

А если с окмлом сравнить? Что более линуксово?

А если с окмлом сравнить? Что более линуксово?

ocaml? не знаю не смотрел - мы же тут под .NET разрабатываем

Да я где-то натыкался что у фшарпа из окамла ноги растут

Да я где-то натыкался что у фшарпа из окамла ноги растут

Это правда, но я даже не знаю где чистый ocaml востребован.

https://github.com/fsprojects/FSharp.Compatibility

емнип компилятор F* пишется на F# c вот этими библиотеками совместимости, чтобы можно было собрать компилятором ocaml

F# далеко не случайно похож на OCaml

он ведь был разработан Доном Саймом

Это правда, но я даже не знаю где чистый ocaml востребован.

Ну наверное там же где фшарп?

Ну наверное там же где фшарп?

это не так

А если с окмлом сравнить? Что более линуксово?

Окамл давнее линуксов. А так оба родные, что окамл что f#

Это правда, но я даже не знаю где чистый ocaml востребован.

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

https://www.slant.co/topics/485/~best-languages-for-learning-functional-programming

это не так

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

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

Да на википедии рассписано: На языке OCaml, в частности, написан рендеринг формул Википедии, использующих тег <math>, файлообменный клиент MLDonkey, стек управления гипервизором Xen xapi (является частью Xen Server/Xen Cloud Platform), язык программирования HaXe.

емнип компилятор F* пишется на F# c вот этими библиотеками совместимости, чтобы можно было собрать компилятором ocaml

Кстати, про f* кто что может рассказать? Что это? зачем?

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

я не знаю в чем отличия но что точно знаю это то что 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# был все таки заметно победнее чем то что есть сейчас

не забывайте только что статья 2003 года когда F# был все таки заметно победнее чем то что есть сейчас

Интересно

А Скала когда вышла?

2010-2009?

чего не знаю того не знаю )

но я знаю что с интерпорабольностью типов в Scala не все так гладко как F# c C# .net

Ну скала наверное самый прямой конкурент же, да?