SB
Size: a a a
2021 January 27
AT
и это не нужно, чтобы писать чистый функциональный код :)
Ɖ
с того что когда я пишу про фарш у меня в конторе, там "архитектор" пишет - у нас тут бизнес, а экспериментальными поделиями балуйся в свободное время. А если еще и статью эту увидит, то ссылку на нее кинет
Оскорбление чувств фшарперов
SB
и это не нужно, чтобы писать чистый функциональный код :)
вот тут уже не знаю, спорно
Ɖ
Да не нужно это для нормального вкатывания в функциональщину подростку, только оттолкнет.
А ему в целом функциональщина то сильно нужна в 14 лет?)
AT
А ему в целом функциональщина то сильно нужна в 14 лет?)
Пусть лучше функциональщина, а не ассемблер как у меня :) Да и дальше проще будет, если окончательно пойдет по пути разработки(кто его знает, может еще чем нибудь увлечется)
VS
так давайте уже не оффтопить что-ли
S
Тогда нужно было писать что кроме того что фшарп это уже как десять лет не эскпериментальный язык, огромное количество компаний юзают его в проде, а фичей крутых там настолько много что некоторые тянут другие языки такие как сишарп, джаваскрипт и скала. Тогда бы я такую статью на работе пошарил)
done
VS
done
спасибо)
Ɖ
Пусть лучше функциональщина, а не ассемблер как у меня :) Да и дальше проще будет, если окончательно пойдет по пути разработки(кто его знает, может еще чем нибудь увлечется)
Из крайности в крайность
AT
Из крайности в крайность
Почему крайность ? И ООП и функциональщина вместе изучаются, одновременно.
AT
Причем без противопоставления, как вполне содружественные подходы при разработке, просто в разных местах проекта
AT
Как по мне диаметрально противоположные области
Холиварная тема, но я считаю что это не так. Точнее-ничто не мешает в рамках одного проекта мешать оба подхода, получая максимум от использования каждого. Простой пример-паттерн стратегия, что в потрохах реализовано чисто функционально. Проект состоит из простой плоской иерархии разных стратегий(типа такой-то интерфейс с таким-то передаваемым контекстом), каждая из которых применяется для той или иной обработки данных по конвееру, а внутри стратегии можно писать хоть императивно, хоть функционально.
I
Холиварная тема, но я считаю что это не так. Точнее-ничто не мешает в рамках одного проекта мешать оба подхода, получая максимум от использования каждого. Простой пример-паттерн стратегия, что в потрохах реализовано чисто функционально. Проект состоит из простой плоской иерархии разных стратегий(типа такой-то интерфейс с таким-то передаваемым контекстом), каждая из которых применяется для той или иной обработки данных по конвееру, а внутри стратегии можно писать хоть императивно, хоть функционально.
Не стесняйся @fsharp_flood а то у меня вопросы еще остались)