ZerdoX-x, приводить единственный крайний пример и распространять вывод на все остальные примеры - это моветон. Поэтому я ещё раз напомню, что речь не про пример из вопроса.
Насчёт оптимизации, я бы не был так уверен. С одной стороны, да, своя функция, которая делает то же самое, что и нативная, будет медленнее. Но с другой стороны, если функциональный стиль предполагает выделение дополнительной памяти под массивы и вызов функции на каждой итерации цикла, то это тоже может быть медленнее, чем чистый цикл-for. К слову, оптимизация обычно противоречит прочим критериям качества, поэтому её целесообразность ситуативна.
На всякий случай: моё "может быть" означает также, что может и не быть. То есть это не утверждение, а сомнение, поэтому не нужно его оспаривать и приводить контрпримеры. Мой тезис заключается в том, что функциональный стиль - не панацея.
Насчёт многословности, - тоже не однозначно. Короче - не значит понятнее. Названия переменных тоже можно сократить до одной буквы, будет короче, но в целом хуже.
На самом деле можно дофига причин придумать и этот список можно дальше продолжать. (с) ваш слова. Я к тому, что не нужно, пожалуйста, этих общих фраз, у меня нет цели "победить" или "доказать", мне лишь было интересно, на чём основано ваше мнение. Примерно понял, спасибо.
А чем плох императивный код? Он сильно медленнее, или больше памяти кушает, или что? Компактность и лаконичность - не одно и то же. Мой комментарий относится не к конкретному коду из вопроса, а к императивному стилю вообще.
for /f "usebackq tokens=2,*" %A in (`reg query HKCU\Environment /v PATH`) do set save_temp_path=%B
setx PATH "%save_temp_path%;C:\Windows\twain_32\CNQL25"
Александр Гусев, я это понимаю, но интересны как раз выходы за min, max (в первую очередь за max). Никто же не будет писать, сколько минут или даже секунд микросхема в среднем будет жить при сверхвысоких температурах самой схемы (до точки плавления, конечно же).
Насчёт оптимизации, я бы не был так уверен. С одной стороны, да, своя функция, которая делает то же самое, что и нативная, будет медленнее. Но с другой стороны, если функциональный стиль предполагает выделение дополнительной памяти под массивы и вызов функции на каждой итерации цикла, то это тоже может быть медленнее, чем чистый цикл-for. К слову, оптимизация обычно противоречит прочим критериям качества, поэтому её целесообразность ситуативна.
На всякий случай: моё "может быть" означает также, что может и не быть. То есть это не утверждение, а сомнение, поэтому не нужно его оспаривать и приводить контрпримеры. Мой тезис заключается в том, что функциональный стиль - не панацея.
Насчёт многословности, - тоже не однозначно. Короче - не значит понятнее. Названия переменных тоже можно сократить до одной буквы, будет короче, но в целом хуже.
На самом деле можно дофига причин придумать и этот список можно дальше продолжать. (с) ваш слова. Я к тому, что не нужно, пожалуйста, этих общих фраз, у меня нет цели "победить" или "доказать", мне лишь было интересно, на чём основано ваше мнение. Примерно понял, спасибо.