• Будущее Лиспа
    0
    и де факто, и де юре
    en.wikipedia.org/wiki/Common_Lisp

    умч
  • Будущее Лиспа
    0
    Ну, вот видите, не зря я вас заминусовал ;)

    1. Стандарт Common Lisp — это не CLTL2, а ANSI Common Lisp. Его HTML-версия находится тут: www.lispworks.com/documentation/HyperSpec/Front/Contents.htm. Вам рассказать, как там найти Arrays? ;)
    Кстати, очень удобно пользоваться, особенно, когда в emacs'е одним нажатием кнопки перекидывает к определению нужного символа.

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

    3. У Scheme очень маленький стандарт и очень большое количество диалектов.
    Ваши цифры совершенно отфонарны.
    Если уже считать что-то, то не количество страниц, а количество сущностей. И принцип тут должен быть, наверно, такой:
    — если хотите получить язык, который очень легко реализовать (например, чтобы его портировать для встраиваемых систем т.д.), то желательно стандарт по-меньше
    — если хотите упростить жизнь пользователям, чтобы у них была портабельность приложений и им не пришлось постоянно изобретать велосипеды — то по-больше
    Кстати, ядро стандарта Lisp'а — описание синтаксиса (проще не придумаешь) + 25 специальных операторов (у Scheme — 7, и это пока известный мне мимнимум) + описание базовых типов. Всё остальное (функции, макросы) можно считать стандартной библиотекой.
  • Будущее Лиспа
    0
    «И, казалось бы, странно, что несмотря на кучу недостатков Питона ...»
    Я разве говорил, что это недостаток? Я о том, что «монструозность» стандарта CL — миф: никто ж не жалуется на «монтруозность» стандарта Питона, так ведь? Собственно, я про «объективный взгляд на реаль».

    «И, казалось бы, странно, что несмотря на кучу недостатков Питона, от него людей за уши не оттащишь. А с CL — зашли, посмотрели, побробовали, повздыхали и… свалили.»
    К Питону никаких претензий — сам пользуюсь. Но меня, например, как раз от CL за уши не оттащищь. Возможно, дело в разном устройстве мозгов (я серьезно).

    Вообще говоря, претензия только к одному всегда: про Lisp любят распространять кучу разного FUD'а. Например, «стандарт — монстр» (надеюсь, доказал уже, что это не так), «библиотек — нет», «скобки съедят ваш мозг» и т.д. Не распространяте FUD! ;)
  • Будущее Лиспа
    0
    А каким местом J/APL к Python?
  • Будущее Лиспа
    0
    Стандарт CL отнюдь не монстр, если учесть, что он описывает и стандартную библиотеку: стандартная библиотека Python что-то в 10 раз больше, кажется…
    А так, начинать нужно не с чтения стандарта. ANSI Common Lisp — отличный вводный курс. Или же Practical Common Lisp.
  • Будущее Лиспа
    0
    нет, Йегге таки много чего делает: js2-mode, например, (правда, для меня он не подошел, но говорят, можно допилить), сейчас работает над дебаггером для Clojure и троллит Рича Хики, чтобы они наконец написали двухпроходный компилятор (http://news.ycombinator.com/item?id=2466731) — а то ж, действительно, стыдно…
  • Будущее Лиспа
    +7
    примитивный фэнбоизм без особо знания матчасти
  • Пора завязывать использовать пробелы вместо табуляции в коде
    +2
    Ваша аргументация разбивается о суровую реальность жизни. С пробелами все-таки проще настроить, поэтому легче добиться соблюдения такого стиля. А, как верно показано на рисунке выше, должен остаться только 1 стиль.
  • Разработчики Scala выиграли грант Евросоюза
    +1
    Если разработка языка идет на гранты, это кое-что говорит о его востребованности для реальных проектов…
  • Google заплатил $700 млн за покупку ITA Software
    –1
    Питон у них только для скриптов, всякого некритичной веб. Для системного программирования только Java, C++ и теперь Go. (Так что на Go)
  • Заметки о внутреннем софте Apple, который никто не видел
  • Заметки о внутреннем софте Apple, который никто не видел
    0
    Насколько я знаю, в продакшене Оракл работает только на Солярисе, АИКс и RHEL. На все остальные системы, конечно, поставить можно, но никто так не делает, потому что буут косяки либо с производительностью, либо еще с чем.
  • Заметки о внутреннем софте Apple, который никто не видел
    0
    Боюсь, что Оракл на MacOS не работает…
  • Заметки о внутреннем софте Apple, который никто не видел
    +24
    Во-первых, это не муравьед, а трубкозуб.
    Во-вторых, IBM/AIX — это не старье, а самые современные серверные системы, которые стоят в банках, телекомах и дальше по списку.
    В-третьих, IT&S — это IT & Services helpdesk (т.е. внутренний сервис-деск) в компании и никакого отношению к MIT не имеет.

    А так, интересно, конечно…
  • Практика функционального программирования №5
    0
    скажу по секрету, что пост согласован с редакцией журнала
  • Практика функционального программирования №5
    0
    Ну, там же стоит ";)"
    А конкретно про смерть Lisp'а проскакивало в том длинном обсуждении на ЛОРе. Сейчас трудно будет найти, сорри.
  • GUI в Common Lisp — еще один миф
    +2
    Ну и, вы уверены, что функция GetUser в этом варианте полиморфна?
  • GUI в Common Lisp — еще один миф
    +2
    Этот пример показан в ответ на то, что вы сказали, что XML — это для данных. Однако в данном случае то XML используется для того, чтобы написать, что делать Ant'у (т.е. это код). (А что Ant — это не пример из практики, где это действительно нужно?)

    Поэтому вы правы: всё относительно и иногда данные становятся кодом и наоброт. Это, собственно, то, о чем я говорил изначально.
  • GUI в Common Lisp — еще один миф
    +1
    В принципе, это то, что я и ожидал (потому что по другому не получится в ООП).
    Есть несколько замечаний:
    1. вы не учли, что мы можем получать разную информацию о пользователе, а не только его ID и name. Я хочу получить список постов пользователя. Принадлежит ли он к классу пользователя? В вашем варианте по другому не получится: прийдется возвращать объект User, в котором, кроме ID и username будет еще и PostsList, Profile, FriendsList,… А что, если нам захочется добавить еще какое-то свойство, например, Carma? Выхода 2: лезть внутрь User'а или же наследовать от него UserWithCarma. Вот и наследование появляется, так же?
    2. Классы HttpApi, Cache и т.д. не имеют никакого состояния — это просто наборы методов. Однако вам приходится их инстанциировать. Да еще и нужен класс-обертка Integrator, который тоже состояния не имеет, он у вас только организовывает полиморфизм. Кстати, политика интегратора захардкожена в GetUser: т.е. сначала делается запрос к кешу, потом к API. А что если у нас добавляется новый метод доступа (какой-нибуть ThriftAPI) или же для некоторых случаев мы хотим сначала информацию смотреть в API, а потом в кеше (если API не отвечает из-за того, что Хабр лежит), а для некоторых сначала в кеше? Правильно, приходится писать новый интегратор.

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

    Альтернатива на Common Lisp:

    <code>(defgeneric get-data (source attribute user))
    
    (defmethod get-data ((source (eql :api))
                         (attribute (eql :posts))
                         (id integer))
      ;; собственно код
      )
    
    (defmethod get-data ((source (eql :fast)) attribute user)
      ;; сначала полезем в кеш, потом в API
      (or (get-data :cache attribute user)
          (get-data :api attribute user)))
    </code>


    При этом, как видите, никаких излишних сущностей не создается.
  • GUI в Common Lisp — еще один миф
    +1
    А можно по-подробнее: что это за класс контроллера такой? И каким образом реализуется полиморфизм? Я имею в виду: вот у нас есть 2 конкретных варианта вызова:
    1. получить через API данные о постах пользователя «lookat»
    2. получить из кеша профиль пользователя 123
    Методами каких классов они будут, каким образом будет происходит специализация? Если бы накидали пару строчек кода, было бы вообще супер… (А я взамен могу показать, как это будет выглядеть в Common Lisp)
  • GUI в Common Lisp — еще один миф
    +1
    вы почему-то не ответили ни на один из моих вопросов…
  • GUI в Common Lisp — еще один миф
    +1
    Хорошо, в этом примере всё выглядит ОК.
    А как быть в таком случае: у нас есть программа, которая использует Хабр, как источник данных о людях. Она получает N видов данных (например, список записей в блог, список друзей, профиль, ...) и может сделать это несколькими путями (через REST API, прямо через HTTP — scraping, а также из собственного кеша), и к тому же запрос может делать по id пользователя (число) или его имени (строка). Как видите, концептуально имеет полиморфную функцию get_data(kind, source, user), которая может менять поведение в зависимости от каждого из своих параметров. Как бы вы это выразили с помощью интерфейсов (да и, вообще, классического ООП), например, в том же C#?
  • GUI в Common Lisp — еще один миф
    +1
    А программа — это не обрабатываемая компилятором информация?

    А что по вашему приведенный пример? Если это чистые данные, то где же закодированна логика работы Ant'а? Как он решает, что ему нужно сделать: заархивировать или разархивировать?
  • GUI в Common Lisp — еще один миф
    +1
    В двух словах, что я хотел сказать: если не создавать иерархий, то не будет полиморфизма в ООП.

    Согласен, что, строго говоря, не верно. Можно реализовывать один интерфейс, можно наследовать только от одного базового класса, куда запихнуть все нужные методы и тоже самое будет. (Т.е. будет вырожденная иерархия из двух уровней). Но так ведь не получается.

    Далее, чтобы получить всего-лишь 1 полиморфную функцию, нужно создать:
    1. интерфейс
    2. класс, который этот интерфейс реализует
    3. инстанциировать этот класс
    В целом, конечно, интерфейсы — это гораздо лучше класс-методов, но в чистом виде то никто так не делает: комбинируют и то, и то, правда же? (И интерфейсы, кстати, тоже наследуются, так что и тут иерархии создаются). А ведь полиморфизм в чистом виде — это разное поведение функции в зависимости от типов входных параметров (или каких-то еще критериев). Причем здесь интерфейсы/классы?
  • GUI в Common Lisp — еще один миф
    +1
    Собственно таск:
    <gunzip dest=".">
    <url url=«example.org/archive.tar.gz»/>
    </gunzip>
  • GUI в Common Lisp — еще один миф
    +1
    а код — это данные*, вы не знали? ;)
    Пока что ограничиваюсь статьями

    * берем для примера первую же Ant Task из мануала (http://ant.apache.org/manual/CoreTasks/unpack.html):
    />
  • GUI в Common Lisp — еще один миф
    +1
    Ну а я программирую на юниксе постоянно. И что дальше — кто из нас круче? ;)

    Объясните мне тогда, что же такое эта слобая связанность, будьте добры…
  • GUI в Common Lisp — еще один миф
    0
    Знаете, на Lisp'е пишу почти каждый день. В то же время не скзал бы, что есть языки, которые мне противны.

    Ну а почему вам софт-код на Lisp'е не понятен — вы же сами дали объяснение (опыт). И еще: быдлокод — он для маленьких задач (которые можно уместить в один файл) часто понятен, поскольку сразу видно ход мысли. Но вы же так не будете писать хоть что-то серьезное (я надеюсь :) И опять мы приходим к критериям хорошего кода. Для серьезных задач — это будет не возможность написать в лоб что-то, а возможность четко разделить интерфейс и реализацию, механизм и политику, возможность абстракции, отсутствие boilerplate, отсутствие нерегулярной ad hoc базы и т.д. По этим критериям Lisp даст фору любому языку.
  • GUI в Common Lisp — еще один миф
    +1
    Понятно, что Unix написан на С. А о его принципах можете почитать здесь: www.faqs.org/docs/artu/ch01s06.html Это я к тому, что слабая связность — это не фантастика.
  • GUI в Common Lisp — еще один миф
    +3
    Вот мы и определили ваш критерий понятности: быдлокод. :)
  • GUI в Common Lisp — еще один миф
    0
    Есть где-то даже исследования на этот счет. (Вот есть какая-то: chayden.net/eliza/Eliza/ Как-то не вериться, что там только 150 строк кода...)

    Ну а на Lisp'е не до фига (не считая названных мною Lisp-машин, которые были 20 лет назад). А вы знаете, кстати, какое-то приложение на миллион строк на Javascript, или на Ruby, или даже на Python? Тем не менее, очень полезные языки, не находите?
  • GUI в Common Lisp — еще один миф
    +1
    это точно :(
  • GUI в Common Lisp — еще один миф
    +1
    Я привел ссылку на Yegge. Поищите в интернете по чему-то типа «big project fail oop» :)

    Слабосвязные системы — это не научная фантастика. На этом принципе построен Unix (в некоторой мере).

    Простите, если не понятно написал. «Не привязанному к иерархиям классов полиморфизму». Это о том, что полиморфизм в ОО-языках (читай C++, Java) не существует отдельно от наследования (будь то через механизм интерфейсов как в Java, или абстрактных классов (это в хорошем случае), или же простого наследования, которое повсеместно для это используется (в не очень хорошем случае)). Если ОО-язык отказывается от концепции наследования, то он теряет и полиморфизм. Не согласны? Как на счет примера Javascript?
  • GUI в Common Lisp — еще один миф
    +3
    Да нет, я заявляю, что Lisp намного понятнее (но не пытаюсь вас в этом убеждать: переубеждать кого-то — глупое занятие). Если вы хотите сделать это предметным спором, а не просто высказыванием своих убеждений, нужно сначала определить критерии «понятности», «хорошести» и т.д., о чем я вас попросил ниже. Разумеется, по некоторым критериям Lisp не будет понятным (например, по критерию наличия фигурных скобок ;)
  • GUI в Common Lisp — еще один миф
    +1
    Несколько сот тысяч строк — это должно быть что-то очень серьезное — эквивалент нескольким миллионам строк на C/Java/… За всю историю таких только несколько было, например известная система для компьютерной алгебры Macsyma (многие ученые прекрасно работают с ней и сейчас). Ну, все что было написано для Lisp-машины — это, явно, миллионы строк кода, но о них сейчас говорить не принято, потому как никто попробовать не может и сравнить (тем не менее Lisp-машины работали около 10 лет в очень многих научных учреждениях, проектных бюро и т.д., что доказывает, что на то время эта технология была вполне конкурентноспособна). Из современных примеров — QPX (http://itasoftware.com/solutions/qpx.html). Эта самая лучшая в мире система расчета цен на авиабилеты и стыковки маршрутов.
  • GUI в Common Lisp — еще один миф
    0
    Вы, конечно, извинити, но убеждать вас никакого смысла нет — ведь вы не хотите объяснить, в чем вас нужно убеждать.

    Единственная ремарка: ваше приложение занимает 700 строк кода, а у Норвига — 200.
  • GUI в Common Lisp — еще один миф
    +1
    Жаль того несчастного, кому пришлось это писать. Но причем здесь Lisp? Можно с таким подходом и в Jave нагородить что-то подобное (только займет это, наверно, 10 экранов: представляете 10 вызовов Java-функций в одной строке?)

    А не могли бы выложить Элизу на какой-то нормальный ресурс (paste.lisp.org)? А то не грузиться. Тем временем можете посмотреть на нормальную ее реализацию: norvig.com/paip/eliza.lisp

  • GUI в Common Lisp — еще один миф
    +1
    Вас, наверно, удивит, но самая распространенная SDK в мире — это Emacs (если сомневаетесь, то посчитайте, сколько людей пользуется им из книги Coders at Work. Около 10ка. Или вы скажете, что те люди, которые написали Unix, BitBlt и Firefox — это не реальный мир?)

    Далее, если говорить о применимости Lisp'а в корпоративной среде (да и в целом в типичных задачах, с которыми сталкиваются большинство программистов), то вы зря делаете такой акцент на списках. Списки — это очень базовая вещь. Все нормальные современные языки прекрасно их поддерживают (взять тот же Python). Возможность Lisp, которые позволяют бороться со сложностью крупных систем (против которых, как уже показала практика, ООП-подход бессилен) — это возможность создания многослойных слабосвязанных систем за счет проблемно-ориентированного программирования (прежде всего на основе макросов) и не привязанного к необходимости городить иерархии классов полиморфизма.
  • GUI в Common Lisp — еще один миф
    +2
    Рекурсия — это одна из стратегий вычисления. Вы что, никогда рекурсию в С не использовали? Причем здесь Lisp? Так же само, как инкапсуляция — это абстрактная концепция, которую можна реализовать множеством способов. Когда мы говорит о языке программирования общего назначения, то такой язык должен позволять задействовать любые стратегии вычисления, реализовать любые не взаимопротиворечивые концепции. Common Lisp это позволяет сделать.

    Ну а читаемость программы не должна в общем-то зависить от количества строк в ней: вы же читаете ее потоково, по нескольку строк, а не сразу 300, которые на экране не умещаются ;) Читаемость зависит от порядка в голове у того, кто программу написал.
  • GUI в Common Lisp — еще один миф
    +1
    наоборот, использование Lisp позволяет эту нереальную сложность, с которой не справляются традиционные подходы (тот же ООП*) преодолеть.

    * steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html