Вот именно, чистота то математическая, а разработка идет на реальной платформе имеющей свои ограничения. Поэтому ФП — абстрактно здорово, а реально только в отдельных случаях хорошо.
А кстати, давайте снимем последние покровы!!! Нахрен
Чистота функций в ФП млять… Какая нах… чистота функций может быть, если все реализуется на императивной неймановском процессоре!? Какая, я вас спрашиваю!?
Если вы в коде на haskel не написали, var a = 100001 или там a+=500, это еще не значит, что ваш код пахнет ромашками, а у соседа пишущего на c++, пардон, г… м.
А стеки вызовов функций? А указатели на голову и хвосты? А стеки данных и буферы потоков ввода/вывода? Вы думаете этого всего нет в haskel!? Тогда купите себе билет в дурдом и больше не пишите го… код!
Все что привносит современное ФП, запиленное поверх императивных языков, под маркой «чистоты» это то, что с проблемами состояния, типизации, выделения памяти борется кто-то другой, а не ФП программист.
В реальности, под капотом реализации любого ФП языка живет гипертрофированное внутренне состояние вычислительной среды, имеющее тенденцию распухать и множится. И уже не понятно, что есть меньшее зло, честно сказать компилятору, чтобы он выделил десять байт под массив и заносил туда данные простым присваиванием или это будет делать невидимый монстр который на каждый чих в рекурсивном цикле будет: выделять десять байт; копировать состояние из предыдущих десяти байт; менять один из байтов и так сотни и тысячи раз! А затем в дело вступает сборщик мусора, который останавливает нашу программу проверяет все эти созданные массивы решает, что ненужно чистит и упаковывает память. Так что сразу прощай и память и производительность.
И любой разработчик, не зная всех особенностей реализации, может безобидной функцией на ФП языке завалить всю систему в глубокий дос. Плавали — знаем, на C# такой сценарий как два пальца, а если быдлокодеру дать еще и haskel с clojure — туши свет
Ага! Гладко было на бумаге… как только заговорили о многопоточности решили все разделить по функциям, а потом вспомнили о синхронизации, а как ее осуществлять из чистых то функций!? Опять неймановская архетиктура стала из под абстракций торчать
ООП и ФП вообще разные вещи и никак друг-другу не противоречат.
Наивный ;) где же это видано 10000 строк чистой функции, наоборот там будет чистый фарш из десятка монад, зависимостей и состояний, ну нельзя реальный мир на неймановской архитектуре описать чистыми функциями — хоть тресни.
А вообще, сколько раз (за двадцать лет программирования) я уже слышал о «новых прорывных» технологиях, которые сделают хорошо программисту, а воз и ныне там… уже не верю ни в серебряные пули, ни в эльфов из Микрософт, что выкуют новую ОС и язык программирования всеобщего счастья, как-то так.
Да и функциональное программирование живет себе уже 40 лет и уже десятое поколение начинающих программистов-фанатиков обещает всеобщее счастье и прогресс, реальность топчет все эти обещания кованным сапогом… в итоге имеем промышленный стандарт с++\c# и Java в которых что-то можно описывать в функциональной парадигме посреди императивного кода
Много раз сталкивался с такими функциями самый эпичный случай хранимая процедура на t-sql из 8 или 9 тыс строк и не одна, великий и могучий индусский код
Но самое большое бедствие функционального подхода это… Функции! И как и в имеративном подходе, каждый разработчик волен производить декомпозицию задачи на функции произвольным образом., что может приводить к очень большим проблемам при сопровождении и изменении программы.
То есть концептуально, для разработки сложных систем, ничего не поменялось, нет никакой страховки, что супер-пупер навороченная функция из десяти тысяч строк не содержит ошибки и не вынесет весь прекрасно выглядещий абстрактный и правильный вобщем код на крах системы
Высказались уже лет тридцать назад и мало кто сейчас так пишет, а так fort хорош конечно, сам по себе.
Вы привели только функциональную часть синтаксиса, а есть еще и императивная которая все меняет
И что это принципиально меняет? Все равно используется неймановская архетиктура и императивный язык, а какие пляски с бубном начинаются при реализации много поточности и сборки мусора!
Так зачем, если не видно разницы, думать больше!? Сразу пишем на императивном языке ;)
Как правильно заметил автор, 95 процентов задач вполне решаются императивным подходом, плюс нароботана десяти-двадцатилетняя экспертиза по решению, плюс библиотеки
Вы привели пример реализации на неймановской архетиктуре и императивном языке. Я знаю еще несколько различных ИМПЕРАТИВНЫХ реализаций. Фактически функциональное программирование это синтаксический сахар над алголоподобными языками. Мое утверждение было гораздо более общим, архетиктура выч системы должна из коробки поддерживать функциональное программирование. Пока есть пример лисп-машины, но она тоже неймановская.
В реализации сила и слабость функционального языка, ибо с одной стороны язык не запрещает никаких способов реализации которые бы давали правильный ответ, но и никаким образом не подсказывает, какая реализация могла бы быть опимальной. Вся реализация лямбда исчисления и фп — математические концепции в голове разработчика.
Те кто здесь рассуждает о функциональном подходе, то забывает о главном, что лямбда исчисление эквивалентно машине тьюринга. Таким образом, выразительная и вычислительная мощь императивных и функциональных языков ОДИНАКОВА!
Но есть ньюанс, никто не знает как должна выглядеть архитектура функционального фычислителя ввиду его полной абстракции ;)
Зато существует, уже полвека, неймановская архетиктура и все императивные языки являются надстройкой над этой архитектурой и максимально ее утилизируют. Все Функциональные языки являются надстройкой над виртуальной машиной, которая пишется в императивном стиле и использует реальную неймановскую архетикоуру.
Так что функциональные языки это попытка построить еще один уровень абстракции над императивным языком, а императивный язык это уровень абстракции над ассемблером и тд и тп
Вопрос риторический сколько уровней абстракции нужно для решения конкретной задачи. Как то так
Вызов делегата это delegate(aaa);
А не всякие там GetType() и GetMethod() это тот же рефлекшен только в профиль
А еще есть вызов интерфейсов, вобщем прежде чем писать мегастатьи лучше погуглите codeplex с 2005 годов, много узнаете нового
Нда… так криво вызывать делегат — это надо постараться… нафига писать говнокод. а потом обсуждать, что он плохо работает…
Пишем:
public static TestResult TestDelegateCall(DateTime arg)
{
var instance = Container.Get(arg.GetType());
//var hook = CreateDelegate(instance, instance.GetType().GetMethod(«Process»));
Func hook = Container.Get().Process;
Stopwatch sw = new Stopwatch();
sw.Start();
long summ = 0;
for (long i = 0; i < ITERATION_COUNT; i++)
{
//summ += (long)hook.DynamicInvoke(arg);
summ += hook(arg);
}
sw.Stop();
return new TestResult { Result = summ, ElapsedMilliseconds = sw.ElapsedMilliseconds };
}
И вуаля:
Прямой вызов
Min: 921 ms
Max: 943 ms
Mean: 928,8 ms
Median: 928,5 ms
Вызов через отражение
Min: 1302 ms
Max: 1319 ms
Mean: 1311,3 ms
Median: 1310,5 ms
Вызов через делегат
Min: 921 ms
Max: 940 ms
Mean: 929,2 ms
Median: 929 ms
Вызов через делегат с оптимизациями
Min: 1093 ms
Max: 1117 ms
Mean: 1103,7 ms
Median: 1101,5 ms
Вызов через dynamic
Min: 1058 ms
Max: 1076 ms
Mean: 1066,6 ms
Median: 1065,5 ms
Чистота функций в ФП млять… Какая нах… чистота функций может быть, если все реализуется на императивной неймановском процессоре!? Какая, я вас спрашиваю!?
Если вы в коде на haskel не написали, var a = 100001 или там a+=500, это еще не значит, что ваш код пахнет ромашками, а у соседа пишущего на c++, пардон, г… м.
А стеки вызовов функций? А указатели на голову и хвосты? А стеки данных и буферы потоков ввода/вывода? Вы думаете этого всего нет в haskel!? Тогда купите себе билет в дурдом и больше не пишите го… код!
Все что привносит современное ФП, запиленное поверх императивных языков, под маркой «чистоты» это то, что с проблемами состояния, типизации, выделения памяти борется кто-то другой, а не ФП программист.
В реальности, под капотом реализации любого ФП языка живет гипертрофированное внутренне состояние вычислительной среды, имеющее тенденцию распухать и множится. И уже не понятно, что есть меньшее зло, честно сказать компилятору, чтобы он выделил десять байт под массив и заносил туда данные простым присваиванием или это будет делать невидимый монстр который на каждый чих в рекурсивном цикле будет: выделять десять байт; копировать состояние из предыдущих десяти байт; менять один из байтов и так сотни и тысячи раз! А затем в дело вступает сборщик мусора, который останавливает нашу программу проверяет все эти созданные массивы решает, что ненужно чистит и упаковывает память. Так что сразу прощай и память и производительность.
И любой разработчик, не зная всех особенностей реализации, может безобидной функцией на ФП языке завалить всю систему в глубокий дос. Плавали — знаем, на C# такой сценарий как два пальца, а если быдлокодеру дать еще и haskel с clojure — туши свет
ООП и ФП вообще разные вещи и никак друг-другу не противоречат.
А вообще, сколько раз (за двадцать лет программирования) я уже слышал о «новых прорывных» технологиях, которые сделают хорошо программисту, а воз и ныне там… уже не верю ни в серебряные пули, ни в эльфов из Микрософт, что выкуют новую ОС и язык программирования всеобщего счастья, как-то так.
Да и функциональное программирование живет себе уже 40 лет и уже десятое поколение начинающих программистов-фанатиков обещает всеобщее счастье и прогресс, реальность топчет все эти обещания кованным сапогом… в итоге имеем промышленный стандарт с++\c# и Java в которых что-то можно описывать в функциональной парадигме посреди императивного кода
То есть концептуально, для разработки сложных систем, ничего не поменялось, нет никакой страховки, что супер-пупер навороченная функция из десяти тысяч строк не содержит ошибки и не вынесет весь прекрасно выглядещий абстрактный и правильный вобщем код на крах системы
Вы привели только функциональную часть синтаксиса, а есть еще и императивная которая все меняет
Так зачем, если не видно разницы, думать больше!? Сразу пишем на императивном языке ;)
Как правильно заметил автор, 95 процентов задач вполне решаются императивным подходом, плюс нароботана десяти-двадцатилетняя экспертиза по решению, плюс библиотеки
В реализации сила и слабость функционального языка, ибо с одной стороны язык не запрещает никаких способов реализации которые бы давали правильный ответ, но и никаким образом не подсказывает, какая реализация могла бы быть опимальной. Вся реализация лямбда исчисления и фп — математические концепции в голове разработчика.
Но есть ньюанс, никто не знает как должна выглядеть архитектура функционального фычислителя ввиду его полной абстракции ;)
Зато существует, уже полвека, неймановская архетиктура и все императивные языки являются надстройкой над этой архитектурой и максимально ее утилизируют. Все Функциональные языки являются надстройкой над виртуальной машиной, которая пишется в императивном стиле и использует реальную неймановскую архетикоуру.
Так что функциональные языки это попытка построить еще один уровень абстракции над императивным языком, а императивный язык это уровень абстракции над ассемблером и тд и тп
Вопрос риторический сколько уровней абстракции нужно для решения конкретной задачи. Как то так
А не всякие там GetType() и GetMethod() это тот же рефлекшен только в профиль
А еще есть вызов интерфейсов, вобщем прежде чем писать мегастатьи лучше погуглите codeplex с 2005 годов, много узнаете нового
Пишем:
public static TestResult TestDelegateCall(DateTime arg)
{
var instance = Container.Get(arg.GetType());
//var hook = CreateDelegate(instance, instance.GetType().GetMethod(«Process»));
Func hook = Container.Get().Process;
Stopwatch sw = new Stopwatch();
sw.Start();
long summ = 0;
for (long i = 0; i < ITERATION_COUNT; i++)
{
//summ += (long)hook.DynamicInvoke(arg);
summ += hook(arg);
}
sw.Stop();
return new TestResult { Result = summ, ElapsedMilliseconds = sw.ElapsedMilliseconds };
}
И вуаля:
Прямой вызов
Min: 921 ms
Max: 943 ms
Mean: 928,8 ms
Median: 928,5 ms
Вызов через отражение
Min: 1302 ms
Max: 1319 ms
Mean: 1311,3 ms
Median: 1310,5 ms
Вызов через делегат
Min: 921 ms
Max: 940 ms
Mean: 929,2 ms
Median: 929 ms
Вызов через делегат с оптимизациями
Min: 1093 ms
Max: 1117 ms
Mean: 1103,7 ms
Median: 1101,5 ms
Вызов через dynamic
Min: 1058 ms
Max: 1076 ms
Mean: 1066,6 ms
Median: 1065,5 ms