Что я делаю не так? :(

Смотря что у тебя за код)

Я вчера был на, возможно, самой хуевой презентации F#. В офисе майкрософта

Т.е. просто подтвердил всеобщий миф :(

Интересно, зачем такое?

Чувак за час рассказал, что "главная фишка F# это оператор |>", немного про паршал аппликейшн (не рассказывая про карринг), про отсутствие скобочек вокруг аргументов, и все это на примерах решения каких-то примитивных математических задачек

про систему типов ВООБЩЕ ни слова не было)

про систему типов ВООБЩЕ ни слова не было)

Фамилия у этого человека есть?

ты расправу учинить хочешь?)

про систему типов ВООБЩЕ ни слова не было)

оно ? https://github.com/ChangHaiBin/FSharpTalk/blob/master/FSharp%20Talk.pdf

Чувак за час рассказал, что "главная фишка F# это оператор |>", немного про паршал аппликейшн (не рассказывая про карринг), про отсутствие скобочек вокруг аргументов, и все это на примерах решения каких-то примитивных математических задачек

Надо мной в очередной раз поржали на отборе докладов на локальную конференцию - «опять этот со своим ф#». Но я там много лет волонтирю - поэтому в расписание засовывают :)

У меня на всех работах начиная с 8летней давности прозвище "Рома F#"

Ну, чувак некомпетентный, очевидно. У него много косяков в докладе было, он даже не смог нормально объяснить, зачем скобки в выражении g (f a), если по его же словам, скобки в фшарпе не нужны. Зачем его пригласили, я не знаю. В конце концов, это была не конференция, а митап в офисе МС. Как так вышло и кому это надо было, я не знаю, к сожалению. Но горело у меня не меньше вашего, пока я там сидел.

я, наверное, уже всех им заебал

Я его понимаю. Будь пайпы в с# мне было бы гораздо легче на нем писать, но просто так пайпы не сделать. Это раскручивает на партиал аппликейшн и автокарринг и т.д. и т.п. иначе пайпами пользоваться будет неудобно.

Формат митапа не подразумевал возможности дополнить его рассказ?

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

Я вот чую, что можно как-то нормально управлять зависимостями без этих безумных DI фреймворков. У меня уже есть хороший пример, во что использование DI может превратиться в C# на сложном проекте, но нет нормального примера на F#

https://github.com/gothinkster/realworld

мой поинт про то, что ООП (то, что под ним сейчас понимают в мире C# & Java) не предназначено для тех целей, для которых их используют. Подразумевается, что объект — хранилище каких-то характеристик и состояния, с пачкой методов для управления этим делом. А сейчас самый популярные объекты в реальном проекте — сервис и репозиторий. Какие там характеристики и состояния? Они не должны быть объектами, они должны быть модулями с функциями, которые принимают конфигурационные настройки в качестве аргументов, а не как поля класса хранить коннекшн к базе и ссылки на другие сервисы/репозитории

мой поинт про то, что ООП (то, что под ним сейчас понимают в мире C# & Java) не предназначено для тех целей, для которых их используют. Подразумевается, что объект — хранилище каких-то характеристик и состояния, с пачкой методов для управления этим делом. А сейчас самый популярные объекты в реальном проекте — сервис и репозиторий. Какие там характеристики и состояния? Они не должны быть объектами, они должны быть модулями с функциями, которые принимают конфигурационные настройки в качестве аргументов, а не как поля класса хранить коннекшн к базе и ссылки на другие сервисы/репозитории

почему неудобно?

ну DI тоже неудобно, когда это разрастается в сервис локаторы, всплывают странные баги с life time scope, когда навигация по коду больше не работает, пушто где-то в миллионах экстеншн методов регистрируется то, что тебе нужно, но пока ты не прочтешь весь код, ты этого не узнаешь