Ну меньше строк - я согласен что в фш многие вещи куда выразительнее. Вопрос то не в этом, а в функциональщине в целом. Просто ф#/с# сравнивать легче

Ну в целом я понял тезис о не поиске перформанса в функциональщине, спасибо за реплики:)

иной подход к решению кмк

иной подход к решению кмк

Тут я согласен практически со всем. Просто как я подойду к менеджеру со словами «а давайте всё/часть перепишем на ф#, правда работать будет /чуть/ медленнее»...

Нет :)

если C# переписывать на Ф# - медленнее не будет

Наоборот - очень много багов будет поймано на компиляции ещё

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

если C# переписывать на Ф# - медленнее не будет

Есть ли пример, когда на ф# что-то заимплеменчено эффективнее с т з перформанса?

Пример - есть DTO класс с моделькой, которую в жсончик обернём :)))) и отдадим клиенту

добавили поле

или лучше 10

Есть ли пример, когда на ф# что-то заимплеменчено эффективнее с т з перформанса?

Эффективнее с точки зрения кода

а инициализировать 1 забыли.

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

Ага, поэтому приходится писать в ОО стиле с элементами функциональщины, а не наоборот:(

ф# - пошлёт - скажет на всё проинициализиролвано

Ага, поэтому приходится писать в ОО стиле с элементами функциональщины, а не наоборот:(

такова селявя

а инициализировать 1 забыли.

Ну для того же есть явные конструкторы...

когда их 5 - запросто

а когда 25?

заимешься их перегенерять каждый раз

ни и перегенерить - тоже можно забьыть

Ну тут конечно у меня вылезают вопросы к дизайнеру, но механизм тот же, раз требования таковы...

и компилятор ничего тебе не скажет

Ну тут конечно у меня вылезают вопросы к дизайнеру, но механизм тот же, раз требования таковы...

дизайн простой - MVVM

и компилятор ничего тебе не скажет

Ну явно определённые конструкторы как раз для того, чтоб на стадии компиляции явно сказать , что именно нужно для построения данного объекта

но компилятор не энфорсит

но компилятор не энфорсит

Не понял мысль

Не понял мысль

добавил поле, оставил прежний конструктор - всё компилируется

добавил поле, оставил прежний конструктор - всё компилируется

Ну и сам себе злобный буратино

Ну явно определённые конструкторы как раз для того, чтоб на стадии компиляции явно сказать , что именно нужно для построения данного объекта

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

Ну и сам себе злобный буратино

я это о пользе ф#

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

которую можно скрывать!

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

Ну мы для начала забыли про опен-клосд принципе, как средстве не попасть по конечностям...

это модель

которую можно скрывать!

Я бы сказал нужно

я это о пользе ф#

Мы говорим об ф# как об отдельном языке или как о функциональщине?

причём тут опен-клозе?

Тут я согласен практически со всем. Просто как я подойду к менеджеру со словами «а давайте всё/часть перепишем на ф#, правда работать будет /чуть/ медленнее»...

^^^

это модель

Тем не менее, нам же нужно соблюдать принцип закрытости к изменениям и открытости к дополнениям

ты свою оопешную софистику тут не разводи!

предлагаешь на каждое изменение модели уровень иерархии что ли добавлять???

Я бы сказал нужно

Доктол к вам мона? Нуна! :)

Я этого не говорил, я говорил о том, что к ООП в целом относится солид, который как раз помогает избежать многих проблем с читаемостью/сопровождением. И вопрос в том, что есть ли в ф# нечто, чисто функциональное, что позволяет обойти проги на с# по конечному перформансу, вот и всё:)

пока ты будешь думать над солидом 3 дня, я запилю 3 функции которые уже будут на следующий день в продакшене :)

вот тебе и перформанс

пока ты будешь думать над солидом 3 дня, я запилю 3 функции которые уже будут на следующий день в продакшене :)

Переход на личности:( ладно, тема закрыта, ты прав

не - это не переход на личности, это я к примеру :)

И у меня естт опыт такой

когда весь дизайн - это ДТО классы без методов

не - это не переход на личности, это я к примеру :)

Это как раз переход на личности. Я говорю о конечном выходе - ты о скорости разработки

И у меня естт опыт такой

