Откровения Guido van Rossum о функциональных языках

[alexey_rom]

Цитата из Masterminds of Programming:

Python probably has the reputation of supporting functional programming based on the inclusion of lambda, map, filter and reduce in the language, but in my eyes these are just syntactic sugar, and not the fundamental building blocks that they are in functional languages. The more fundamental property that Python shares with Lisp (not a functional language either!) is that functions are first-class objects, and can be passed around like any other object. This, combined with nested scopes and a generally Lisp-like approach to function state, makes it possible to easily implement concepts that superficially resemble concepts from functional languages, like currying, map, and reduce. The primitive operators that are necessary to implement those concepts are built into Python, where in functional languages, those concepts are the primitive operations. You can write reduce() in a few lines of Python. Not so in a functional language.

Перевод:

Считается, что Python поддерживает функциональное программирование, скорее всего из-за включения lambda, map, filter и reduce в язык. Но с моей точки зрения это просто синтаксический сахар, а не основные строительные блоки, которыми они являются в функциональных языках. Куда более фундаментальным свойством, общим для Python и Lisp (который тоже не функциональный язык!), является то, что функции — объекты первого класса, и могут передаваться так же, как и любой другой объект. Это, в сочетании с вложенными областями видимости и в общем близким к Lisp'у подходом к состоянию функций, позволяет легко реализовать возможности, поверхностно напоминающие о таких возможностях функциональных языков, как карринг, map, и reduce. В Python встроены примитивные конструкции, необходимые для реализации этих понятий; а вот в функциональных языках они сами и являются примитивными конструкциями. В Python достаточно нескольких строк, чтобы написать reduce(). В функциональных языках это не так.

Comments

[rmihael.livejournal.com]

"В Python достаточно нескольких строк, чтобы написать reduce(). В функциональных языках это невозможно".
Он что, прикалывается?

[alexey-rom.livejournal.com]

Учитывая остальное, что он говорит про ФП — похоже, что нет :(

[alexey-rom.livejournal.com]

Впрочем, привёл перевод чуть ближе к буквальному, поскольку кто-то утверждает, что понял эту фразу как "в функциональных языках нет необходимости писать reduce". По-моему, неправильно, но оставлю этот вариант.

[sdfgh153.livejournal.com]

Ну я всегда подозревал, что от него ничего хорошего не дождешься.

[archimag-dev.blogspot.com (from livejournal.com)]

О, отлично, теперь буду на него ссылаться, доказывая неверующим, что Common Lisp не является функциональным языком ;)

[jtootf.livejournal.com]

в свете данного абзаца это, пожалуй, не лучшая идея :)

[archimag-dev.blogspot.com (from livejournal.com)]

А я буду опускать последние три предложения. Принципиально то его рассуждения верны.

[lionet.livejournal.com]

Currying — это можно считать "примитивной операцией" в функциональных языках, действительно. Но не map и не reduce. Так что он way out of line.

[dsorokin.blogspot.com (from livejournal.com)]

Да, вообще, нелучшая идея доказывать отрицание. Позитива в этом мало :)

[lionet.livejournal.com]

Да хоть на http://fprog.ru/ можно ссылаться. Там на первой же странице об этом написано.

[archimag-dev.blogspot.com (from livejournal.com)]

Хм, на первой странице такого не вижу :( Кажется, в первом журнале было что-то на тему того, что он остался в прошлом (с позиций ФП), хотя на самом деле он просто свернул в другую сторону ;)

[lionet.livejournal.com]

Во втором номере журнала была провокация, чтобы получить лисперов в четвёртый. А на сайте во второй же строке заголовка это написано.

[archimag-dev.blogspot.com (from livejournal.com)]

А!!! В упор не замечал :)))

[alexey-rom.livejournal.com]

Если посмотреть ещё на предыдущий абзац: "functional languages are all about doing as much as possible at the compile time" -- то Common Lisp (приличная часть использования макросов) и C++ (шаблоны) получаются куда более функциональные чем, например, Erlang.

[archimag-dev.blogspot.com (from livejournal.com)]

Шаблоны в С++ это действительно отдельный функциональный язык ;) А в Common Lisp термин "compile time" вообще нельзя употреблять, ибо есть только :COPMILE-TOPLEVEL, :LOAD-TOPLEVEL и :EXECUTE (а термин компиляции означает просто процесс раскрытие макросов).

[alexey-rom.livejournal.com]

А в Common Lisp термин "compile time" вообще нельзя употреблять
Если HyperSpec и CLtL употребляют, то мне тоже можно :)

[archimag-dev.blogspot.com (from livejournal.com)]

Ну только если понимать, что "compile time" в CL очень далеко от аналогичного понятия в том же C++. С точки зрения CL компиляция - это процесс раскрытия макросов. SBCL, например, выражение, введённое в REPL по-умолчанию сначала компилирует в машинный код, а только потом исполняет, но это не то же самое, что раскрытие макросов. Но, даже процесс раскрытия макросов (compile time) происходит во время исполнения и, вообще говоря, зависит от текущего состояния образа, и может иметь произвольные сайд-эффекты.

[alexey-rom.livejournal.com]

