И это уже всё пора во флудилку переносить :)

только я не умею. Утром придут знающие - почистят :)

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

Вот я честно пытаюсь разобраться. Без дураков. Мой тезис бы такой, что на каждый дто по одному классу и каждый статический метод, отвечающий за обработку дто (по факту - трансформацию в другой дто, а ещё точнее создание нового дто на основе предыдущего). Исключение это всякий стафф, вроде контроллеров (где гетры и посты в одном классе, тут тяжело повлиять) энтити фреймворковских контекстов и подобного 3рд пати. Ответ был что так классов слишком много (и к слову чем меньше тем лучше). И возникает тогда резонный вопрос, как определить-то, сколько нужно?

В моём тезисе была простота , новый функционал - новый класс, и его можно легко заинжектить куда нужно

Вот я честно пытаюсь разобраться. Без дураков. Мой тезис бы такой, что на каждый дто по одному классу и каждый статический метод, отвечающий за обработку дто (по факту - трансформацию в другой дто, а ещё точнее создание нового дто на основе предыдущего). Исключение это всякий стафф, вроде контроллеров (где гетры и посты в одном классе, тут тяжело повлиять) энтити фреймворковских контекстов и подобного 3рд пати. Ответ был что так классов слишком много (и к слову чем меньше тем лучше). И возникает тогда резонный вопрос, как определить-то, сколько нужно?

Фции можно группировать как угодно. судя по ф# либам - часто по типу входа/выхода. Но в прикладном плане это не всегда удобно. Поэтому... хз. Я группирую по области прикладной.

Надо файлик определенного вида обработать - всё там, вне зависимости от входов/выходов. Иного вида файлик - иной модуль с ф-циями.

и, кстати, тот пример с C# так же рубился

но это не С в солиде. С - это внутри одной ф-ции :)

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

счастливо :)

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

Так не говори, ты так слона никогда не продашь. Даже в нагруженном сервисе тебе перфоманс как правило нужен в очень ограниченном кол-ве мест, и там иногда приходится сильно уродовать код даже на сишарпе (можно почитать, какие хаки со структурами сделали Stackoverflow для своего тэг сервера). Но фп это не про перфоманс. Это стабильный код, который еще и пишется быстрее. При должном навыке при прочих равных ты будешь выкатывать более стабильные фичи быстрее, чем на сишарпе. Ну, во всяком случае, я так думаю.

Так не говори, ты так слона никогда не продашь. Даже в нагруженном сервисе тебе перфоманс как правило нужен в очень ограниченном кол-ве мест, и там иногда приходится сильно уродовать код даже на сишарпе (можно почитать, какие хаки со структурами сделали Stackoverflow для своего тэг сервера). Но фп это не про перфоманс. Это стабильный код, который еще и пишется быстрее. При должном навыке при прочих равных ты будешь выкатывать более стабильные фичи быстрее, чем на сишарпе. Ну, во всяком случае, я так думаю.

Мне в ответ на такое написали, что я «перехожу на личности» :(

Так не говори, ты так слона никогда не продашь. Даже в нагруженном сервисе тебе перфоманс как правило нужен в очень ограниченном кол-ве мест, и там иногда приходится сильно уродовать код даже на сишарпе (можно почитать, какие хаки со структурами сделали Stackoverflow для своего тэг сервера). Но фп это не про перфоманс. Это стабильный код, который еще и пишется быстрее. При должном навыке при прочих равных ты будешь выкатывать более стабильные фичи быстрее, чем на сишарпе. Ну, во всяком случае, я так думаю.

Согласен.

Мне в ответ на такое написали, что я «перехожу на личности» :(

ну там формулировку можно двояко толковать, при желании) Бывает

ну там формулировку можно двояко толковать, при желании) Бывает

Всё, что будет вами сказано, может быть использовано против вас...

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

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/fsharpcore-csharpcore.html

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

Извини, но это конечно аргумент ужасный. Вы даже на числомолотилках едва заметите разницу. А я подозреваю вы не их пишете. Поэтому не заметите.

люди на однопоточном питоне пишут веб-сервисы, карл!

а вы тут меряете разницу в 2 инструкции от разных компиляторов которые всё одно в JIT попадут

это надо быть настолько не очень чтобы об этом думать

