Например?

Вакансии по f#?

Зачем тебе мертвый чат?

Доброе утро. Никто не знает чатов по машинному обучению? Буду рад ссылке или любой информации) с Гуглом что то не повезло)

Тут подборка чатов по всеразличным темам (не знаю, находил уже сам или нет): https://github.com/goq/telegram-list

Но по машинному обучению и т.п. там мало чатов

Тут подборка чатов по всеразличным темам (не знаю, находил уже сам или нет): https://github.com/goq/telegram-list

ML как и F# , не так уж и развит )) даже совета толком спросить не у кого )

Там вроде turp <- struct (0,0)

ML как и F# , не так уж и развит )) даже совета толком спросить не у кого )

Есть чат по ризонмл

Он же по окамл

Там вроде turp <- struct (0,0)

Благодарю ?

ML как и F# , не так уж и развит )) даже совета толком спросить не у кого )

Есть русскоязычный слак OpenDataScience, 12к человеков.

Сеттер, брр.

ML как и F# , не так уж и развит )) даже совета толком спросить не у кого )

Ну не знаю. Говорят-то о нём все при любом удобном случае

Сеттер, брр.

А можно без них писать код для UI?

А можно без них писать код для UI?

В F# есть нормальные свойства.

Доброе утро. Никто не знает чатов по машинному обучению? Буду рад ссылке или любой информации) с Гуглом что то не повезло)

http://goo.gl/abmjom

В F# есть нормальные свойства.

В смысле?

А можно без них писать код для UI?

А зачем? Если это и есть нормальный способ для f#?

В смысле?

В смысле как в C#.

https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/members/properties

Вообще там val, так что эта штука уже доступна публично.

В смысле как в C#.

А, вы об этом. Ну тут как-бы на вход 1 число, а сетерить его нужно в турплу

А можно без них писать код для UI?

Зависит. Когда-то давно я писал UI для CAD на C#. И в какой-то момент переход к иммутабельным структурам здорово упростил мне жизнь.

С тех пор, правда, я UI не пишу. Но в иммутабельность уверовал. :)

С тех пор, правда, я UI не пишу. Но в иммутабельность уверовал. :)

У нас немного разные задачи по UI. Конечно, можно перелинковывать для DataSource каждый раз новую ViewModel, но допустим, у нас есть события, обработчики которых тоже нужно переносить в пересознанный "рекорд", как тогда организовывать код (того же извлечения обработчиков, это похоже на большее извращение, чем мутабельность, если нет - поправьте)?

Может быть проблема во мне (например, не знаком с React, где, возможно, всё на лету через иммутаблы обновляется, кажется его потому и советуют)

У нас немного разные задачи по UI. Конечно, можно перелинковывать для DataSource каждый раз новую ViewModel, но допустим, у нас есть события, обработчики которых тоже нужно переносить в пересознанный "рекорд", как тогда организовывать код (того же извлечения обработчиков, это похоже на большее извращение, чем мутабельность, если нет - поправьте)?

Поэтому я и написал "зависит". Наверное, сейчас бы я просто старался по возможности уменьшить количество мелких мутабельных объектов. Или можно попробовать перейти на некоторую "правильную" функциональную архитектуру, типа Elmish. Но это поле непаханное. :)

@yerumaku А ты читал статьи Reed Copsey про WPF в F#?

Это серия из трех статей с простеньким примером, которые эволюционирует каждый год. :) - http://reedcopsey.com/2015/12/09/christmas-trees-in-wpf-using-fsharp-viewmodule/ - http://reedcopsey.com/2016/12/15/christmas-trees-in-wpf-2016-edition/ - http://reedcopsey.com/2017/12/14/christmas-trees-in-wpf-2017-update/

@yerumaku А ты читал статьи Reed Copsey про WPF в F#?

Написано интересно, но как работает Gjallarhorn не понятно (словно смотрю на айсберг), поиск по слову mutable вообще не даёт представления где там куча. Ещё бы найти кого-нить, кто его применил в реальном приложении и каков профит в скорости для сравнения. https://github.com/ReedCopsey/Gjallarhorn.Bindable

Может быть проблема во мне (например, не знаком с React, где, возможно, всё на лету через иммутаблы обновляется, кажется его потому и советуют)

Не надо React, кстати, возьми Elm. :)

http://goo.gl/abmjom

Спасибо. Оставил данные.

Спасибо. Оставил данные.

Через денек-другой аппрувнуть должны.