Да, я верю в то, что ты уже писал программы на ф# быстрее чем я «возился с солимом»

каждому овощу - свой фрукт. Если тебе нужен сферический перформанс - надо брать ц++

когда весь дизайн - это ДТО классы без методов

Это я вообще не понял к чему

Это я вообще не понял к чему

это я начал приводить пример - и бросил :)

ДТО классы + статичные методы для их обработки

фп на C# для бедных

это я начал приводить пример - и бросил :)

Ну в меня во всех практически проектах с нуля объекты либо дто, либо то что я в DI регаю как синглтон, что с того?

тогда зачем тебе ооп?

ДТО классы + статичные методы для их обработки

Ну пусть так, это никаким принципам ООП не противоречит

состояние в синглтонах хранить?

тогда зачем тебе ооп?

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

состояние в синглтонах хранить?

Состояния я в синглтонах не храню

а то в ф# ты не можешь? :)))

https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual/array.sortinplace%5B't%5D-function-%5Bfsharp%5D

а то в ф# ты не можешь? :)))

Если речь об изменении переменных - я говорил о функциональщине. Иначе это просто «функциональщина местами»

Ну пусть так, это никаким принципам ООП не противоречит

солиду - противоречит

солиду - противоречит

Каким образом?

сингл респонсибилити - лесом

https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual/array.sortinplace%5B't%5D-function-%5Bfsharp%5D

Ну отлично, у нас появляются переменные. Сдаётся мне, что с использованием ф# превращается в сишарп где «не нужно писать открывающие/закрывающие скобки» и прочими плюшками

сингл респонсибилити - лесом

Каким образом? Где вылезает вторая ответственность?

Если речь об изменении переменных - я говорил о функциональщине. Иначе это просто «функциональщина местами»

ты же не собираешься с# на хаскель переписывать? что тогда не принять фичи ф# как данность?

Ну отлично, у нас появляются переменные. Сдаётся мне, что с использованием ф# превращается в сишарп где «не нужно писать открывающие/закрывающие скобки» и прочими плюшками

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

ты же не собираешься с# на хаскель переписывать? что тогда не принять фичи ф# как данность?

Фичи ф# прекрасны. Но при таком подходе они просто становятся фичами, и принципиального нового не привносят

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

Делая шаг назад, отказываясь от фп

Каким образом? Где вылезает вторая ответственность?

она вылазит по количеству статичных методов

Делая шаг назад, отказываясь от фп

это не приекрасно ли?!

она вылазит по количеству статичных методов

А никто не заставляет херачить их в один класс

А никто не заставляет херачить их в один класс

тогда получится по одной в классе :)

это не приекрасно ли?!

Это просто в чистом виде «если нужен перформанс - отказывайтесь от фп», что и есть прямой ответ на мой самый первый вопрос. И если продакшн критичен к перформансу - лучше сразу забыть о фп, чтоб не переписывать лишний раз

тогда получится по одной в классе :)

Ну и? Мне вот не жалко. У меня оплата от количества классов в коде не зависит:)

у меня тоже, но поддерживать такое - адъ

у меня тоже, но поддерживать такое - адъ

Почему?

По мне так пусть будут два небольших класса, которые каждый отвечают за своё. Чем когда они спаяны в одну кучу

чем меньше "классов", тем проще ориентироваться в проекте

чем меньше "классов", тем проще ориентироваться в проекте

Ну бахнуть тогда всё в один класс

ну, зачем же :)

нужно искать компромисс

ну, зачем же :)

Ну чем меньше) меньше одного ноль:) а это уже фп, удар по перформансу - меньше одного никак

нужно искать компромисс

Дык в чем компромисс, если чем меньше тем лучше?

нет :)

Ну окей. Я опять же повторюсь, что рассуждал о теории. В целом на свои вопросы я ответы получил, за что спасибо)

Дык в чем компромисс, если чем меньше тем лучше?

Компромисс между количеством и качеством :)

Компромисс между количеством и качеством :)

Ну т.е. Чем меньше классов, тем ниже качество?О_о

ну хорош уже придуриваться. 0 классов и все методы в одном классе, это 2 крайности, которые мы не рассматриваем. А далее рубить можно по-разному. Можно добавить ещё по методу на класс.