@Fsharp_chat
Алекс18.09.2017
18:01:59
18:01:59
\o/
https://twitter.com/sforkmann/status/909815497734213632
Расскажите доступным языком что такое произошло?))
Oleg18.09.2017
18:02:13
18:02:13
== Мне сложно представить веб приложение без npm
На всякий случай Bower - самый популярный менеджер пакетов для клиентского яваскрипта :) Npm устанавливает зависимости для каждого пакета отдельно, в папку этого пакета, потом так же ставит зависимости зависимостей и так далее. В клиентском яваскрипте это недопустимо: нельзя подключить на страницу две версии jQuery или любой другой библиотеки. В Бовере каждый пакет устанавливается один раз, и в случае конфликта зависимостей Бовер просто не станет устанавливать пакет, несовместимый с уже установленными.
Давно есть Yarn, который решает эти проблемы npm, а также проблему отсутствия .lock-файла для зависимостей
Evgeniy18.09.2017
18:03:45
18:03:45
Расскажите доступным языком что такое произошло?))
Чувак, который в JetBrains работает над поддержкой F# в Rider, пишет код в FSharp.Compiler.ServicesАлекс18.09.2017
18:05:31
18:05:31
Чувак, который в JetBrains работает над поддержкой F# в Rider, пишет код в FSharp.Compiler.Services
Может наоборот?.. чувак который пишет код для компилера работает над поддержкой в rider?))
GoogleАлекс18.09.2017
18:05:43
18:05:43
В любом случае это хорошо)
Evgeniy18.09.2017
18:17:10
18:17:10
Akkling (experimental F# API for Akka.NET) v0.7 released:
https://www.nuget.org/packages/Akkling/
Roman18.09.2017
18:17:19
18:17:19
Ого
Oleg18.09.2017
18:19:11
18:19:11
Akkling (experimental F# API for Akka.NET) v0.7 released:
https://www.nuget.org/packages/Akkling/
Это здорово, но под netcore ведь нет сборки? Может помочь человеку в портировании?Evgeniy18.09.2017
18:20:00
18:20:00
Это здорово, но под netcore ведь нет сборки? Может помочь человеку в портировании?
Я вижу FsPickler в зависимостях. А его портировать, как я понимаю, нетривиальная задача.Oleg18.09.2017
18:23:44
18:23:44
Я вижу FsPickler в зависимостях. А его портировать, как я понимаю, нетривиальная задача.
Мда... в Akka.FSharp тоже она используется. Поговорю с автором может быть можно есть идеи заменить FsPicklerМне вообще Akka.Streams нужны, в Akkling они нормально завернуты
Evgeniy18.09.2017
18:25:35
18:25:35
Мда... в Akka.FSharp тоже она используется. Поговорю с автором может быть можно есть идеи заменить FsPickler
Было бы неплохо заменить, конечно.
https://github.com/mbraceproject/FsPickler/issues/83#issuecomment-330175730Oleg18.09.2017
18:40:26
18:40:26
Покопаюсь завтра https://www.reddit.com/r/dotnet/comments/64xdnx/binary_serialization_alternative_in_net_core/
Pawel18.09.2017
20:03:01
20:03:01
Давно есть Yarn, который решает эти проблемы npm, а также проблему отсутствия .lock-файла для зависимостей
корень проблем yarn не решает. Он кеширует пакеты, которые есть у него в реестре, c остальными работает в точности как npm с node_modules - не детерминированно сваливает всё в большую локальную помойку. Потому что нужно чтобы была совместимость с npm. Большинство популярных либ не заморачиваются yarn версиями, ограничившись npm - yarn и так поймёт. appolo.js напримерkana18.09.2017
20:07:51
20:07:51
Только увидел твое сообщение про бовер. Почему-то был уверен, что он умер 2-3 года назад и все давно используют чисто вебпак с нпм, или аналоги для бандлинга, но именно с нпм
Pawel18.09.2017
20:14:22
20:14:22
Как я это понимаю, Fable создает Babel AST из F# AST, которое ему дает F# Compiler Services, в результате в Fable не нужно реализовывать лексеры/парсеры и кодогенерацию (генерацию JS). Грамотный пример повторного использования
по такой логике можно сделать ядро линукса с зависимостью от user32.dll и назвать это грамотным примером повторного использования. Мне кажется такое никто использовать не станетRoman19.09.2017
09:25:37
09:25:37
Можно на F# побаловаться.
GoogleRoman19.09.2017
09:25:37
09:25:37
Официально открыта площадка http://aicups.ru!
https://habrahabr.ru/company/mailru/blog/337942/ анонс первого чемпионата. Go к нам ;)
Проблема только в клиенте. C# клиент это java код транспличеный в C#.
Привет!
Vasily19.09.2017
14:28:51
14:28:51
Отож
Friedrich19.09.2017
14:29:18
14:29:18
Даже иногда код пишут!
Aleksey19.09.2017
14:29:26
14:29:26
Это хорошо! Активное сообщество - это важно!
Friedrich19.09.2017
14:30:51
14:30:51
Если что, мы базируемся вот тут: http://fsharplang.ru/ / https://github.com/fsharplang-ru
У нас там есть переводы статей (изредка закидываем на хабр) и проекты.
Привет!
Yuri19.09.2017
14:31:39
14:31:39
Привет!
Aleksey19.09.2017
14:32:51
14:32:51
Я то сам - хаскелист (а ещё Elm и PureScript), так что сюда заглянул больше для интересу, чем из профессионального любопытства :)
Но в плане common FP questions могу помочь, если что :)
Vasily19.09.2017
14:34:23
14:34:23
За теорию категорий ответишь? :)
Aleksey19.09.2017
14:35:13
14:35:13
Не, я практик больше. За теоркатом - в хаскелечатик или к идрисовцам :)
Монады знаю, да :)
Vasily19.09.2017
14:37:15
14:37:15
Да концепция монад-то в целом более-менее понятна, как ее на практике применять
Aleksey19.09.2017
14:39:14
14:39:14
Мы применяем постоянно :) Потому как по-другому у нас нельзя
Friedrich19.09.2017
14:40:48
14:40:48
А вот в F# вполне можно припеваючи жить, не зная монад и всего такого.
Хотя некоторые заковыристые библиотеки без этого очень сложно понять.
(хотя некоторые библиотеки и с этим сложно понять)
GoogleVasily19.09.2017
14:42:26
14:42:26
Некоторые библиотеки вообще не понять
Aleksey19.09.2017
14:42:51
14:42:51
Дело не в припеваючи/неприпеваючи. Дело в том, носколько предсказуемо работает программа и насколько полно можно о ней рассуждать. Монады это позволяют. Как и любой другой способ контроля эффектов
Vlad19.09.2017
14:43:09
14:43:09
Хотя некоторые заковыристые библиотеки без этого очень сложно понять.
это ты про кастомные операторы и >=> ?Vlad19.09.2017
14:43:43
14:43:43
рыбки читаемость портят для несведущих, это да
Aleksey19.09.2017
14:44:13
14:44:13
встроенные в Perl регулярки читаемость портят для всех :)
А синтаксис разный бывает, не Алголом единым, как говорится
В ASCII маловато символов, поэтому и приходится "рыбок" делать
Friedrich19.09.2017
14:45:51
14:45:51
Хе-хе, надо Дону предложить добавить юникодовые операторы :)
Vasily19.09.2017
14:46:06
14:46:06
программирование на смайлах
Aleksey19.09.2017
14:46:21
14:46:21
Можно просто лигатуры прикрутить :)
Friedrich19.09.2017
14:46:28
14:46:28
Наделают всяких →> ¡ ¿
Можно просто лигатуры прикрутить :)
В этом же самый смак! Смешать лигатуры с настоящими юникодовыми операторами, и потом дружно в них путаться :)Evgeniy19.09.2017
14:47:12
14:47:12
Хе-хе, надо Дону предложить добавить юникодовые операторы :)
https://github.com/fsharp/fslang-suggestions/issues/224Aleksey19.09.2017
14:47:16
14:47:16
В Haskell есть юникодные операторы, но это как-то не прижилось - слишком рано добавили, тогда ещё многие в терминале сидели и не у всех отображалось :)
Aleksey19.09.2017
14:47:44
14:47:44
Elm-овцы вон тоже лигатуры любят
Особенно для |> и <|
Только у Elm нету тайпклассов, поэтому полиморфизм ограничен (тем, что он - не ограниченный), а значит ограничиться небольшим кол-вом полиморфных операторов не выйдет...
Evgeniy19.09.2017
14:50:55
14:50:55
GoogleAleksey19.09.2017
14:51:19
14:51:19
Модули же есть, вроде?
Aleksey19.09.2017
14:52:42
14:52:42
это когда ты пишешь
class Eq a where
(==) :: a -> a -> Bool
Это подразумевает, что любой тип, который принадлежит этому классу типов, умеет ==
Vasily19.09.2017
14:53:11
14:53:11
А, тип вычисляется на основе сигнатур констрейнтов?
Aleksey19.09.2017
14:53:19
14:53:19
Ага
Vasily19.09.2017
14:53:44
14:53:44
Т.е. под него попадает любой тип, в котором реализовано ==
Aleksey19.09.2017
14:53:50
14:53:50
Т.е. можно написать
unique :: Eq a => [a] -> Bool
Vasily19.09.2017
14:54:19
14:54:19
Строку не совсем понял
Aleksey19.09.2017
14:54:56
14:54:56
Эта функция полиморфна - работает для любых списков [a] - но требует, чтобы элементы списка a поддерживали проверку на равество (Eq a)
Friedrich19.09.2017
14:55:23
14:55:23
Т.е. под него попадает любой тип, в котором реализовано ==
Это чем-то похоже на наши SRTP, только у нас пока несколько ограниченней.Если завезут SRTP, которые резолвятся по методам-расширениям, у нас станет так же мощно.
Тогда заживём!
Aleksey19.09.2017
14:55:59
14:55:59
Это чем-то похоже на интерфейсы в ООП, только возможностей больше
Evgeniy19.09.2017
14:56:00
14:56:00
Vasily Мне нравятся объяснения через реализацию. Вот, смотри, возможный концепт тайпклассов для F#.
https://github.com/MattWindsor91/visualfsharp/blob/hackathon-vs/examples/fsconcepts.md
Vasily19.09.2017
14:56:05
14:56:05
Ну будем ждать
Friedrich19.09.2017
14:56:48
14:56:48
Vasily Мне нравятся объяснения через реализацию. Вот, смотри, возможный концепт тайпклассов для F#.
https://github.com/MattWindsor91/visualfsharp/blob/hackathon-vs/examples/fsconcepts.md
Ага, отдельный бонус в том, что у нас уже есть несколько прототипов разной степени свежести и готовности, которые пробивают дорогу для тайпклассов.Evgeniy19.09.2017
14:57:27
14:57:27
Если завезут SRTP, которые резолвятся по методам-расширениям, у нас станет так же мощно.
Вариантов два на самом деле:
1. Тайпклассы можно будет соорудить на SRTP:
https://github.com/Microsoft/visualfsharp/pull/3582
2. Тайпклассы появятся в C# вместе с соответствующими изменениями в CLR, а в F# навернут интероп.GoogleFriedrich19.09.2017
14:57:58
14:57:58
Не факт, что в CLR в итоге всё-таки потянут изменения. Могут решить там локально у себя в C#.
Сам понимаешь, разговоры идут разные, и прототипы даже для C# тоже есть разные.
Evgeniy19.09.2017
14:58:44
14:58:44
Не факт, что в CLR в итоге всё-таки потянут изменения. Могут решить там локально у себя в C#.
Default interfaces показывают, что они настроены решительно в отношении изменений в CLR.Friedrich19.09.2017
14:58:45
14:58:45
Раньше Мэдс говорил, что изменений в CLR не будет, а сейчас вот говорит что будут. Это не окончательно всё.
Aleksey19.09.2017
14:59:14
14:59:14
окэмловы (точнее SML-евы) модули что-то похожее позволяют выразить - завязываемся на сигнатуру модуля и имеем нужное поведение и при этом полиморфизм
Friedrich19.09.2017
15:00:17
15:00:17
Default interfaces показывают, что они настроены решительно в отношении изменений в CLR.
Начиная примерно с Roslyn (т.е. с C# 6) в каждую версию C# обещают добавить фичи, которые потребуют минорных изменений CLR. И каждый раз этих изменений не вносят. Я не исключаю, что в этот раз получится так же. Оцениваю вероятность, что C# 8 будет работать только на CLR 5, ниже 50%.Ну и не забывай про F#. Мне кажется, ты забываешь про F# (иронично, а?)
Vasily19.09.2017
15:01:23
15:01:23
Ну в F# в целом можно написать свои тайп-классы, используя констрейнты, по идее
Evgeniy19.09.2017
15:01:31
15:01:31
Vasily19.09.2017
15:01:31
15:01:31
Даже в текущей реализации
Friedrich19.09.2017
15:01:38
15:01:38
F# 5 (?) тоже должен будет как-то работать на предыдущих рантаймах. Если у нас будет core-фича, которая опирается на изменения CLR, то вообще нифига непонятно, что будет с нашими инициативами на Mono, на .NET Native, на всём вот этом.
Evgeniy19.09.2017
15:02:15
15:02:15
Aleksey19.09.2017
15:02:35
15:02:35
Простой ограниченный параметрический полиморфизм можно накостылять разными способами. Но этого мало
Evgeniy19.09.2017
15:02:45
15:02:45
А в чем отличия?
Ты можешь это делать только для своего кода. У тебя не получится расширить чужие типы, без доступа к их реализации и перекомпиляции.В этом же суть тайпклассов.
Vasily19.09.2017
15:03:17
15:03:17
Они же имплиситы, шоле?
Friedrich19.09.2017
15:03:22
15:03:22
Ну в F# в целом можно написать свои тайп-классы, используя констрейнты, по идее
Неа, нельзя. Есть существенные ограничения.
Тайпкласс я могу реализовать для чужого типа. Например, для System.Int32.
Систему из констрейнтов я не смогу реализовать для чужого типа. Потому что SRTP «не видят» методов раширения, которые я в чужие типы добавляю.Vasily19.09.2017
15:03:54
15:03:54
Тогда я недопонимаю, что же все таки такое тайпклассы
Friedrich19.09.2017
15:03:56
15:03:56
Ну, это сегодня такая ситуация. Есть прототипы, которые грозятся это поменять. Если всё сложится очень хорошо, то, может, будет даже в 4.2.
Открыть в Telegram