Но аннотации это ужасно

Страшненькие? :)

попахивает джавой @NotNull

Прототип тайпклассов для F# тоже с аннотациями.

Ну, и всякие [<Struct>].

Страшненькие? :)

Аоп вносит неясность

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

т.е. это как AggresiveInlining

на код никак не сказывается

т.е. это как AggresiveInlining

вот с рекордами ок, я не против. ПРосто Fable в итоге изучается как отдельный язык

Это в C# struct меняет поведение, т.к. там сразу появляется non null, поля инициализируются и прочая тема. Помимо аллокации на стеке

вот с рекордами ок, я не против. ПРосто Fable в итоге изучается как отдельный язык

Ну, как и bucklescript, например. Там тоже свои аннотации.

И типы нельзя переиспользовать, часто из-за аннотаций

Ну, как и bucklescript, например. Там тоже свои аннотации.

да и это пка грустно

Я вот считаю что C# в этом плане плоховат. Он смешивает бизнесовые, логические вещи (record types, non-nullability) с инфраструктурными (аллокация на стеке/в куче). Ну и эта фигня в F# проникает, да Понятно что сейчас разделять никто не будет, но видимо 20 лет назад это казалось хорошей идеей

Я вот считаю что C# в этом плане плоховат. Он смешивает бизнесовые, логические вещи (record types, non-nullability) с инфраструктурными (аллокация на стеке/в куче). Ну и эта фигня в F# проникает, да Понятно что сейчас разделять никто не будет, но видимо 20 лет назад это казалось хорошей идеей

А как разделять?

А как разделять?

ну логические вещи типа non-nullable/nullable ключевым словом например. Компилятор будет орать что ты не инициализировал все поля в Immutable классе, или ещё чо А способ аллокации так: 1) если аллоцируется через stackalloc -> на стаке 2) если есть заданная аннтоция, следуем ей 3) всё остальное по дефолту на куче

вот с рекордами ок, я не против. ПРосто Fable в итоге изучается как отдельный язык

Кажись скоро будет как в хаскеле, разные фичи-расширения языка под флажками

Кажись скоро будет как в хаскеле, разные фичи-расширения языка под флажками

Это печально, кстати

https://www.reddit.com/r/ProgrammerHumor/comments/8tlqo9/javascript_is_getting_real_tired_of_your_jokes/ "C# is a dull language for corporate schmucks. He takes advantage of his sister F# and then hides her in the basement."

да, тоже сегодня улыбноло это про C# ))

https://twitter.com/demystifyfp/status/1011229606379061248

HOPAC!!!1

HOPAC!!!1

no

танцуем, сегодня мы с тобой танцуем (гопак)

no

Там хорошая серия постов.

Там хорошая серия постов.

а юз кейсы для него какие?

Да и гопак в целом ничо. После унылых асинков, к которым даже map надо руками прикручивать так вообще огонь

https://www.reddit.com/r/ProgrammerHumor/comments/8tlqo9/javascript_is_getting_real_tired_of_your_jokes/ "C# is a dull language for corporate schmucks. He takes advantage of his sister F# and then hides her in the basement."

Ухахаха

а юз кейсы для него какие?

осенхронность.

haf вообще мечтал hopac дефолтной асинхронной либой в F# сделать. Но думаю не сложится у него с этим)

Joinads!!!!!

даже у них мало шансов по-моему

Мне понравился подход сам

А учитывая, что пейпер писали Петричек с Саймом, все ок

task

task

?

task

https://vaskir.blogspot.com/2015/01/parallel-reduce-hopac-vs-asyncs-vs-tasks.html

Ага.

Я лишь про то, что таск будет в стандартной либе.

А, эт да. Давно пора

Я лишь про то, что таск будет в стандартной либе.

прям будет? Это где такое сказано?

Я кстати толком понял как тасковая стейт машина работает отсюда https://github.com/rspeele/TaskBuilder.fs/blob/master/TaskBuilder.fs В C# сырцах там размазано по десятку классов с кучей воды. F# код хоть и не 100% повторяет, но мысль понять можно

прям будет? Это где такое сказано?

я где-то в пропозалах на гитхабе видел

прям будет? Это где такое сказано?

https://github.com/fsharp/fslang-suggestions/issues/581#issuecomment-344927068

https://github.com/fsharp/fslang-suggestions/issues/581#issuecomment-344927068

Thnx

Немного странный вопрос. Могу ли я объявить event.Publish в модуле с целью дальнейших Observable.subscribe?

