В течение нескольких лет в сообществе программистов происходил мемориал, что «среднестатистические программисты» не получают функциональное программирование (часто от функциональных программистов) или что «функциональное программирование слишком сложно для среднего программиста» (часто от тех, кто не хочет научиться функциональному программированию).
Я бы сказал, что функциональное программирование является абсолютно важной эволюцией именно потому, что большая часть из нас является средней или ниже средней. Если вы понимаете определение «средний», вы не должны обижаться на то, что я называю большое количество программистов средним или ниже.
Распад императивного программирования в условиях растущей сложности
Джесситрон написал отличный пост о двух моделях вычислений, которые в значительной степени соответствуют моему аргументу, который я укажу ниже.
Императивное программирование ломается с ростом сложности и богатства, рассмотрим следующий императивный пример в Java:
public void addBar(Foo foo){
Bar bar = new Bar("baz");
foo.setBar(bar);
dao.update(foo);
dao.save(bar);
}
- Будет ли этот код работать?
- Нужно ли обновлять foo перед сохранением панели или наоборот?
- Можем ли мы верить, что любой из вызванных методов делает только то, что подразумевают имена?
Ответ на все три вопроса: вы не могли бы знать, не держа в голове полную модель всего приложения вместе со знанием библиотек, которые оно использует!
Можете ли вы представить себе когнитивную нагрузку, которую это накладывает на ваш мозг, когда вам нужно создать мысленную модель куска кодов всей вселенной, чтобы иметь возможность осмысленно рассуждать об этом?
Некоторые утверждают, что вы должны «просто знать», как работают ваши библиотеки, что делает дао и т. Д. Но это именно моя точка зрения: это ненужная когнитивная нагрузка на ваш мозг, мозговые циклы, пытающиеся вспомнить тонкости другого кода, мозговые циклы это можно было бы более продуктивно использовать для рассуждения о проблеме под рукой.
Некоторые утверждают, что вы должны «быть дисциплинированными» и следовать точному набору кодифицированных практик, чтобы облегчить нагрузку. Справедливо, если вы следуете этим правилам, и все остальные тоже так поступают (что, по моему опыту, является довольно смелым предположением), теперь вам нужно всего лишь сохранить X сотню правил, чтобы рассуждать о коде. Тем не менее: очень высокая когнитивная нагрузка на мозг, когда хорошие инструменты и языки могут ее разгрузить.
Функциональное программирование на помощь!
Я не собираюсь описывать здесь функциональное программирование полностью (другие сделали это лучше), но если мы предположим, что следующие свойства верны для FP:
- Неизменные данные : присвоенное значение или значения, из которых оно состоит, не изменяются в течение срока его службы.
- Ссылочная прозрачность : одни и те же входные данные для функции всегда возвращают один и тот же результат и больше ничего не делают.
- Функции высшего порядка : функции могут принимать функции в качестве аргументов и возвращать функции. Функции являются значениями первого класса.
Теперь давайте посмотрим на простейший из возможных фрагментов кода, вычисляя y , применяя функцию f к x :
let y = f x
Если 3 свойства верны, мы знаем, что для f (x) мы всегда получим один и тот же y, и вычисление y — единственное, что происходит — ядерные ракеты не запускаются .
Мы также знаем, что мы не могли сказать x = fx , потому что это просто не имело бы никакого смысла — x уже существует и не может быть переназначен.
Хорошо, это все довольно очевидно, но какой в этом смысл? Ну, вдруг вы достигаете следующего:
- Вам не нужно строить умственную модель всей системы и ее библиотек, чтобы рассуждать об этом.
- Следствие, вы можете рассуждать о любом подмножестве системы, пусть даже небольшом, даже не понимая, что делает вся система.
Преимущества этого вряд ли стоит перечислять, но я все равно перечислю несколько практических:
- Вам не нужно полагаться на свою память о том, что вы, возможно, сделали много лет назад, чтобы справиться с новыми требованиями, изменениями или отследить ошибки.
- Для менеджеров: зависимость от ключевых лиц ( «парень, который знает все о системе» ) становится менее важной проблемой.
- Новые люди могут стать продуктивными гораздо быстрее, больше не нужно тратить время на построение ментальной модели всего.
Смею ли я сказать это? Для счетчиков бинов и риск-менеджеров функциональное программирование делает людей, работающих в системе, более взаимозаменяемыми, если они обладают необходимыми знаниями, чтобы понимать и аргументировать общие концепции, используемые в системе.
На пути к функциональному программированию: в основном вопрос смирения, образования и самообразования
После того, как я медленно погрузился в функциональное программирование в течение последних 6-7 лет или около того, сталкиваясь с различными организациями и множеством людей на многих этапах принятия или сопротивления ФП, я понял, что иногда медленный рост и сопротивление функциональному программированию не имеет ничего общего с обычными спорными аргументами. Они широко делятся на две категории:
Гордость и престиж: люди, которые могли потратить десятилетия в своей области и стать признанными «экспертами», могут неохотно отказываться от своего экспертного ярлыка или признавать себя или других, что они все еще могут быть новичками и им есть чему поучиться. Интерес к статус-кво всегда велик в любой области, и смирение, которое требуется, чтобы сказать: «Я снова новичок в этом подмножестве выбранной мной области» , особенно трудно найти тем, кто вложил самые большие инвестиции в так обстоят дела.
Сопоставление незнакомости со сложностью. Другая распространенная умственная ловушка — думать, что то, что незнакомо, на самом деле вовсе не незнакомо, а сложно или сложно. Я думаю, что это тесно связано с гордостью — нежелание узнавать что-то новое и признавать даже себе, что вы, возможно, не являетесь экспертом во всем, что связано с программированием, значительно упрощает объявление чего-то незнакомого как «сложного» .
Функциональное программирование на самом деле не сложнее, чем императивное программирование. Как я объяснил в этом посте, функциональное программирование фактически делает вещи намного проще, намного менее сложными, и дает нам инструменты, чтобы лучше справляться со сложностью в целом.
В 2014 году у вас нет абсолютно никаких причин для того, чтобы напрягать мозг умением строить интеллектуальную модель всей системы в своей голове, чтобы продуктивно выполнять свою работу программиста. Это проигрышная причина, так как в конечном итоге размер рабочей памяти человека просто не позволит никому справиться со всем этим.
Нет никаких оснований для нас сохраняется в использовании неподходящего уровня абстракции свободно основанный на физических работах манипулирования памяти кремния. Давайте перейдем в 21 век раз и навсегда.