Comments 19
Первая часть еще куда ни шло, но вторая уж совсем толстый троллинг.
Что делает мужик с перилами и стаканом песка?
количество_строк_кода = время_необходимое_на_написание_кода = $$$деньги$$$
кстати в нормальном языке может быть так что количество строк кода уменьшается со временем и это правильно.
необходимоеКоличествоСтрокКода = флудерскоеКоличествоСтрокКода — время * коэффициентИнтеллектуальностиПрограммера.
Больше всего в ООП мне не нравится, что его противопоставляют ФП и другим парадигмам. Это с одной стороны. С другой больше всего в ФП мне не нравится, что его противопоставляют… Шутка. Что его объединяют с другими вещами, например "Говорим ФП — поразумеваем мощную систему типов, вплоть до решения задачи исключительно через типы"
ФП таки напрямую связано с типами, потому что оно про композицию функций, а правила оной задаются в т. ч. системой типов.
То есть в нетипизированном или слаботипизированном языке композиция функций невозможна? У меня другое представление. Да, защиты от выстрела себе в ногу не будет, может даже ошибки рантайма не будет, но если самому следить, чтобы параметры/результаты соотвествовали как по типам, так и по смыслу, то в чём проблема? Даже ФП с сильной системой типов не уберегут вас от получения ерунды, если скомпозируете вычисление квадратного корня и синуса, а передадитt ид юзера. (предполагаем, конечно, что он числовой, а не какой-то UserIdType)
То есть в нетипизированном или слаботипизированном языке композиция функций невозможна?
Возможна, конечно. С разной типизацией – разные правила. И поскольку нам обычно не хочется композировать всякую ерунду, неплохо бы выразить в этих правилах какие-то разумные ограничения (не хочу только разводить холивор на тему, что считать разумным).
Уже в базовейшем нетипизированном лямбда-исчислении уже есть правила – терм можно подставлять только в лямбда-абстракцию, что означает выделение функционального типа из всего остального, и запрет на композицию не-функций. А дальше – другие системы с последовательным развитием этих правил.
Даже ФП с сильной системой типов не уберегут вас от получения ерунды, если скомпозируете вычисление квадратного корня и синуса, а передадитt ид юзера. (предполагаем, конечно, что он числовой, а не какой-то UserIdType)
Конечно, нет. Но они предоставят средства, чтобы избежать такой ерунды. Дадут возможность, при наличии желания.
Ограничения, конечно, нужны, если мы хотим получить разумный результат. Но система типов не единственно возможное средство описания этих ограничений и проверки системы на их соответствие. Это с одной стороны, а с другой- система типов ортогональна по сути используемой парадигме. Сильная система типов может быть и в ООП, например.
Сколько общался с функциональщиками — у них всегда горят глаза, когда они говорят об ФП, и они всегда готовы с невообразимым энтузиазмом обмазывать десятками слоев говна все, что представляет какую-либо альтернативу ФП. Причем, обратного не наблюдается — адепты ООП не возбуждаются аналогично при разговорах о ФП.
А уж разделение на «функциональное и ООП» мне просто в голову бы не пришло. Metaobject Protocol, рефлекшен придумали в Lisp.
Функциональное программирование: дурацкая игрушка, которая убивает производительность труда. Часть 2