извини

Я думаю там главный вопрос был - быстрее ли работает программа на фп, можно было дать простой ответ, что не быстрее)

Я думаю там главный вопрос был - быстрее ли работает программа на фп, можно было дать простой ответ, что не быстрее)

Оптимизатор все уравняет

Почти)

Вот к слову гопак. Код написанный на гопаке - чистое фп. Унижает по скорости ооп поделие целой команды топовых программистов. Какой вывод можно сделать из этого кейса про скорость ФП вс ООП? Никаких

Вот к слову гопак. Код написанный на гопаке - чистое фп. Унижает по скорости ооп поделие целой команды топовых программистов. Какой вывод можно сделать из этого кейса про скорость ФП вс ООП? Никаких

о каком поделии идет речь?

о каком поделии идет речь?

async/await + TPL

спс

Я думаю там главный вопрос был - быстрее ли работает программа на фп, можно было дать простой ответ, что не быстрее)

Так из этого следует, что либо так же (медленно), либо ещё медленнее

Вот к слову гопак. Код написанный на гопаке - чистое фп. Унижает по скорости ооп поделие целой команды топовых программистов. Какой вывод можно сделать из этого кейса про скорость ФП вс ООП? Никаких

Куда же без него!

Чую, надо подосвоить :) но я ту простыню из асинксеков сделал женериком :))) просто и понятно :)))

Чую, надо подосвоить :) но я ту простыню из асинксеков сделал женериком :))) просто и понятно :)))

Его даже просто для общего развития полезно освоить

Его даже просто для общего развития полезно освоить

Я по твоему видосику идею кажется понял

Вот к слову гопак. Код написанный на гопаке - чистое фп. Унижает по скорости ооп поделие целой команды топовых программистов. Какой вывод можно сделать из этого кейса про скорость ФП вс ООП? Никаких

зато сам гопак это никак даже не ооп, а процедурное программироване с goto =) вопрос же не про либу, а наоборот, как такую либу написать чтобы было быстрее

зато сам гопак это никак даже не ооп, а процедурное программироване с goto =) вопрос же не про либу, а наоборот, как такую либу написать чтобы было быстрее

Гопак написан с использованием правильных абстракций - стейт машины (да, через goto), CPS (через трамплины), linked list для очереди работ (с подменой ссылки на голову для скорости), n:m кооперативный шедулер. При этом там много эээ ООП? - сабтайпинг IVar :> Alt :> Job по словам самого автора даёт нетривиальное ускорение чтобы не аллоцировать лишнего. Его делает быстрым не то что написан в каком-то конкретном стиле, а то что он написан пиздец как грамотно с применением всех стилей. И процедурное, и фп, и ооп

Автор страдал что по его прикидкам можно ускорить гопак ещё на 30%: https://github.com/Hopac/Hopac/blob/master/Docs/Internals.md#could-something-like-hopac-be-even-faster

Оки, принимается) Но все же тезис что чистое фп точно не быстрее остается в силе)

если что, текст по ссылке 3 года назад написан, так что может с текущими C# новшествами типа ref var может чо и можно сделать, но хз

Оки, принимается) Но все же тезис что чистое фп точно не быстрее остается в силе)

чистое ООП (или то что под ним понимается сейчас) так же будет умирать в перформансе AbstractFactoryOfFactories factoryForFactories = FactoryLocator.CreateFactoryFactory(new FactoryFactorySettings(...)); IProductFactory productFactory = factoryForFactories.CreateProductFactory(new ProductFactorySettings(...)); IProduct product = productFactory.CreateProduct(new ProductSettings(...)); ...

Я коненчо возвёл в абсолют, но мысль понятна.

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

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

Ну что ты начинаешь)))

нормально же общались!

))

чорт, надо спеку перечитать

Мне в ответ на такое написали, что я «перехожу на личности» :(

Нет, было сказано в ответ на другое

а вы тут меряете разницу в 2 инструкции от разных компиляторов которые всё одно в JIT попадут

Я про асимптотику же спрашивал, на кажется ниже разобрались..

Я про асимптотику же спрашивал, на кажется ниже разобрались..

LLVM придет, порядок наведёт)

LLVM придет, порядок наведёт)

Когда же?

Когда же?

