Привет всем. Я только не давно стал приглядываться к F#, прочитал несколько статей, но не могу понять одной важной штуки.
У меня сложилось впечатление, что в F# при решении любых задач сама суть решения задвинута в самый конец алгоритма, стоит позади ВСЕХ мелких обобщенных частностей. Чтобы понять, ЧТО делает функция, необходимо смотреть на неё сзади), потому что впереди будет всякий вспомогательный хлам, который не даёт понимания назначения этой функции. Мне кажется, такая "математичность" не полезна при решении любых конкретных проблем, так как не позволяет СПЕРВА разбить большую задачу на подзадачи, решение которых можно описать ПОТОМ. Поэтому не покидает ощущение, что я неправильно понимаю F#.  Но чего именно я не понимаю?)

Привет. Тоже погружаюсь в F# параллельно разработке. Интересен ряд более-менее актуальных вопросов:
- Как реализуется DI. Например, если в C# требуется импорт интерфейса с набором методов/свойств - как в F#?
- В F# есть алгебраические типы и discriminated unions. Сейчас при построении архитектуры на базе CQRS получается очень объемное описание (DTO + Commands + Domain models). Как это выглядит при написании API на F#?
- Часто приходится использовать маппинг, например AutoMapper. Как с этим?

я обязательно почитаю и посмотрю всё, что мне посоветовали.
просто сейчас я могу сказать, что
1) "циклические зависимости" никогда не были моей проблемой в C#. возможно, что я их бессознательно избегал и мне было пофик на них.  возможно я знаю их под другим названием, но на ум ничего не приходит.
2) "суть позади деталей" - это антиметод решения задач в принципе. если f# не позволяет решать задачу в традиционном порядке (сначала - важное, а потом - мелочи), то имхо это большой косяк.

я лишь хочу научится решать задачи по принципу "от сути к мелочам" с помощью F#.
Народ, возможно считает, что я флудю, но для меня это действительно важно)

За сим, разрешите откланяться) Всем спасибо за советы. Когда почитаю статьи, тогда вернусь)

Эфшарп позволяет делать все, просто у нас есть некоторое количество одержимых зилотов, и как всегда от них больше шума, чем от нормальных людей. На фоне общей скудности материала может сложиться мнение, что других подходов нет и что надо делать только так и не иначе, причем в полном объеме. Не обращай на это внимание, вся экосистема только формируется. Мнемонически можно считать, что проектирование в эфшарпе (и фп в целом) соответствует началу 90х в мейнстриме

я уже почти верю, что f# может сделать всё, что мне на самом деле нужно, потому-то и спросил совета в этом чате
но я всё еще не знаю, как узнать КАК ЭТО СДЕЛАТЬ)
очевидно, мне ещё нужно во многое вникнуть, чтобы найти оптимальный подход к решению задач в F#...

я уже почти верю, что f# может сделать всё, что мне на самом деле нужно, потому-то и спросил совета в этом чате
но я всё еще не знаю, как узнать КАК ЭТО СДЕЛАТЬ)
очевидно, мне ещё нужно во многое вникнуть, чтобы найти оптимальный подход к решению задач в F#...

советую вот эту книгу https://www.oreilly.com/library/view/domain-modeling-made/9781680505481/ даст пищу для размышлений

советую вот эту книгу https://www.oreilly.com/library/view/domain-modeling-made/9781680505481/ даст пищу для размышлений

Зачем вы ее советуете? Риторический вопрос

эээ, а что с этой книгой не так? её нельзя советовать?

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

Не то, чтоб ее не стоило прочесть, но использовать ее в качестве примера «как правильно» явно не надо. И уж точно не начинающим

так а что лучше то? я ровно теми же самыми вопросами задавался