Здравствуйте, Poopy Joe, Вы писали:

PJ>Общая скорость определяется самым медленным элементом. Иногда это память, иногда процессор, но в 99% это IO. Именно оно и определяет в большей степени.

Это верно в очень редких случаях, более того, в тех случаях, когда это верно, функциональное программирование используется редко (приведите примеры программ на функциональном языке, которые бы обрабатывали огромные объёмы данных и затыкались бы именно на IO).

PJ>Смелое и бездоказательное утверждение. Я точно так же могу возразить, что в реальность практически любой кода останется примерно таким же. Какой-то, да, станет быстрее, какой-то сделать быстрее написать будет намного сложнее. И чем сложнее код, тем эта вероятность выше.

Вот, например тесты производительности. В них функциональщина сливает по производительности практически всегда. Из особо показательных тестов: C# vs F# — функциональный вариант уступает императивному, исполняющемуся в той же среде (net core).

PJ>Я ровно это и сказал. Хоть на ассемблере перепиши, если приложение ждет сетевой пакет, или просто реагирует на таймер, его общая скорость никак не изменится от переписывания. Где я тут чего наврал?

Тут, по-моему, имелось в виду другое: функциональщина используется ограниченно именно потому что существенно медленнее императивного кода, поэтому её используют только в тех случаях, когда производительность не важна.
(К примеру, тот же околофункциональный LINQ — отличная штука в целом, но в узких местах приложения лучше от него отказаться).

Здравствуйте, Poopy Joe, Вы писали:

PJ>Общая скорость определяется самым медленным элементом. Иногда это память, иногда процессор, но в 99% это IO. Именно оно и определяет в большей степени.

Это верно в очень редких случаях, более того, в тех случаях, когда это верно, функциональное программирование используется редко (приведите примеры программ на функциональном языке, которые бы обрабатывали огромные объёмы данных и затыкались бы именно на IO). (Поясню — я имею в виду современное железо, способное обеспечить гигабайты пропускной способности в секунду).

PJ>Смелое и бездоказательное утверждение. Я точно так же могу возразить, что в реальность практически любой кода останется примерно таким же. Какой-то, да, станет быстрее, какой-то сделать быстрее написать будет намного сложнее. И чем сложнее код, тем эта вероятность выше.

Вот, например тесты производительности. В них функциональщина сливает по производительности практически всегда. Из особо показательных тестов: C# vs F# — функциональный вариант уступает императивному, исполняющемуся в той же среде (net core).

PJ>Я ровно это и сказал. Хоть на ассемблере перепиши, если приложение ждет сетевой пакет, или просто реагирует на таймер, его общая скорость никак не изменится от переписывания. Где я тут чего наврал?

Тут, по-моему, имелось в виду другое: функциональщина используется ограниченно именно потому что существенно медленнее императивного кода, поэтому её используют только в тех случаях, когда производительность не важна.
(К примеру, тот же околофункциональный LINQ — отличная штука в целом, но в узких местах приложения лучше от него отказаться).