Я заинтересован в функциональном программировании и решил наладить отношения с Haskell. У меня болит голова ... но я в итоге получу это ... У меня есть одно любопытство, почему синтаксис такой загадочный (в отсутствии другого слова)?
Есть ли причина, почему он не более выразительный , более близкий к человеческому языку?
Я понимаю, что FP хорош в моделировании математических понятий и заимствовал некоторые из его кратких средств выражения, но все же это не математика ... это язык.
Ответы:
Функциональные языки, такие как Хаскелл и его предшественница Миранда, выросли из математической концепции лямбда-исчисления . Со страницы Википедии:
Из-за этой истории на синтаксисы этих функциональных языков (и функциональных элементов более императивных языков) сильно влияют математические обозначения, используемые лямбда-исчислением.
Точность, с которой математические записи и компьютерные языки могут описывать требования, и точность, с которой компьютеры требуют написания своих инструкций, хорошо коррелируют друг с другом. Неточность естественного языка, однако, создает огромный барьер для его использования для программирования компьютеров. Даже (возможно) наиболее успешные среды программирования на естественном языке, такие как Wolfram Alpha, нуждаются в значительном опыте в предметной области для эффективного использования.
источник
Синтаксис Haskell это близко к человеческому языку. Он специально разработан для того, чтобы напоминать математическую нотацию, которая является языком, разработанным людьми (таким образом, человеческим языком ) для точного выражения тех концепций, на которых построен Haskell.
Вы можете показать кусок кода на Haskell любому математику или логику, и он сможет понять его, даже если он никогда не слышал о Haskell и абсолютно ничего не знает о программировании, информатике или даже компьютерах.
С другой стороны, вы можете показать любому математику или логику фрагмент кода, подобный следующему:
и он будет совершенно сбит с толку, говоря: «Это не имеет смысла, нет
x
такого, чтоx
равноx
плюс1
».Независимо от того, является ли какое-то конкретное обозначение «загадочным» или нет, это вопрос мнения и знакомства.
источник
where
позволяет сконцентрировать сущность функция в одной строке.x = infinity
это действительно решает уравнение.Я думаю, что одна вещь, с которой вы, вероятно, сталкиваетесь, - это то, с чем я столкнулся при изучении функционального программирования: с функциональным программированием вы можете (и почти должны) думать / работать на более высоком уровне, чем с императивным программированием.
То, что вы находите менее выразительным, я думаю, на самом деле более выразительно: вам не нужно подробно описывать каждую мелочь и вы можете делать больше с меньшим количеством кода в функциональном программировании - у вас больше возможностей для написания.
Например, я мог бы написать обязательно:
который полностью читается как английский.
Версия Haskell может быть (и это не допустимый Haskell, но только для синтаксического сравнения):
который требует меньше кода и меньше детализации - мне не нужно разбивать элементы на циклы и их переменную (и) (
for each (...)
),map
функция позаботится об этом за меня.Работа на этом уровне может занять некоторое привыкание. Если это поможет, Haskell был, вероятно, самым сложным временем, когда я изучал новый язык с тех пор, как начал программировать, и я знаю> 10 языков (включая Lisp). Это стоило изучения, хотя.
источник
В настоящее время я вхожу в борьбу со Scala, поэтому я могу сочувствовать. По крайней мере, со Scala я могу вернуться к императивному стилю, когда движение становится слишком жестким.
Я думаю, что здесь есть несколько сил:
Разработчики функциональных языков обязательно имеют сильный математический фон, поэтому они используют математические обозначения, которые для них естественны.
Большая выразительность (т.е. сила высказываний, а не близость к английскому) любого языка (IMO) имеет соответствующую цену в крутизне кривой обучения. Terseness - высоко ценимое качество в Scala, причем многие вещи являются необязательными.
Функциональные языки просто делают вещи совсем по-другому, поэтому основные операции не отображаются на императивные конструкции.
источник
Если я правильно понял ваш последний комментарий, ваш вопрос заключается в том, почему Haskell часто использует символические операторы в тех местах, где он может также использовать буквенно-цифровые ключевые слова (или имена функций)?
Что касается ключевых слов, одним из ответов будет то, что ключевые слова не позволяют использовать определенные слова в качестве имен переменных. Например, меня всегда раздражает, когда я хочу вызывать свои переменные
from
иto
в языках, где одним из них является ключевое слово - как в Python.Еще одна причина для символических операторов в целом - краткость. Это на самом деле не применимо в ваших конкретных примерах понимания списка (
<-
не корочеin
), но во многих случаях это так.Еще одна причина - удобочитаемость. Это может показаться нелогичным, потому что символические операторы часто сложнее выучить, поскольку их «имена» на самом деле ничего не говорят вам о том, что они делают (в то время как имя функции обычно будет), но как только вы узнаете, что делает данный оператор, выражения с инфиксными символическими операторами часто легче проанализировать для человека, чем с множеством вызовов буквенно-цифровых префиксных функций, поскольку операторы легче визуально отличить от операндов таким образом. Например, большинство людей согласятся с тем, что
2 * 3 + 4
их легче прочитать, чемadd (mult 2 3) 4
илиadd(mult(2, 3), 4)
.источник
Императивные языки программирования в большинстве своем не ближе к естественным, чем, скажем, Haskell.
Тем не менее, некоторые из них предназначены для более близкого к английскому языку: например, Cobol и Hypercard. Уроки, которые я извлек бы из этих примеров:
Сообщается, что компьютерный язык Perl был разработан с учетом некоторых более тонких аспектов естественного языка . Я бы сказал, что Perl работает лучше, чем Cobol или Hypercard, но в целом люди по-разному относятся к Perl.
источник
Я думаю, что Haskell становится настолько похожим на человеческий язык, насколько это возможно без введения сумасшедшего синтаксиса. Это действительно идет вразрез с этим, например, с
where
предложением отложить определение и с синтаксисом понимания списка, который я и написал на доске. Это также позволяет избежать посторонних символов, таких как фигурные скобки, и имеет свободное использование отступов. Типичный пример - быстрая сортировка:Признаюсь, это простой пример, но я не знаю другого языка, который бы делал его таким читабельным, как этот.
В Haskell трудно читать более сложные вещи, но это связано с системой типов, ограниченным IO, а не с синтаксисом вообще.
Во всяком случае, я бы сказал, что Haskell пожертвовал синтаксической простотой, чтобы приспособить синтаксис, который больше похож на человеческий язык. Подобная языку схема имеет синтаксис, который очень далек от того, что написал бы человек, но объяснить его правила действительно просто.
источник
++ [p] ++
?Я думаю, что разница связана с тем, как функциональное / декларативное программирование делает утверждения о проблеме, как будто это математическая проблема, где императивное программирование описывает процесс . В деловом мире компьютерные программы обертывают или заменяют физические процессы, поэтому вы можете найти язык, который отражает это, чтобы быть более интуитивным.
Оказывается, что функциональный стиль позволяет безопасно использовать несколько процессоров (поскольку он минимизирует изменчивость и побочные эффекты) - то, что мы увидим больше в будущем. Кроме того, большинство современных функциональных языков имеют коллекции с итераторами, в которые вы можете передавать функции. Эти методы могут очень эффективно распределить рабочую нагрузку между несколькими процессорами, даже не подозревая об этом.
источник