среда, 23 декабря 2009 г.

Элементы функциональных языков. Резюме.

Дочитал таки статью "Элементы функциональных языков", мысль по прочтению только одна: если бы хаскелисты освоили Common Lisp, то большинство из них забыло бы про Haskell как про страшный сон :)
Автор: на
Ярлыки: ,

19 комментариев:

  1. Анонимный23 декабря 2009 г. в 14:21

    Сомнительно. В своё время я дал себе труд ознакомиться с этим языком. Он вполне подпадает под известный критерий "язык, который ничему не учит, незачем изучать".

    ОтветитьУдалить
  2. Анонимный23 декабря 2009 г. в 20:07

    Вы оба не правы.
    Лисп и Хаскель слишком разные языки, чтобы их адепты могли здраво воспринимать точки зрения друг друга.

    ОтветитьУдалить
  3. Nikita23 декабря 2009 г. в 22:37

    Если Вы говорите о статье Евгения Кирпичева, то не могу с Вами согласиться.

    Я лично знаю этого человека и ручаюсь, что он отлично знает и понимает, на что способен lisp, однако же он выбирает хаскелл.

    Мне кажется этот выбор сделан поэтому (цитата цитаты из твиттера Е. Кирпичева @jkff):

    Maybe the most important contribution of Haskell is that it gets programmers in touch with their mathematical side. @TacticalGrace

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

    ОтветитьУдалить
  4. archimag23 декабря 2009 г. в 23:46

    @Keip
    > он отлично знает и понимает,
    > на что способен lisp

    Судя по статье, это совсем не так. В предыдущем посте я указал на явный ляп с динамической областью видимости, который однозначно показывает, что автор совершенно не знаком с Common Lisp. Другой пример: в главе про сопоставление с образцом упомянуты виртуальные функции и даже (о, ужас!) паттерн Visitor, но ни слова про generic-функции в CL. Вероятно, он знаком с Scheme, но Common Lisp это сильно другой язык. Scheme я сам не люблю и никогда за него не ратовал.

    Кстати, языка lisp в данный момент не существует, а разница между различными диалектами очень велика.

    ОтветитьУдалить
  5. Nikita24 декабря 2009 г. в 00:50

    Вы не в первый раз оспариваете право хаскелла на жизнь

    ОтветитьУдалить
  6. archimag24 декабря 2009 г. в 01:07

    @Keip
    > Вы не в первый раз оспариваете право
    > хаскелла на жизнь

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

    ОтветитьУдалить
  7. Nikita24 декабря 2009 г. в 02:35

    ну хотя бы вот это:
    http://hackage.haskell.org/cgi-bin/hackage-scripts/package/jarfind-0.1.0.0

    не код чтоли?

    ОтветитьУдалить
  8. Nikita24 декабря 2009 г. в 02:38

    да вообще на весь ресурс посмотрите:

    http://hackage.haskell.org/packages/archive/pkg-list.html

    не марсиане же писали - тоже такие де программисты

    так что код есть, и не надо говорить, что его нет

    ОтветитьУдалить
  9. Nikita24 декабря 2009 г. в 02:40

    я специально дал ссылку на программу Е. Кирпичева, чтобы Вы видели, что пишут данный код именно "наши авторы"

    ОтветитьУдалить
  10. archimag24 декабря 2009 г. в 02:51

    @Keip
    > ну хотя бы вот это
    Я нигде не говорил, что кода вообще нет. Я про конкретных людей: если ты как-то агитируешь за конкретный язык, то будь добр, расскажи как ТЫ его используешь.

    > специально дал ссылку на
    > программу Е. Кирпичева
    Я не видел этой ссылки в его блоге, плохо смотрел? Но я думаю, что этого всё таки там нет, ибо "Tool for searching java classes ..." - это всё, на что способен haskell? Быть вспомогательным инструментом для программирования на Java? Лучшей анти-рекламы трудно придумать. Кроме того, одного проекта мало, я вот могу верить человеку, когда он рассказывает о чём-то, только тогда, когда он сам постоянно использует то, о чём говорит.

    Я не помню ни одного "нашего" поста, что бы кто-то рассказывал о коде на Haskell, который автор реально использовал для решения какой-либо практической проблемы. А об этом надо говорить постоянно, иначе создается полное впечатление, что никто не пишет на нём на постоянной основе. И кажется, оно совсем не обманчиво.

    ОтветитьУдалить
  11. Nikita24 декабря 2009 г. в 03:53

    ох, что-то это зело напоминает холивар

    если не сложно, может покажите пару ссылок на коммерческие проекты на Common Lisp?

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

    я просто хочу удовлетворить свое любопытство, а заодно ответить на достаточно банальный вопрос:

    - есть ли смысл взять и сесть на CL, заменив им хотя бы 1 из этого списка: Apache/PHP, Apache/Python, Glassfish|JBoss/Java,
    ASP.NET?

    ну так есть такие?

    ОтветитьУдалить
  12. Анонимный24 декабря 2009 г. в 04:01

    К предыдущему посту про динамическую область видимости: Я знаю, что CL *поддерживает* переменные с динамической областью видимости - но не *по умолчанию*. Согласен, что мне стоило прибавить в тексте "по умолчанию" и, возможно, упомянуть, что CL в принципе их поддерживает. Прибавлю, спасибо за багрепорт.

    > Скажем, в главе про "сопоставление с образцом" нет ни слова про унификацию
    У меня не хватило времени, сил и места (и не было цели) упомянуть *все*, про что Вам бы могло *в принципе* захотеться сказать, что оно-де в статье не упоминается и потому-де автор ничего ни в чем не понимает. Я считаю, что понимание соответствия между унификацией и паттернматчингом менее критично, чем остальное, написанное в соответствующей статье, поэтому я осознанно не стал рассказывать в статье об унификации (хотя и хотелось).

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

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

    ОтветитьУдалить
  13. archimag24 декабря 2009 г. в 04:20

    @Keip
    > если не сложно, может покажите пару ссылок на
    > коммерческие проекты на Common Lisp?

    Я привык говорить только за себя, поэтому: http://archimag-dev.blogspot.com/2009/11/made-with-common-lisp.html - скрин и ссылка на небольшой ролик, это сейчас основной мой проект, за который мне платят деньги. На предыдущей работе я был ведущим по схожему проекту, который, если моя информация верна, продолжает использоваться в нескольких десятках гипермакетов по всей России, там тоже использовался CL, но только не для всей системы (как у меня сейчас), а для нескольких ключевых компонентов.

    Но мне не нравится, когда речь заходит только о коммерческих системах. Open Source уже запретили писать? http://github.com/archimag - здесь все мои открытые проекты (которые я использую и в своём корпоративном софте), за исключением hunchentoot, colorize и gentoo-list-overlay, авторами которых я не являюсь (об этих репозиториях написано в моих пред. сообщениях).

    > только не надо это воспринимать как предложение
    > спросить меня об аналогичных вещах на хаскелле

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

    > есть ли смысл взять и сесть на CL,
    > заменив им хотя бы 1 из этого списка
    Я это сделал, и очень доволен. Я продолжаю использовать Apache на работе ради mod_auth_kerb, но я обязательно со временем сделаю привязку к mit-krb5 и выброшу и его. Есть ли смысл для Вас, мне трудно судить.

    ОтветитьУдалить
  14. archimag24 декабря 2009 г. в 04:48

    @antilamer
    > но не *по умолчанию*

    Для переменных, объявленных с помощью defvar или defparameter - по-умолчанию. И это действительно широко используется в реальном коде.

    > generic-функции не имеют достаточного
    > отношения к patternmatching

    Я тоже так считаю, но ведь Вы зачем-то умомянули про Visitor? Конечно, "pattern matching" vs. Visitor имеет весьма сильный эффект, но в основном потому, что сама идея Visitor весьма сомнительна. А "pattern matching" vs. generic выглядит уже совсем не так однозначно, и я считаю, что в большинстве случаев generic является куда более лучшим решение, хотя и не прямой заменой.

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

    Кстати, есть один момент, который почему-то нигде у нас не оговаривается, и не обсуждается. В SICP утверждается, что за всё время было придумано всего два подхода к декомпозиции компьютерных систем: объектная (не путать с ООП) и на основе потоков. Так вот, ФП было фактически придумано именно для поддержки декомпозиции на основе потоков данных и если говорить о применении ФЯП, то прежде всего надо указывать о необходимости использования других подходов к декомпозиции, и доказывать состоятельность подобных методов декомпозиции. А так люди пытаются применить (хотя бы мысленно) ФЯП совместно с традиционной объектной декомпозицией и начинают ругаться матом, что выливается в совершенно не соответствующий сути различий срач "функциональый vs. императивный". А ведь для понимания этих вещей не нужен "суровый матан".

    ОтветитьУдалить
  15. Анонимный24 декабря 2009 г. в 05:03

    > Для переменных, объявленных с помощью defvar или defparameter - по-умолчанию.
    Очень странное замечание. А в си переменные, объявленные с помощью [], являются массивами по умолчанию. И что?

    > ведь Вы зачем-то умомянули про Visitor?
    Затем, что Visitor - это основной и очень важный с практической точки зрения (особенно для целевой аудитории статьи, которые пишут не на лиспе и хаскелле, а на мейнстримовых, в основном ОО-языках) способ типобезопасной реализации pattern matching в языках, которые его не поддерживают нативно.

    > что, конечно, не так.
    Из прочтения каких фрагментов статьи может создаться ошибочное впечатление, что некоторая концепция впервые появилась в функциональных языках, тогда как на самом деле это не так?
    В случае pattern matching, например, явно указано, что первым, хотя и в специфической области, был SNOBOL. Он не функциональный.
    Причем тут унификация, кстати?

    > прежде всего надо указывать о необходимости использования других подходов к декомпозиции

    Полностью согласен. Статья "combinator library" ;) А также некоторые другие статьи первого, второго и третьего номера: например, статья про шашки в первом номере.

    ОтветитьУдалить
  16. Анонимный24 декабря 2009 г. в 05:04

    Что значит "по умолчанию"? defvar/defparameter/let для определенных динамических переменных/progv это недостаточно "по умолчанию"?

    ОтветитьУдалить
  17. archimag24 декабря 2009 г. в 05:09

    > Очень странное замечание.
    Что странного? И при чём тут массивы из С? defparameter и defvar всегда (!) создают динамические переменные, которые по своим свойства сильно отличаются от лексических. Или может Вы не вполне верно понимаете, что есть "динамическая область видимости"?

    ОтветитьУдалить
  18. Анонимный24 декабря 2009 г. в 05:20

    Нет, похоже, у нас разногласия в том, что значит словосочетание "по умолчанию". Для того, чтобы переменная обладала динамической областью видимости, надо определить ее с помощью defparameter или defvar. А чтобы статической - ничего не надо: let, defun, аргументы функций все создают привязки со статической областью видимости.
    Мне кажется, что этого достаточно, чтобы сказать "по умолчанию в LISP используется статическая область видимости, но при помощи defparameter или defvar можно создавать переменные с динамической областью видимости".

    Можно сформулировать как "LISP поддерживает и static scope, и dynamic scope" - тогда можно порассуждать об умолчаниях, сравнив в какой-нибудь реальной программе количество идентификаторов, связанных тем или иным образом. Смею предположить, статических будет на пару порядков больше.

    ОтветитьУдалить
  19. archimag24 декабря 2009 г. в 05:26

    > Смею предположить, статических будет
    > на пару порядков больше.

    Конечно, а скобок будет ещё больше ;) Только дело в том, что роли их несравнимы, динамические переменные обычно являются частью дизайна системы и влияют на общую архитектуру, а лексические - обыкновенный расходный материал.

    И, кстати, термин LISP давно не моде, это дурной тон, такого языка сейчас нет, я всегда говорю о Common Lisp и называю его по имени :)

    ОтветитьУдалить

Подписаться на: Комментарии к сообщению (Atom)