Потому что в конвейерной сборке процессы однотипные: ты можешь запрограммировать узел на точное повторение одного и того же действия раз за разом (без надежды на изменение в данном случае). В разработке же, в противовес ручному труду, важна именно уникальность. Безусловно, ЧатГПТ может решить проблему по превращению слов в код, но, как и сказал автор, решать он будет по готовой информации в интернете. В разработке людьми большую часть времени занимает ведь не написание кода, а придумывание и осмысление, собственно, что и является ключевыми процессами. А до таких мыслей ЧатГПТ ещё надо дорасти :)
Кажется, автор не до конца понимает смысл функционального программирования :\ ФП - это про иммутабельность и предсказуемое поведение методов, которые при одинаковых параметрах будут возвращать одинаковые результаты, а не внезапные исключения. А в данной статье всё описывается так, будто для ФП достаточно каждую операцию в отдельный метод, чтобы потом "переиспользовать этот модуль"
В пункте "Сглаживание побочных эффектов" можно заменить
int y = AddFive(x);
на
int y = x + 5;
при этом "функциональность" кода (а именно метода Main()) не потеряется. А пока всё это выглядит как утка в зайце: давайте вынесем +5 в метод, чтобы стало функционально.
Пункт про параллелизм я вообще не понял. В угоду распараллеливания автор жертвует иммутабельностью и переписывает значение одного и того же объекта.
Ну и в пункте Модульность и возможность повторного использования автор говорит о том, что цикл - не круто, а вот Enumerable.Aggregate - топ, хотя на функциональность метода Product() это никак не влияет..
Потому что в конвейерной сборке процессы однотипные: ты можешь запрограммировать узел на точное повторение одного и того же действия раз за разом (без надежды на изменение в данном случае). В разработке же, в противовес ручному труду, важна именно уникальность. Безусловно, ЧатГПТ может решить проблему по превращению слов в код, но, как и сказал автор, решать он будет по готовой информации в интернете. В разработке людьми большую часть времени занимает ведь не написание кода, а придумывание и осмысление, собственно, что и является ключевыми процессами. А до таких мыслей ЧатГПТ ещё надо дорасти :)
А почему бы не использовать InMemory бд, которая после выполнения тестов ничего не оставляла? Или нужна именно реальная база?
Кажется, автор не до конца понимает смысл функционального программирования :\
ФП - это про иммутабельность и предсказуемое поведение методов, которые при одинаковых параметрах будут возвращать одинаковые результаты, а не внезапные исключения. А в данной статье всё описывается так, будто для ФП достаточно каждую операцию в отдельный метод, чтобы потом "переиспользовать этот модуль"
В пункте "Сглаживание побочных эффектов" можно заменить
на
при этом "функциональность" кода (а именно метода Main()) не потеряется. А пока всё это выглядит как утка в зайце: давайте вынесем +5 в метод, чтобы стало функционально.
Пункт про параллелизм я вообще не понял. В угоду распараллеливания автор жертвует иммутабельностью и переписывает значение одного и того же объекта.
Ну и в пункте Модульность и возможность повторного использования автор говорит о том, что цикл - не круто, а вот Enumerable.Aggregate - топ, хотя на функциональность метода Product() это никак не влияет..