Почему smalltalk не является функциональным языком программирования?

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

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

Общепринятого определения языка функционального программирования не существует.

Если вы определяете функциональный язык как язык, который поддерживает функции первого класса, тогда да, Smalltalk * является * функциональным языком.

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

Я рекомендую вам прочитать следующие связанные сообщения в блоге (а также комментарии под ними):

• Scala не является функциональным язык

• Erlang не работает

• Обсуждение Reddit на тему «Erlang не работает. функциональный "

Smalltalk может не быть «чисто функциональным языком» (чем бы он ни был). Однако естественное использование Smalltalk часто приводит к созданию функционального кода. (Я полагаю, что в Scala люди назвали бы «объектно-функциональным».)

Например, класс Point Squeak имеет функциональный API: такие методы, как 1 @ 1 translateBy: 1 @ 1 , возвращают новые точки с новое состояние вместо изменения внутреннего состояния. (Это делает Point практически неизменяемым, поскольку единственный способ изменить внутреннее состояние объекта - использовать механизмы отражения, такие как #instVarAt:.)

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

У многих людей есть так много определений термина «функциональный язык программирования», что вопрос «является ли Foo FPL» таким же бесполезным вопросом, как «является ли Foo объектно-ориентированным языком».

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

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

Сказав это, да, вы можете писать на Smalltalk нефункционально. Это допускает изменяемое состояние. Мешает ли это называть Smalltalk функциональным языком? Если это так, то ни один из этих языков не работает: Common Lisp, Erlang (общее состояние через словарь процесса, ets / dets).

Итак, вкратце, Smalltalk - это FPL , потому что:

• Функции - это первоклассные сущности (объекты в Smalltalk - CompiledMethods или BlockClosures, если быть точным).
• Smalltalk поддерживает замыкания (он называет их блоками).
• Smalltalk позволяет функционально писать в естественной идиоматической манере.

и Smalltalk не является FPL , потому что:

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

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

Изменить: я не понимаю, что igouy нуждается в определениях именованных функций, кроме как путем определения методов для объекта. Но в любом случае, начнем:

Smalltalk at: #func put: [:x | x + 1].
func value: 1.

Я видел некоторые сходства между Smalltalk и FPL, а именно замыкания

. Существует более основное сходство - каждое сообщение Smalltalk всегда возвращает значение.

Но теперь посмотрите на Принципы проектирования Smalltalk

[Smalltalk] отправляет имя желаемую операцию вместе с любыми аргументы, как сообщение к номеру, с пониманием того, что приемник лучше всех умеет выполнять желаемая операция.

Это описывает то, что вы думаете о функциональном программировании?

@Frank Shearar - Это описывает Erlang слишком. Erlang теперь нефункционален?

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

Что необходимо, чтобы рассматривать его как такой?

• способ объявления функций, а не способ объявления методов в классе

• способ структурировать программу вокруг функций, а не вокруг объектов

@Missing Faktor - но не func в этом примере названный function?

|func v|
func := [:x | x + 1].
v := func value: 5.

Нет func - это локальная переменная. Вы связали анонимную функцию с локальной переменной func .

|func v|
func := [:x | x + 1].
func := 2.
v := func value: 5.

Чтобы увидеть разницу, посмотрите этот пример на Erlang , в котором показаны как анонимная функция, так и именованная функция.

Спасибо всем за ответы.

Я добавлю сюда свое, что в основном является моим (возможно, отсутствующим) пониманием вашего.

Я думаю, что критерии для обозначения чего-либо ОО или ФП - это способ построения «материала» с использованием языка; не то, насколько легко или сложно это сделать, я имею в виду используемую ментальную парадигму.

Например, как показывают ссылки, набрать что-либо в Scala может быть сложнее, чем в OCaml, но это не делает его менее FPL (может быть неполным или нечистым, но определенно функциональным); потому что цель Scala - использовать функции в качестве основных строительных блоков, а не объектов.

С другой стороны, упрощение написания функции на языке не делает ее функциональной, если стиль или цель заключается в использовании других артефактов. Smalltalk, например, позволяет очень легко написать анонимный блок или предоставить подключаемый компаратор сортировки, но это не делает его НИКАКИМ функциональным, потому что основное внимание уделяется использованию объектов и передаче сообщений. Блокировка - это просто механизм для кодирования этих сообщений (не функций), даже если они выглядят так, как будто они были функциями.

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

Что еще хуже, Scala также использует парадигму объектно-ориентированного программирования, чтобы упростить массовым программистам (Java, C ++, C #) прыжок, и, если вы видите, он имел гораздо больший успех, чем любой другой FPL сделали.И, конечно же, это было благодаря Java (ИМХО, если Clojure будет успешным, будет по той же причине, что и JVM)

В заключение : язык программирования можно классифицировать по парадигме, которую он использует для создания «вещей». ". Существуют чистые языки, такие как [Smalltalk: OO, Haskell: Functional, C: Procedural], или гибриды, такие как Scala, или мультипарадигмальные, такие как C ++, Ruby, Python.

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

Чтобы ответить на этот вопрос, чтобы его можно было считать функциональным, Smalltalk должен был бы использовать функции в качестве строительных блоков, чего не происходит, потому что он использует объекты.