Может быть проблема во мне (например, не знаком с React, где, возможно, всё на лету через иммутаблы обновляется, кажется его потому и советуют)

не надо elm, возьми elmish

не надо elm, возьми elmish

Как не надо? Надо! Эталонная реализация, чистота, не нужно возиться с JS инфраструктурой.

Для изучения подхода самое то. :)

ну ели эль рассматривать как фп-basic то ладно

Не надо React, кстати, возьми Elm. :)

Пока не вижу нужны, если внутри модели будет 1 рекорд мутабл

попробуй blazor

https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-started-building-net-web-apps-in-the-browser-with-blazor/

https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-started-building-net-web-apps-in-the-browser-with-blazor/

У меня клиент на мобилке, если вы это мне.

для html пойдет

а elm уж извините но давно не развивается, не вижу там перспективы

его двигает 1 чел

а elm уж извините но давно не развивается, не вижу там перспективы

Блин, ну, не Blazor же в качестве альтернативы рассматривать. :)

blazor-y до продакшна как до луны еще)

у эльма тоже самое)

формально

Elm уже в продакшене, Fable+Elmish тоже есть немного.

https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-started-building-net-web-apps-in-the-browser-with-blazor/

тогда надо смотреть на Xamarin.Elm

у blazor хорошее будущее пока изучать)

пора..

тогда надо смотреть на Xamarin.Elm

Xamarin.Elmish

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

у blazor хорошее будущее пока изучать)

немного не о том, учить надо и все такое, но задачу надо решить сейчас)

Xamarin.Elmish

да, спасибо

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

Можно. https://github.com/panesofglass/blazorapp

Но хочется ли писать UI на C#/Razor? :)

Но хочется ли писать UI на C#/Razor? :)

божечки упаситечки

к тому же я так понимаю это свежее слово во фронте уже с учетом опыта реакта и всего прочего современного

почем же нет? посмотрите как элементарно написать типа todo app

к тому же я так понимаю это свежее слово во фронте уже с учетом опыта реакта и всего прочего современного

Оно должно пройти естественный отбор

к тому же это уже webassembly

это вообще крутяк)

почем же нет? посмотрите как элементарно написать типа todo app

ХеллоуАпп не показатель!

долой JS

Но хочется ли писать UI на C#/Razor? :)

да, почему нет

да, почему нет

Ок, я не настаиваю. :)

я вот тоже так думаю что будет очень круто. razor для фронта!

Главное - дотнет для фронта. Уже не JS

к тому же майкрософт решила похоже эту тему поддержать

к тому же я так понимаю это свежее слово во фронте уже с учетом опыта реакта и всего прочего современного

Из примера пока не видно, что хорошего из современного переняли.

F# в Razor бы

и сейчас в razor не фшарп

Из примера пока не видно, что хорошего из современного переняли.

в blazor?

долой JS

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

в blazor?

Да.

Да.

компонентный подход ангуляра 2, из того что я знаю

ну компоненты и прочее. все сразу заложено и пока все просто

Единственное, с чем не поспоришь, что Blazor — это действительно будущее .NET во фронте.

значит надо учить

@angmarr Присоединяйся к дискуссии.

значит надо учить

Совсем не обязательно.

значит надо учить

раньше Q3 2019 беты скорее всего не будет))

@angmarr Присоединяйся к дискуссии.

К какой? (я тут выпал из контекста) Сейчас пытаюсь завести react + reagent + clojure ?

К какой? (я тут выпал из контекста) Сейчас пытаюсь завести react + reagent + clojure ?

За Blazor трём.

Единственное, с чем не поспоришь, что Blazor — это действительно будущее .NET во фронте.

и там так или иначе придется писать на C# клиентское приложение, потому что никто не собирается делать разор для F# (как и текущий)

Да, я понял.

сейчас там темплейт из 3 проектов - клиентское (фронт), сервер - обычное асп нет кор приложение и отдельный проект с бизнес-логикой (как я понял)

по-идее никто не мешает последние 2 на фшарпе писать

можно будет типа иметь общую объектную модель для бэка и фронта

короче я inspired)

За Blazor трём.

Хм, тогда мне нечего добавить (я же мобильный девелопер) ? кроме того что я за SAFE

А мне не очень нравится.

почему?

Инжектированный стейт, который размазывается про компонентам сложно держать в голове.

мне кажется еще рано об этом говорить пока мало примеров кода

к тому же они только начали еще могут все переделать