Какое твое самое сильное мнение против функционального программирования? [закрыто]

Функциональное программирование - одна из самых старых парадигм программирования. Однако он не используется в промышленности по сравнению с более популярными парадигмами. Но это в значительной степени подчеркивалось в научных кругах.

Какое твое самое сильное мнение против функционального программирования?

Проблема в том, что наиболее распространенный код по своей природе включает в себя государственные приложения, игры, пользовательский интерфейс и т. Д. Нет проблем с тем, что некоторые части приложения являются чисто функциональными; на самом деле, большинство приложений может принести пользу как минимум в одной области. Но навязывание парадигмы повсеместно кажется нелогичным.

Проблема с функциональным программированием не в самом функциональном программировании - это большинство людей, которые делают это и (что еще хуже) большинство людей, которые создают языки, на которых это делается.

Проблема связана с тем фактом, что, несмотря на то, что люди очень умные (иногда совершенно блестящие), слишком многие люди слишком фанатичны в отношении чистоты, совершенства и реализации своего собственного (часто довольно узкого) взгляда на мир и программирования на язык и все, кто его использует.

Одним из результатов является неспособность к компромиссу. Это приводит (помимо всего прочего) к примерно 10 000 языков и диалектов, которые достаточно различны, чтобы раздражать, но лишь в редких случаях достаточно различаются, чтобы один имел действительно значительное преимущество над другими. Многие также смотрят на реальный мир и решают, что, поскольку он не очень хорошо вписывается в функциональную модель, он в основном просто неправильный и лучше всего игнорируется.

Неспособность идти на компромисс также привела к появлению нескольких языков, которые абсолютно прекрасны для определенного типа проблемы (или нескольких конкретных типов проблем), но действительно отстой для многих других. Частично это, вероятно, вызвано самой функциональной моделью, но гораздо больше (по крайней мере, мне) вызвано базовым типом личности, который изначально привлекает эту область.

Это приводит к ряду проблем. Прежде всего, изучение «функционального программирования» имеет в основном философскую ценность. Для большинства других типов языков знание одного языка определенного жанра существенно помогает в изучении другого. Если в моем проекте используется язык XI, обычно я могу нанять человека, который знает язык Y (но не X), достаточно безопасно. С функциональными языками это гораздо менее верно. Возможно, вы хорошо знаете Эрланга, но все еще находите монады Хаскелла совершенно чужими и непостижимыми.

Соедините количество языков с ограниченной переносимостью талантов между ними, и вы получите уродливую ситуацию: для одного языка или диалекта почти невозможно сформировать «критическую массу», необходимую для того, чтобы сделать ее достаточно широко используемой. Это медленно меняется, но это все еще очень много , как Linux становится доминирующей настольной ОС - каждый год, люди приходят с убедительными аргументами , что в конце концов это будет год - и так же , как людей , которые предсказывали , что каждый год на протяжении десятилетий, они снова будут неправы. Это не означает, что этого (любого из них) никогда не случится, просто люди, которые смотрят на прогнозы и думают: «Нет, не в этом году», были теми, кто был прав до сих пор.

Я думаю, что причина, по которой функциональное программирование используется не очень широко, заключается в том, что оно слишком мешает вам. Трудно серьезно взглянуть, например, на Лисп или Хаскелл, не говоря «весь этот язык - одна большая инверсия абстракции». Когда вы устанавливаете базовые абстракции, ниже которых кодер не может получить нужную информацию, вы устанавливаете вещи, которые язык просто не может делать, и чем функциональнее язык, тем больше таких тенденций он имеет.

Взять, к примеру, Хаскелл. Во имя функциональной чистоты вам необходимо использовать головокружительные инверсии абстракций, которые никто не понимает, чтобы управлять состоянием и вводом / выводом, двумя наиболее фундаментальными частями любой компьютерной программы, которая взаимодействует с чем угодно! Это быстро стареет.

При всем моем уважении, я думаю, что ваш вопрос плохо сформулирован. Функциональное программирование - это инструмент, а точнее набор инструментов, которые полезны для решения определенных видов задач. Наличие мнения об этом имеет смысл только в контексте конкретной проблемы или приложения. Иметь мнение против этого вообще, как иметь мнение против плоскогубцев или рывков.

Даже если бы я освоил его, я мог бы не захотеть использовать функциональный язык для коммерческого продукта по той простой причине, что он не очень понятен, и если бы я ожидал, что бизнес будет расти, я был бы обеспокоен возможностью найти других разработчиков, способных поддерживать или расширять его с течением времени.

Это немыслимо, и вы, вероятно, получите более высокий стандарт разработчика, потому что выпускник javaschool без реальных навыков хакерства не будет знать, с чего начать проект такого типа, но ограниченный пул способных разработчиков, безусловно, будет необходимым соображением с точки зрения бизнеса.

Пора торговать

Сложно избавить весь ИТ-ландшафт от процедурного кода и мантр.

во-первых, я не принимаю никаких аргументов, касающихся программирования с учетом состояния и fp. Изучите монаду State в haskell, и вы найдете ряд новых интересных способов оценить влияние состояния на ваш код.