Да, так я и понимаю.

[ivan-gandhi.livejournal.com]

Он сделал свой язык, вполне компактный, юзабельный, и, при определённой сноровке, пригодный на вполне хорошие проекты. Но будущего нет ни у Питона, ни у Гвидо. Спросите его про монаду. Он не знает и не хочет знать про монаду. Ну и т.д. Так что язык, как бы он ни был хорош, останется набором хороших штучек, соответствующих передовым понятиям примерно 2000-го года.

[(Anonymous)]

> Но будущего нет ни у Питона, ни у Гвидо.

Размер Python-community, а также размер банковского счёта самого Гвидо свидельствует об обратном ;)

[zevlg.livejournal.com]

всё нормально старикан сказал. Я вон для geo задачи (с fprog.ru) накатал парсер файлов с полигонами в три строчки! на питоне - сомневаюсь, что такое возможно на любом ФП:

def contours(f):
    def notEND(): return takewhile(lambda x: x[:3] != "END", f)
    def contour(): return [map(float, l.split()) for l in notEND()]       
    return [(contour(), l[0] == "!") for l in notEND()]

[lionet.livejournal.com]

Круто, да. Лаконично. В функциональном стиле. Но мутабельные итераторы подсирают чуток понимание кода. Вот хаскельный вариант:

countours = map excl . filter ((/=) ["END"]) . groupBy notEND . words
excl (h:t) = (map read t :: [Double], head h == '!')
notEND x y = x /= "END" && y /= "END"

[alexey-rom.livejournal.com]

Серьёзно сомневаетесь?

contours f = [ (contour p, head (head p) == '!') | p <- map lines (endBy "END" f)]
               where contour p = map (read :: String -> Double) (words p)

endBy из Data.List.Split, а не из стандартной библиотеки, но в одну строчку пишется.

[alexey-rom.livejournal.com]

Чуть ошибся в contour, здесь ведь p -- список строк:

contour p = map (map (read :: String -> Double) . words) (tail p)

[zevlg.livejournal.com]

не пробовал, но кажется, что на завершающем файл ENDе обломается и выдаст неправильный контур

если серьёзно, то конечно не сомневался, но хотелось чтобы кто-нибудь *подоказывал* :)

[alexey-rom.livejournal.com]

не пробовал, но кажется, что на завершающем файл ENDе обломается и выдаст неправильный контур
Ну тогда (init $ endBy "END" f).

[alexey-rom.livejournal.com]

но хотелось чтобы кто-нибудь *подоказывал* :)
:)

[zevlg.livejournal.com]

там ещё на реальных файлах в конце END бывает \r, поэтому у меня x[:3]

[lionet.livejournal.com]

Вот блин. Спасибо за Data.List.Split. В хугле его нет, кстати.

[alexey-rom.livejournal.com]

Он смотрит только ограниченный набор пакетов.

Using the standard web interface, Hoogle searches: array, arrows, base, bytestring, Cabal, cgi, containers, directory, filepath, haskell-src, HUnit, mtl, old-locale, old-time, packedstring, parallel, parsec, pretty, process, QuickCheck, random, stm, template-haskell, time, xhtml

[palm-mute.livejournal.com]

В hayoo - есть.

[lionet.livejournal.com]

Считай, что нет:

http://holumbus.fh-wedel.de/hayoo/hayoo.html#0:%5Ba%5D%20-%3E%20%5Ba%5D%20-%3E%20%5B%5Ba%5D%5D

Как можно найти endBy, если знаешь только примерную сигнатуру?

[palm-mute.livejournal.com]

Никак, hayoo по типам не ищет.

[palm-mute.livejournal.com]

С последним заявлением я поторопился

[b-al-u.livejournal.com]

Но нельзя в несколькострок сделть лямбду :)

[ulysses4ever.livejournal.com]

> В Python встроены примитивные конструкции, необходимые для реализации этих понятий; а вот в функциональных языках они сами и являются примитивными конструкциями. В Python достаточно нескольких строк, чтобы написать reduce(). В функциональных языках это не так.
Одному мне кажется, что в первом предложении он утверждает, что Пайтон более низкоуровневый, чем «функциональные языки», а во вторых двух — что он более высокоуровневый — сиречь противоречит себе?

[alexey-rom.livejournal.com]

Нет, по-моему, во вторых двух предложениях он утверждает, что ФЯ слишком высокоуровневые, чтобы внутри них реализовать reduce().

[archimag-dev.blogspot.com (from livejournal.com)]

На самом деле он просто утверждает, что Python не является ФЯП (есть такое поверье), и что map/reduce не являются признаком ФЯП (и такое поверье тоже есть). Вряд ли стоит выискивать здесь что-либо ещё.

[alexey-rom.livejournal.com]

Да нет, он всё же утверждает, что reduce (т.е. foldl) нельзя написать в несколько строчек на функциональных языках. Что, собственно, людей (включая меня) и впечатлило :)

[zevlg.livejournal.com]

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

[ivan-gandhi.livejournal.com]

Гвидо хороший человек, но образования у него не хватает, и это, конечно, ставит крест на будущем питона.