Какое твое самое сильное мнение против функционального программирования? [закрыто]
25
Функциональное программирование - одна из самых старых парадигм программирования. Однако он не используется в промышленности по сравнению с более популярными парадигмами. Но это в значительной степени подчеркивалось в научных кругах.
Какое твое самое сильное мнение против функционального программирования?
Кстати, термин «функциональное программирование» используется разными людьми для обозначения разных вещей, поэтому вам необходимо уточнить, какое значение вы используете.
Джон Харроп
2
Вы никогда и никогда не найдете людей, которые будут кодировать вашу функциональную кодовую базу. Не лучшее деловое решение, ограничивающее ваш талант.
Патрик Хьюз
Ответы:
52
Проблема в том, что наиболее распространенный код по своей природе включает в себя государственные приложения, игры, пользовательский интерфейс и т. Д. Нет проблем с тем, что некоторые части приложения являются чисто функциональными; на самом деле, большинство приложений может принести пользу как минимум в одной области. Но навязывание парадигмы повсеместно кажется нелогичным.
Абсолютно. Чисто функциональное программирование НЕ подходит для приложений, ориентированных на состояние. Вот почему я люблю гибридные языки, которые могут делать и то, и другое. Используйте функциональные парадигмы для функциональных проблем, императивные парадигмы для императивных проблем.
Мэтт Оленик
8
Согласовано! Государство является неотъемлемой частью программирования. Вот почему даже Haskell, в некотором роде самый чистый из языков FP, позволяет использовать state и IO - он просто проводит различие между кодом IO / изменяемым кодом состояния и чистым кодом, что очень удобно для тестирования и для простоты понимания ,
Билл
8
Вот почему я люблю Haskell. Это поощряет минимизировать тот код с состоянием. В ОО я стремлюсь написать повторно используемый, легкий для понимания и легкий для тестирования код. Большую часть времени я получаю код, я бы не стал писать по-другому на Хаскеле.
LennyProgrammers
4
«он просто обеспечивает различие между кодом ввода-вывода / изменяемым кодом состояния и чистым кодом, что очень удобно для тестирования». Вы даже не можете печатать отладочные сообщения, не обходя систему типов и не вводя монаду крипа.
Джон Харроп
2
Предположительно, чисто функциональная программа оставит мир полностью неизменным, запустив его?
Мартин Беккет
24
Проблема с функциональным программированием не в самом функциональном программировании - это большинство людей, которые делают это и (что еще хуже) большинство людей, которые создают языки, на которых это делается.
Проблема связана с тем фактом, что, несмотря на то, что люди очень умные (иногда совершенно блестящие), слишком многие люди слишком фанатичны в отношении чистоты, совершенства и реализации своего собственного (часто довольно узкого) взгляда на мир и программирования на язык и все, кто его использует.
Одним из результатов является неспособность к компромиссу. Это приводит (помимо всего прочего) к примерно 10 000 языков и диалектов, которые достаточно различны, чтобы раздражать, но лишь в редких случаях достаточно различаются, чтобы один имел действительно значительное преимущество над другими. Многие также смотрят на реальный мир и решают, что, поскольку он не очень хорошо вписывается в функциональную модель, он в основном просто неправильный и лучше всего игнорируется.
Неспособность идти на компромисс также привела к появлению нескольких языков, которые абсолютно прекрасны для определенного типа проблемы (или нескольких конкретных типов проблем), но действительно отстой для многих других. Частично это, вероятно, вызвано самой функциональной моделью, но гораздо больше (по крайней мере, мне) вызвано базовым типом личности, который изначально привлекает эту область.
Это приводит к ряду проблем. Прежде всего, изучение «функционального программирования» имеет в основном философскую ценность. Для большинства других типов языков знание одного языка определенного жанра существенно помогает в изучении другого. Если в моем проекте используется язык XI, обычно я могу нанять человека, который знает язык Y (но не X), достаточно безопасно. С функциональными языками это гораздо менее верно. Возможно, вы хорошо знаете Эрланга, но все еще находите монады Хаскелла совершенно чужими и непостижимыми.
Соедините количество языков с ограниченной переносимостью талантов между ними, и вы получите уродливую ситуацию: для одного языка или диалекта почти невозможно сформировать «критическую массу», необходимую для того, чтобы сделать ее достаточно широко используемой. Это медленно меняется, но это все еще очень много , как Linux становится доминирующей настольной ОС - каждый год, люди приходят с убедительными аргументами , что в конце концов это будет год - и так же , как людей , которые предсказывали , что каждый год на протяжении десятилетий, они снова будут неправы. Это не означает, что этого (любого из них) никогда не случится, просто люди, которые смотрят на прогнозы и думают: «Нет, не в этом году», были теми, кто был прав до сих пор.
Возможно, было бы больше пересечения между функциональными языками, если бы было больше функциональных языков.
Барри Браун
5
Вы не можете быть «функциональными» без этой чистоты. Как только вы переступите черту, вся концепция развалится, и вы получите беспорядочный, параллельный, стандартный язык без каких-либо преимуществ.
Патрик Хьюз
7
Итак, ваша первая проблема заключается в том, что функциональные языки не настолько различны, чтобы иметь преимущество друг над другом, а ваша вторая проблема заключается в том, что они слишком разные, чтобы между ними было легко переходить?
Тихон Джелвис
2
Для меня этот ответ читается как напыщенная речь. Ваш аргумент был бы гораздо более убедительным, если бы вы привели несколько примеров.
Бенджамин Ходжсон
1
...roughly 10,000 languages and dialects that are enough different to annoy but only rarely enough different for one to have a truly significant advantage over the others...Нет, это звучит как все эти процедурные проблемы. Java, Scala, Kotlin, C ++, C #, Groovy, Cheddar, ES6, Ceylon, Python, список можно продолжать и продолжать - все это просто скучные итерации C, которые не решают реальных проблем. Это мое странное мнение, чтобы дополнить этот странный ответ: D
кошка
17
Я думаю, что причина, по которой функциональное программирование используется не очень широко, заключается в том, что оно слишком мешает вам. Трудно серьезно взглянуть, например, на Лисп или Хаскелл, не говоря «весь этот язык - одна большая инверсия абстракции». Когда вы устанавливаете базовые абстракции, ниже которых кодер не может получить нужную информацию, вы устанавливаете вещи, которые язык просто не может делать, и чем функциональнее язык, тем больше таких тенденций он имеет.
Взять, к примеру, Хаскелл. Во имя функциональной чистоты вам необходимо использовать головокружительные инверсии абстракций, которые никто не понимает, чтобы управлять состоянием и вводом / выводом, двумя наиболее фундаментальными частями любой компьютерной программы, которая взаимодействует с чем угодно! Это быстро стареет.
+1, хотя иногда я чувствую то же самое, когда программирую на императивных языках высокого уровня. Например, почему для fsck мне нужно создать один класс методов, который реализует интерфейс одного метода в Java, а не просто использовать указатель на функцию, как в C?
Дсимча
14
Я бы сказал, что дело не в том, что вы «не можете подняться» под этими абстракциями, скорее, это просто требует много работы. Мы привыкли собирать бананы и есть их на языке императива; Например, Haskell заставляет вас сначала заполнить 20-страничную форму, потому что она устанавливает приоритеты, гарантирующие, что ни один банан никогда не будет загадочным образом съеден, когда вы не смотрите. Что помогает при рассуждениях о бананах, но иногда вы просто голодны.
j_random_hacker
4
@dsimcha: это особенность Java, а не тенденция в императивных языках высокого уровня. На самом деле, языки высокого уровня, скорее всего, будут иметь функцию в качестве первоклассного объекта.
Мухаммед Алкарури
3
Необходимость монад в Haskell проистекает не из функциональной чистоты, а из того факта, что побочные эффекты и ленивая оценка - это два великолепных вкуса, которые НЕ имеют прекрасный вкус вместе. Монады форсируют последовательную оценку. (На самом деле их следует называть Построителями вычислений или что-то в этом роде. «Монада» - это паршивое имя для любого, кроме теоретика категории.) И вы можете с радостью делать FP без (сознательно используя) монад!
Фрэнк Шиарар
4
Стоит отметить одну вещь: учитывая эти «инверсии абстракций», язык может быть более ограниченным, но компилятор и среда выполнения имеют больше гарантий относительно вашего кода и могут делать больше. Это похоже на сборку мусора - на языке gc вы не можете просто использовать пространство malloc (что может быть полезно), но, в свою очередь, среда выполнения может управлять всей вашей памятью за вас, потенциально более эффективно, чем вы могли бы вручную. То же самое с функциональной чистотой.
Тихон Джелвис
8
При всем моем уважении, я думаю, что ваш вопрос плохо сформулирован. Функциональное программирование - это инструмент, а точнее набор инструментов, которые полезны для решения определенных видов задач. Наличие мнения об этом имеет смысл только в контексте конкретной проблемы или приложения. Иметь мнение против этого вообще, как иметь мнение против плоскогубцев или рывков.
Это логически обоснованный момент, но его можно исправить, если в конце предложения «ОП» указать «для проблем программирования, с которыми вы часто сталкиваетесь». (Неважно, что отдельные читатели столкнутся с разными проблемами, при условии, что они описывают, что они есть.)
j_random_hacker
4
Даже если бы я освоил его, я мог бы не захотеть использовать функциональный язык для коммерческого продукта по той простой причине, что он не очень понятен, и если бы я ожидал, что бизнес будет расти, я был бы обеспокоен возможностью найти других разработчиков, способных поддерживать или расширять его с течением времени.
Это немыслимо, и вы, вероятно, получите более высокий стандарт разработчика, потому что выпускник javaschool без реальных навыков хакерства не будет знать, с чего начать проект такого типа, но ограниченный пул способных разработчиков, безусловно, будет необходимым соображением с точки зрения бизнеса.
Функциональные программы часто проще тестировать. И они короче. Так что не согласен. Я думаю, что вы отвечаете на другой вопрос "Каково ваше самое сильное мнение против перехода к функциональному программированию?"
во-первых, я не принимаю никаких аргументов, касающихся программирования с учетом состояния и fp. Изучите монаду State в haskell, и вы найдете ряд новых интересных способов оценить влияние состояния на ваш код.
если бы я мог привести содержательный аргумент против fp, то было бы так, что изучение серьезного функционального языка, такого как haskell, похоже на обучение вождению автомобиля Формулы 1. Вдохновляющее и познавательное, но, к сожалению, бесполезное для повседневного промышленного кодирования, потому что в среднем Ваши коллеги водят Camrys и очень рады это сделать. все еще чрезвычайно трудно найти работу в среде, дружественной к фп, и я не вижу, как это изменится, если только один не захочет нанести удар самостоятельно или разыскивать некоторых из известных практиков фп.
я предполагаю, что мой ответ показывает меня как фанат fp. Я предлагаю серьезно подумать над реальным языком fp, таким как haskell, прежде чем беспокоиться о поиске причин, по которым вам этого не следует делать.
Я думаю, что ваш первый абзац точно описывает, что не так с мышлением FP. Мы не хотим «новых интересных способов оценить влияние состояния на наш код». Что это хотя бы значит?!? Мы просто хотим, чтобы государство было там и было легко доступным, потому что оно нам нужно, чтобы все было сделано.
Мейсон Уилер
2
У Камри, на которой я езжу, есть свои проблемы, но она не требует, чтобы я постоянно проверял под капотом утечки места . Haskell больше похож на язык, похожий на автомобиль F1, но на самом деле не может делать высокие обороты в течение длительного периода времени. :-P
j_random_hacker
1
@ Мейсон Уилер: «Мы не хотим новых интересных способов оценить влияние состояния на наш код». Вместо этого мы предпочитаем провести неделю, выискивая очень неприятную ошибку из-за нежелательного побочного эффекта (я говорю из личного опыта).
Джорджио
@brad clawsie: Я думаю, что весь вопрос управления побочными эффектами в FP может сделать кодирование намного более продуктивным: для написания требуется больше времени, но для исправления требуется меньше времени. К сожалению, сначала нужно приложить немало усилий для обучения, и у многих программистов нет такого долгосрочного мышления: все должно быть сделано быстро. В первый раз нет времени сделать это правильно, но всегда есть время отладить и исправить это позже. :-)
Джорджио
@ Мейсон Уилер: с функциональной точки зрения наличие общего состояния полезно только для целей оптимизации: копирование значений занимает слишком много времени и памяти, поэтому вы разделяете объект данных, чтобы избежать ненужного копирования. Но принудительное использование общего состояния, как правило, с самого начала является своего рода преждевременной оптимизацией.
Джорджио
2
Я большой поклонник и сторонник функционального программирования. Но вот мои пункты:
легко изучать
Языки программирования, такие как python и ruby (и многие другие языки), легко изучаются. Усовершенствованное функциональное программирование с такими языками, как Haskell, Agda, Coq, ATS и т. Д., Довольно сложно освоить. Некоторые используют термин «математическое структурированное программирование». Это легко, если вы знакомы с теорией категорий и абстрактной математикой, но довольно много работы, если вы не знаете, что такое, например, «монады».
программирование на языке сценариев может означать большую производительность.
В некоторых ситуациях использование языков сценариев, таких как python и ruby, может повысить производительность. Это означает быстрое создание прототипов и склейку различных пакетов или библиотек. Даже использование динамических языков (например, динамическое объектно-ориентированное программирование) может быть хорошей вещью в этом контексте. Обычно статическая типизация лучше, но сценарии с динамическими типами могут иметь положительный эффект.
деловые соображения
Программирование - это лишь небольшая часть успешных программных проектов. Программное обеспечение должно работать, пользователи должны быть счастливы, и это не обязательно зависит от используемого языка программирования. Менеджеры должны учитывать преимущества и риски при оценке новых технологий и языков программирования. Могут ли новые программисты быстро выучить новый язык программирования? Есть ли у компании опыт работы с технологиями? Есть ли риск, и будет ли трудно спорить с высшим руководством?
В бизнес-контексте функциональное программирование может использоваться в системах, которые добавляют к основным программным компонентам, например, к компонентам, которые не являются критически важными. Например, банк, который вряд ли изменит основное программное обеспечение, но добавит новые части (графический интерфейс, программное обеспечение для мониторинга и т. Д.) На новом языке программирования. (Возможно, есть исключения, но это мой опыт работы с банками.)
Кроме того, функциональное программирование очень полезно, когда формальная проверка является преимуществом или необходимостью.
Согласитесь с первым предложением, не согласитесь со вторым. Вы в принципе не можете сделать FP без сборки мусора.
dsimcha
Нет необходимости в том, чтобы в системе времени исполнения не было прозрачного управления памятью (со сборкой мусора), чтобы соответствовать «процедурной» метке, поэтому иронично, что вы таким образом сформулировали свое второе предложение. Бейсик является одним из таких языков.
Гуперникетес
«Вы в принципе не можете обойтись без FP». - Зачем?
Quant_Dev
+1 Функциональное программирование на самом базовом уровне - программирование без сохранения состояния. Я не думаю, что есть какой-либо язык, который не может сделать это до некоторой степени. Я написал функции на C, C ++, Java, ассемблере, C #, даже Basic. Все, что требуется, - это чтобы функция не имела побочных эффектов или сохраняла состояние между вызовами.
Майкл К
С другой стороны, если ваш язык полностью чистый, у компилятора есть больше возможностей в его оптимизации. Кроме того, код становится легче тестировать и рассуждать о. Будучи функциональным в течение действительно дают некоторые преимущества по сравнению с гибридным подходом; если вы все равно хотите, чтобы большая часть кода оставалась без состояния, вы можете пойти немного дальше и воспользоваться дополнительными преимуществами.
Тихон Джелвис
1
(и, безусловно, самое важное). Персонал программиста не обучен этим языкам или стилям.
Многие из функционирующих евангелистов оказываются «дырками» или кексами из-за того, как они пытаются продать функционал. Никто не любит дыру, и никто не собирается бросать деньги за кекс. Имейте в виду, мне действительно нравятся функциональные вещи, и я хотел бы их использовать, но я знаю, что на своем рабочем месте я был бы единственным человеком, который мог бы развивать его, не тратя денег на обучение (упорные продажи) и почти все хорошее ссылки обговорены у читателя.
Функционал придет, когда у нас будут сотни ядер, и поймем, что блокировки не масштабируются. Тогда параллельная обработка вложенных данных будет единственным способом использования программ «большого железа», и в этом функциональность будет превосходной.
FP - это круто в академических кругах, потому что это здорово - писать хорошие короткие программы, игнорируя при этом производительность. Нет никакого заговора против этого в реальном мире. Также, например, реализация некоторых вещей (например, радикальная сортировка) выглядит как полная боль в FP. Ох, и сгенерированный код IMHExperience sloooooooooooooooooooow.
Да, это явно не соответствует действительности. Код на Haskell обычно находится на одном уровне с C и Java, и намного быстрее, чем Python и его друзья. Распараллеливание также обычно тривиально, что потенциально дает еще большую скорость.
Тихон Джелвис
0
У некоторых кривая обучения довольно крутая, что занимает много времени (особенно если вы выходите из ООП; вы несколько раз покачаете головой, прежде чем получите смену парадигмы).
Даже несмотря на то, что я начал заниматься функциональным программированием (с Java и с Clojure), мне все еще трудно. Сообщество, похоже, не пишет такой выразительный код, как Java.
Похоже, что есть небольшая потеря выразительности и небольшое увеличение сложности.
Я думаю, что люди без предшествующего опыта программирования сказали бы, что ООП имеет более крутую кривую обучения, чем FP, поскольку FP ближе к математике. Я не понимаю, что вы имеете в виду под «Сообществом, кажется, не пишут столь же выразительный код, как Java», в чем ваша точка зрения?
Джонас
Я никогда не слышал, чтобы функциональный язык терял выразительность. Но тогда я никогда не использовал менее выразительный язык, чем Java, поэтому у меня может быть другое определение «выразительный».
Гленатрон
@Jonas - из-за одной простой вещи: сокращение имен для функций, переменных и т. Д. Я имею в виду, почему бы просто не назвать вещи для того, что они или должны делать? почему "pmap"?
Белун
1
@Belun: Это не имеет ничего общего с функциональным программированием. Вы должны обратиться к конкретному языку программирования. Карта - это функция, распространенная во многих функциональных языках программирования, и у нее хорошее имя . pmapВы имеете в виду, может быть параллельный вариант.
Джонас
я сказал "сообщество, кажется, не пишет". это означает, что это то, что я испытал, и это относится к сообществу, которое я наблюдал. это не должно относиться ко всем, хотя я сомневаюсь в этом. это имеет отношение к функциональному программированию, это как его стиль
Belun
0
Несмотря на то, что у меня мало опыта работы с функциональными языками программирования (я знаю некоторые Haskell и Lisp), я нахожу парадигму FP очень мощной и часто более элегантной, чем другие парадигмы. Хотел бы я иметь возможность работать над серьезным проектом с использованием FP.
Единственная область, в которой у меня есть серьезные сомнения относительно эффективности FP, заключается в том, как он может работать со сложными структурами данных, которые не могут быть определены индуктивно, например, с графиками. Например, если мне нужно реализовать алгоритм, который работает на большом графе, возможно, проходя по нему и делая небольшие локальные изменения, мне интересно, может ли подход FP соответствовать императивному подходу, при котором программе разрешено перемещаться с узла на узел с помощью указателей.
Ответы:
Проблема в том, что наиболее распространенный код по своей природе включает в себя государственные приложения, игры, пользовательский интерфейс и т. Д. Нет проблем с тем, что некоторые части приложения являются чисто функциональными; на самом деле, большинство приложений может принести пользу как минимум в одной области. Но навязывание парадигмы повсеместно кажется нелогичным.
источник
Проблема с функциональным программированием не в самом функциональном программировании - это большинство людей, которые делают это и (что еще хуже) большинство людей, которые создают языки, на которых это делается.
Проблема связана с тем фактом, что, несмотря на то, что люди очень умные (иногда совершенно блестящие), слишком многие люди слишком фанатичны в отношении чистоты, совершенства и реализации своего собственного (часто довольно узкого) взгляда на мир и программирования на язык и все, кто его использует.
Одним из результатов является неспособность к компромиссу. Это приводит (помимо всего прочего) к примерно 10 000 языков и диалектов, которые достаточно различны, чтобы раздражать, но лишь в редких случаях достаточно различаются, чтобы один имел действительно значительное преимущество над другими. Многие также смотрят на реальный мир и решают, что, поскольку он не очень хорошо вписывается в функциональную модель, он в основном просто неправильный и лучше всего игнорируется.
Неспособность идти на компромисс также привела к появлению нескольких языков, которые абсолютно прекрасны для определенного типа проблемы (или нескольких конкретных типов проблем), но действительно отстой для многих других. Частично это, вероятно, вызвано самой функциональной моделью, но гораздо больше (по крайней мере, мне) вызвано базовым типом личности, который изначально привлекает эту область.
Это приводит к ряду проблем. Прежде всего, изучение «функционального программирования» имеет в основном философскую ценность. Для большинства других типов языков знание одного языка определенного жанра существенно помогает в изучении другого. Если в моем проекте используется язык XI, обычно я могу нанять человека, который знает язык Y (но не X), достаточно безопасно. С функциональными языками это гораздо менее верно. Возможно, вы хорошо знаете Эрланга, но все еще находите монады Хаскелла совершенно чужими и непостижимыми.
Соедините количество языков с ограниченной переносимостью талантов между ними, и вы получите уродливую ситуацию: для одного языка или диалекта почти невозможно сформировать «критическую массу», необходимую для того, чтобы сделать ее достаточно широко используемой. Это медленно меняется, но это все еще очень много , как Linux становится доминирующей настольной ОС - каждый год, люди приходят с убедительными аргументами , что в конце концов это будет год - и так же , как людей , которые предсказывали , что каждый год на протяжении десятилетий, они снова будут неправы. Это не означает, что этого (любого из них) никогда не случится, просто люди, которые смотрят на прогнозы и думают: «Нет, не в этом году», были теми, кто был прав до сих пор.
источник
...roughly 10,000 languages and dialects that are enough different to annoy but only rarely enough different for one to have a truly significant advantage over the others...
Нет, это звучит как все эти процедурные проблемы. Java, Scala, Kotlin, C ++, C #, Groovy, Cheddar, ES6, Ceylon, Python, список можно продолжать и продолжать - все это просто скучные итерации C, которые не решают реальных проблем. Это мое странное мнение, чтобы дополнить этот странный ответ: DЯ думаю, что причина, по которой функциональное программирование используется не очень широко, заключается в том, что оно слишком мешает вам. Трудно серьезно взглянуть, например, на Лисп или Хаскелл, не говоря «весь этот язык - одна большая инверсия абстракции». Когда вы устанавливаете базовые абстракции, ниже которых кодер не может получить нужную информацию, вы устанавливаете вещи, которые язык просто не может делать, и чем функциональнее язык, тем больше таких тенденций он имеет.
Взять, к примеру, Хаскелл. Во имя функциональной чистоты вам необходимо использовать головокружительные инверсии абстракций, которые никто не понимает, чтобы управлять состоянием и вводом / выводом, двумя наиболее фундаментальными частями любой компьютерной программы, которая взаимодействует с чем угодно! Это быстро стареет.
источник
При всем моем уважении, я думаю, что ваш вопрос плохо сформулирован. Функциональное программирование - это инструмент, а точнее набор инструментов, которые полезны для решения определенных видов задач. Наличие мнения об этом имеет смысл только в контексте конкретной проблемы или приложения. Иметь мнение против этого вообще, как иметь мнение против плоскогубцев или рывков.
источник
Даже если бы я освоил его, я мог бы не захотеть использовать функциональный язык для коммерческого продукта по той простой причине, что он не очень понятен, и если бы я ожидал, что бизнес будет расти, я был бы обеспокоен возможностью найти других разработчиков, способных поддерживать или расширять его с течением времени.
Это немыслимо, и вы, вероятно, получите более высокий стандарт разработчика, потому что выпускник javaschool без реальных навыков хакерства не будет знать, с чего начать проект такого типа, но ограниченный пул способных разработчиков, безусловно, будет необходимым соображением с точки зрения бизнеса.
источник
Пора торговать
Сложно избавить весь ИТ-ландшафт от процедурного кода и мантр.
источник
во-первых, я не принимаю никаких аргументов, касающихся программирования с учетом состояния и fp. Изучите монаду State в haskell, и вы найдете ряд новых интересных способов оценить влияние состояния на ваш код.
если бы я мог привести содержательный аргумент против fp, то было бы так, что изучение серьезного функционального языка, такого как haskell, похоже на обучение вождению автомобиля Формулы 1. Вдохновляющее и познавательное, но, к сожалению, бесполезное для повседневного промышленного кодирования, потому что в среднем Ваши коллеги водят Camrys и очень рады это сделать. все еще чрезвычайно трудно найти работу в среде, дружественной к фп, и я не вижу, как это изменится, если только один не захочет нанести удар самостоятельно или разыскивать некоторых из известных практиков фп.
я предполагаю, что мой ответ показывает меня как фанат fp. Я предлагаю серьезно подумать над реальным языком fp, таким как haskell, прежде чем беспокоиться о поиске причин, по которым вам этого не следует делать.
источник
Я большой поклонник и сторонник функционального программирования. Но вот мои пункты:
легко изучать
Языки программирования, такие как python и ruby (и многие другие языки), легко изучаются. Усовершенствованное функциональное программирование с такими языками, как Haskell, Agda, Coq, ATS и т. Д., Довольно сложно освоить. Некоторые используют термин «математическое структурированное программирование». Это легко, если вы знакомы с теорией категорий и абстрактной математикой, но довольно много работы, если вы не знаете, что такое, например, «монады».
программирование на языке сценариев может означать большую производительность.
В некоторых ситуациях использование языков сценариев, таких как python и ruby, может повысить производительность. Это означает быстрое создание прототипов и склейку различных пакетов или библиотек. Даже использование динамических языков (например, динамическое объектно-ориентированное программирование) может быть хорошей вещью в этом контексте. Обычно статическая типизация лучше, но сценарии с динамическими типами могут иметь положительный эффект.
деловые соображения
Программирование - это лишь небольшая часть успешных программных проектов. Программное обеспечение должно работать, пользователи должны быть счастливы, и это не обязательно зависит от используемого языка программирования. Менеджеры должны учитывать преимущества и риски при оценке новых технологий и языков программирования. Могут ли новые программисты быстро выучить новый язык программирования? Есть ли у компании опыт работы с технологиями? Есть ли риск, и будет ли трудно спорить с высшим руководством?
В бизнес-контексте функциональное программирование может использоваться в системах, которые добавляют к основным программным компонентам, например, к компонентам, которые не являются критически важными. Например, банк, который вряд ли изменит основное программное обеспечение, но добавит новые части (графический интерфейс, программное обеспечение для мониторинга и т. Д.) На новом языке программирования. (Возможно, есть исключения, но это мой опыт работы с банками.)
Кроме того, функциональное программирование очень полезно, когда формальная проверка является преимуществом или необходимостью.
источник
Я не против FP как полезной парадигмы, но я против нее как единственной парадигмы, доступной в языке программирования.
Это дает преимущества в решении многих проблем. Однако FP может и был применен в процедурных языках, таких как C.
источник
Функционал придет, когда у нас будут сотни ядер, и поймем, что блокировки не масштабируются. Тогда параллельная обработка вложенных данных будет единственным способом использования программ «большого железа», и в этом функциональность будет превосходной.
источник
FP - это круто в академических кругах, потому что это здорово - писать хорошие короткие программы, игнорируя при этом производительность. Нет никакого заговора против этого в реальном мире. Также, например, реализация некоторых вещей (например, радикальная сортировка) выглядит как полная боль в FP. Ох, и сгенерированный код IMHExperience sloooooooooooooooooooow.
источник
У некоторых кривая обучения довольно крутая, что занимает много времени (особенно если вы выходите из ООП; вы несколько раз покачаете головой, прежде чем получите смену парадигмы).
Даже несмотря на то, что я начал заниматься функциональным программированием (с Java и с Clojure), мне все еще трудно. Сообщество, похоже, не пишет такой выразительный код, как Java.
Похоже, что есть небольшая потеря выразительности и небольшое увеличение сложности.
источник
pmap
Вы имеете в виду, может быть параллельный вариант.Несмотря на то, что у меня мало опыта работы с функциональными языками программирования (я знаю некоторые Haskell и Lisp), я нахожу парадигму FP очень мощной и часто более элегантной, чем другие парадигмы. Хотел бы я иметь возможность работать над серьезным проектом с использованием FP.
Единственная область, в которой у меня есть серьезные сомнения относительно эффективности FP, заключается в том, как он может работать со сложными структурами данных, которые не могут быть определены индуктивно, например, с графиками. Например, если мне нужно реализовать алгоритм, который работает на большом графе, возможно, проходя по нему и делая небольшие локальные изменения, мне интересно, может ли подход FP соответствовать императивному подходу, при котором программе разрешено перемещаться с узла на узел с помощью указателей.
источник