Вопрос снимается, таки можно

Я вот понял что мне не нравится засовывать юнит в конструктор: Class(()) Выглядит ужасно. Что можно сделать?

Не засовывать его туда

Допустим. А если надо всё же присунуть, то?..

Зачем он там?

Сайд эффекты?

Ну всякие ситуации бывают. Мне надо соорудить в гопачке промиз, который всегда выполняется. что-то типа Alt.always, но промиз Promise() возвращает промиз который никогда не выполнится, это пустой промиз, ок А вот Promise(()) как раз то что надо

Promise 42 тоже всегда выполняется, но будет выглядит тупо

А зачем тебе такой промис?

Я почему вопросы такие задаю, потому что с трудом могу представить такую ситуацию

Когда это потребуется

У меня там такое в хранилище ищется файлик. Если он есть, то его выкачиваем, мемоизим (переиспользуется, поэтому промиз). Если его нет, запускаем тяжкую логику его сборки, сайд эффектом (который надо ОБЯЗАТЕЛЬНО дождаться) заливаем в хранилище. соответственно остальная часть логики принимает два промиза - промиз на файлик (он будет выкачан из хранилища, или собран заново) и промиз сайд эффекта (это тот самый Promise(()) ), т.к. мы можем очень быстро закончить программу, а заливки надо дождаться асинхронно. Промиз на сайд эффект тут затем чтобы два раза заливка не пошла

Надеюсь понятно объяснил

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

Что мешает написать две функции аплода и передавать в промиз одну из них?

Оборачивать функцию в промиз это слишком ФП, ща попробую обмыслить

Промиз скорее про способ исполнения кода, чем про воркфлоу,кмк

Ну и неясно, почему аплоад сайд эффектом

И нельзя ли завернуть в промиз функцию аплода, которая как раз проверяет мемоизацию и подгружает файл, если надо

В гопачке промиз - это способ мемоизить джобы, которые как и F# асинки являются генераторами, т.е. будут каждый раз заново запускаться. А у меня тяжёлый IO, который не хочется гонять два раза если двум функциям понадобятся одни и те же данные.

Дык разрули его внутри функции

Я понимаю, типа разбиндить промиз в нормальную переменную, но всё не так просто когда у тебя десятки этих промизов)))

проще не разворачивать

Не поверишь, нашёл применение аппликативному функтору в продакшн коде Всё через промизы/джобы. Пишешь обычные функции (без промизов и джобов). Через инфиксный apply закидываешь промизы в функцию (как в nodeJs)

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

Ну и неясно, почему аплоад сайд эффектом

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

А,два разных потока событий

Типа waitall?

Типа да

Ну просто не добавляй промис загрузки, если нет необходимости

Или оно так не работает?

Т.е. основной кусок кода такой - получи как нибудь важные данные (из хранилища или собери заново) -> (если получены заново, начинай заливать в хранилище, но асинхронно) -> используй важные данные и собери ещё более важные данные -> убедись что залит как основной результат, так и запущенный (возможно) ранее

Ну просто не добавляй промис загрузки, если нет необходимости

Возвращаясь к изначальному вопросу. Если заливка не требуется, я для промиза заливки создаю Promise(()), который нифига не делает)

и вот мне не нравится синтаксис!

Зачем создавать, когда можно не создавать!

А по вопросу

let p f = Promise(f)

Зачем создавать, когда можно не создавать!

Если у меня есть условный if который делит контрол-флоу на части (надо собирать заново и заливать) и (не надо собирать заново), то если я в первом куске кода запускаю джоб и не получу какой-нибудь хендл на него (ну типа таск/асинк/ и т.п), то в конце программы я не смогу его повейтить чтобы убедиться что он залился. Он просто может очень долго заливаться, дольше чем остальная программа выполняется, соответственно тред умрёт и заливка сдохнет

Ну выглядит странно, если честно

т.е. условные оба бранча этого ифа должны возвращать какой-то хендл на заливку

или полный или заглушку.

Тааак

Бля, нарисовал)

Так вот

В нижней ветке квадратик лишний

там один квадратик :D

и прям он лишний?

Просто т.к. это F#, то типы верхей и нижней ветки должны сходиться. В данном случае в крайний правый терминирующий квадратик должно прилетать одинаковое что сверху, что снизу

Массив состояний ожидания

Все, пошёл тренироваться

ООПешечкой пахнуло :D