Нескоро, но попытки уже есть https://dotnext-moscow.ru/2018/msk/talks/6qxwwyq5yqo2megee6swke/

LLVM же не починит асимптотику

И кто-то жаловался, что ML-подобное не очень с помощью LLVM компилить

LLVM же не починит асимптотику

Если ты про внезапно превращение O(n) в O(1), то я могу показать случай когда может! let veryLongFunction (seq: _ seq) = for item in seq do () //nothing 42 я утрирую

мне кажется даже наш доморощенный оптимизатор сможет превратить эту функцию из O(n) в константный возврат 42, но это не точно

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

А на какой стадии моно ллвм использует?

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

я не шарю, но возможно есть похожие кейсы

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

Ну в общем случае если алгоритм написан неоптимально (скажем, квадрат где можно n log n), то оптимизатор не поможет, каким бы он ни был умным

в каких-то частных случаях может и поймёт что-то

Ну в общем случае если алгоритм написан неоптимально (скажем, квадрат где можно n log n), то оптимизатор не поможет, каким бы он ни был умным

я тут недавно вопрос задавал. Меня в ступор поставил ionide или F# компилятор (не уверен): fun x -> fun y -> x y он предложил заменить на id Я неприлично долго одуплял почему это действительно так. Но ведь подобный датафлоу анализ можно проводить, если ещё можно доказать что сайд эффектов нет, ссылки не утекают и всё такое, то оптимизировать можно дофига чего. Асимптотика в теории так же чинится, циклы там убирать если они взаимно уничтожаются. Но я о таком не слышал

я тут недавно вопрос задавал. Меня в ступор поставил ionide или F# компилятор (не уверен): fun x -> fun y -> x y он предложил заменить на id Я неприлично долго одуплял почему это действительно так. Но ведь подобный датафлоу анализ можно проводить, если ещё можно доказать что сайд эффектов нет, ссылки не утекают и всё такое, то оптимизировать можно дофига чего. Асимптотика в теории так же чинится, циклы там убирать если они взаимно уничтожаются. Но я о таком не слышал

Оптимизировать много что можно, это правда. Но я бы не стала возлагать такие надежды именно на LLVM. Тем более, что он под такие штуки и не заточен (ну где-то даже статью кидали мне, сейчас пока не могу поискать)

И если теоретически что-то можно доказать и оптимизировать, это ещё не значит, что это можно прям взять и реализовать в компиляторе из жизни и для прода ?

И если теоретически что-то можно доказать и оптимизировать, это ещё не значит, что это можно прям взять и реализовать в компиляторе из жизни и для прода ?

это всё потому что ты ещё не сделала!

Привет, ты тоже со странным именем

Привет, ты тоже со странным именем

@neftedollar недоверяй странным Именам

А вы говорили фпарсек с гопаком упоролись по операторам https://github.com/fsprojects/FSharpPlus/blob/1bf075391d76013eeaa2e9c837f66de3cacf35cb/src/FSharpPlus/Operators.fs#L751

Нет, было сказано в ответ на другое

Я просто оптимизировал :) моё сообщение из одного предложения, а аналогичное, на которое я сослался - два экрана в телефончике.

(=) <!> x <*> y

это если что определение оператора ( .=. )

¯\_(ツ)_/¯

¯\_(ツ)_/¯

такой оператор кстати есть?

такой оператор кстати есть?

В try catch сделать?

такой оператор кстати есть?

было бы офигенно)

А такой - (__!__)

Надо либу такую писать!

А такой - (__!__)

тогда уж такой! (__*__) - девственный оператор (__o__) - слегка развальцованный (__O__) - полный жопак

Вместо failwith конечно же :)

В жопаке

да чиорт тебя дери

короче, авторы FSharpPlus упоролись

haskell wannabe

Но там есть плюсы. Я обычно для своих структур определяю ручками моноид: type Abc = ... static member (+) (a,b) = ... static member Zero = .... Так вот F# плюс позволяет такие структуры без лишнего гемора сразу в Seq.sum засовывать! Я-то раньше как плебей писал так |> Seq.fold (+) Abc.Zero а теперь можно так |> Seq.sum символов 10 мне сэкономили, черти. Это стоит того чтобы тащить эту либу! /s

Привет!

Привет!