если бы я мог привести содержательный аргумент против fp, то было бы так, что изучение серьезного функционального языка, такого как haskell, похоже на обучение вождению автомобиля Формулы 1. Вдохновляющее и познавательное, но, к сожалению, бесполезное для повседневного промышленного кодирования, потому что в среднем Ваши коллеги водят Camrys и очень рады это сделать. все еще чрезвычайно трудно найти работу в среде, дружественной к фп, и я не вижу, как это изменится, если только один не захочет нанести удар самостоятельно или разыскивать некоторых из известных практиков фп.

я предполагаю, что мой ответ показывает меня как фанат fp. Я предлагаю серьезно подумать над реальным языком fp, таким как haskell, прежде чем беспокоиться о поиске причин, по которым вам этого не следует делать.

Я большой поклонник и сторонник функционального программирования. Но вот мои пункты:

• легко изучать
  Языки программирования, такие как python и ruby ​​(и многие другие языки), легко изучаются. Усовершенствованное функциональное программирование с такими языками, как Haskell, Agda, Coq, ATS и т. Д., Довольно сложно освоить. Некоторые используют термин «математическое структурированное программирование». Это легко, если вы знакомы с теорией категорий и абстрактной математикой, но довольно много работы, если вы не знаете, что такое, например, «монады».

• программирование на языке сценариев может означать большую производительность.
  В некоторых ситуациях использование языков сценариев, таких как python и ruby, может повысить производительность. Это означает быстрое создание прототипов и склейку различных пакетов или библиотек. Даже использование динамических языков (например, динамическое объектно-ориентированное программирование) может быть хорошей вещью в этом контексте. Обычно статическая типизация лучше, но сценарии с динамическими типами могут иметь положительный эффект.

• деловые соображения
  Программирование - это лишь небольшая часть успешных программных проектов. Программное обеспечение должно работать, пользователи должны быть счастливы, и это не обязательно зависит от используемого языка программирования. Менеджеры должны учитывать преимущества и риски при оценке новых технологий и языков программирования. Могут ли новые программисты быстро выучить новый язык программирования? Есть ли у компании опыт работы с технологиями? Есть ли риск, и будет ли трудно спорить с высшим руководством?

В бизнес-контексте функциональное программирование может использоваться в системах, которые добавляют к основным программным компонентам, например, к компонентам, которые не являются критически важными. Например, банк, который вряд ли изменит основное программное обеспечение, но добавит новые части (графический интерфейс, программное обеспечение для мониторинга и т. Д.) На новом языке программирования. (Возможно, есть исключения, но это мой опыт работы с банками.)

Кроме того, функциональное программирование очень полезно, когда формальная проверка является преимуществом или необходимостью.

Я не против FP как полезной парадигмы, но я против нее как единственной парадигмы, доступной в языке программирования.

Это дает преимущества в решении многих проблем. Однако FP может и был применен в процедурных языках, таких как C.

1. (и, безусловно, самое важное). Персонал программиста не обучен этим языкам или стилям.
2. Многие из функционирующих евангелистов оказываются «дырками» или кексами из-за того, как они пытаются продать функционал. Никто не любит дыру, и никто не собирается бросать деньги за кекс. Имейте в виду, мне действительно нравятся функциональные вещи, и я хотел бы их использовать, но я знаю, что на своем рабочем месте я был бы единственным человеком, который мог бы развивать его, не тратя денег на обучение (упорные продажи) и почти все хорошее ссылки обговорены у читателя.

Функционал придет, когда у нас будут сотни ядер, и поймем, что блокировки не масштабируются. Тогда параллельная обработка вложенных данных будет единственным способом использования программ «большого железа», и в этом функциональность будет превосходной.

FP - это круто в академических кругах, потому что это здорово - писать хорошие короткие программы, игнорируя при этом производительность. Нет никакого заговора против этого в реальном мире. Также, например, реализация некоторых вещей (например, радикальная сортировка) выглядит как полная боль в FP. Ох, и сгенерированный код IMHExperience sloooooooooooooooooooow.

У некоторых кривая обучения довольно крутая, что занимает много времени (особенно если вы выходите из ООП; вы несколько раз покачаете головой, прежде чем получите смену парадигмы).

Даже несмотря на то, что я начал заниматься функциональным программированием (с Java и с Clojure), мне все еще трудно. Сообщество, похоже, не пишет такой выразительный код, как Java.

Похоже, что есть небольшая потеря выразительности и небольшое увеличение сложности.

Несмотря на то, что у меня мало опыта работы с функциональными языками программирования (я знаю некоторые Haskell и Lisp), я нахожу парадигму FP очень мощной и часто более элегантной, чем другие парадигмы. Хотел бы я иметь возможность работать над серьезным проектом с использованием FP.

Единственная область, в которой у меня есть серьезные сомнения относительно эффективности FP, заключается в том, как он может работать со сложными структурами данных, которые не могут быть определены индуктивно, например, с графиками. Например, если мне нужно реализовать алгоритм, который работает на большом графе, возможно, проходя по нему и делая небольшие локальные изменения, мне интересно, может ли подход FP соответствовать императивному подходу, при котором программе разрешено перемещаться с узла на узел с помощью указателей.