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, и это пока известный мне мимнимум) + описание базовых типов. Всё остальное (функции, макросы) можно считать стандартной библиотекой.
«И, казалось бы, странно, что несмотря на кучу недостатков Питона ...»
Я разве говорил, что это недостаток? Я о том, что «монструозность» стандарта CL — миф: никто ж не жалуется на «монтруозность» стандарта Питона, так ведь? Собственно, я про «объективный взгляд на реаль».
«И, казалось бы, странно, что несмотря на кучу недостатков Питона, от него людей за уши не оттащишь. А с CL — зашли, посмотрели, побробовали, повздыхали и… свалили.»
К Питону никаких претензий — сам пользуюсь. Но меня, например, как раз от CL за уши не оттащищь. Возможно, дело в разном устройстве мозгов (я серьезно).
Вообще говоря, претензия только к одному всегда: про Lisp любят распространять кучу разного FUD'а. Например, «стандарт — монстр» (надеюсь, доказал уже, что это не так), «библиотек — нет», «скобки съедят ваш мозг» и т.д. Не распространяте FUD! ;)
Стандарт CL отнюдь не монстр, если учесть, что он описывает и стандартную библиотеку: стандартная библиотека Python что-то в 10 раз больше, кажется…
А так, начинать нужно не с чтения стандарта. ANSI Common Lisp — отличный вводный курс. Или же Practical Common Lisp.
нет, Йегге таки много чего делает: js2-mode, например, (правда, для меня он не подошел, но говорят, можно допилить), сейчас работает над дебаггером для Clojure и троллит Рича Хики, чтобы они наконец написали двухпроходный компилятор (http://news.ycombinator.com/item?id=2466731) — а то ж, действительно, стыдно…
Ваша аргументация разбивается о суровую реальность жизни. С пробелами все-таки проще настроить, поэтому легче добиться соблюдения такого стиля. А, как верно показано на рисунке выше, должен остаться только 1 стиль.
Насколько я знаю, в продакшене Оракл работает только на Солярисе, АИКс и RHEL. На все остальные системы, конечно, поставить можно, но никто так не делает, потому что буут косяки либо с производительностью, либо еще с чем.
Во-первых, это не муравьед, а трубкозуб.
Во-вторых, IBM/AIX — это не старье, а самые современные серверные системы, которые стоят в банках, телекомах и дальше по списку.
В-третьих, IT&S — это IT & Services helpdesk (т.е. внутренний сервис-деск) в компании и никакого отношению к MIT не имеет.
Этот пример показан в ответ на то, что вы сказали, что XML — это для данных. Однако в данном случае то XML используется для того, чтобы написать, что делать Ant'у (т.е. это код). (А что Ant — это не пример из практики, где это действительно нужно?)
Поэтому вы правы: всё относительно и иногда данные становятся кодом и наоброт. Это, собственно, то, о чем я говорил изначально.
В принципе, это то, что я и ожидал (потому что по другому не получится в ООП).
Есть несколько замечаний:
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>
При этом, как видите, никаких излишних сущностей не создается.
А можно по-подробнее: что это за класс контроллера такой? И каким образом реализуется полиморфизм? Я имею в виду: вот у нас есть 2 конкретных варианта вызова:
1. получить через API данные о постах пользователя «lookat»
2. получить из кеша профиль пользователя 123
Методами каких классов они будут, каким образом будет происходит специализация? Если бы накидали пару строчек кода, было бы вообще супер… (А я взамен могу показать, как это будет выглядеть в Common Lisp)
en.wikipedia.org/wiki/Common_Lisp
умч
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, и это пока известный мне мимнимум) + описание базовых типов. Всё остальное (функции, макросы) можно считать стандартной библиотекой.
Я разве говорил, что это недостаток? Я о том, что «монструозность» стандарта CL — миф: никто ж не жалуется на «монтруозность» стандарта Питона, так ведь? Собственно, я про «объективный взгляд на реаль».
«И, казалось бы, странно, что несмотря на кучу недостатков Питона, от него людей за уши не оттащишь. А с CL — зашли, посмотрели, побробовали, повздыхали и… свалили.»
К Питону никаких претензий — сам пользуюсь. Но меня, например, как раз от CL за уши не оттащищь. Возможно, дело в разном устройстве мозгов (я серьезно).
Вообще говоря, претензия только к одному всегда: про Lisp любят распространять кучу разного FUD'а. Например, «стандарт — монстр» (надеюсь, доказал уже, что это не так), «библиотек — нет», «скобки съедят ваш мозг» и т.д. Не распространяте FUD! ;)
А так, начинать нужно не с чтения стандарта. ANSI Common Lisp — отличный вводный курс. Или же Practical Common Lisp.
Во-вторых, IBM/AIX — это не старье, а самые современные серверные системы, которые стоят в банках, телекомах и дальше по списку.
В-третьих, IT&S — это IT & Services helpdesk (т.е. внутренний сервис-деск) в компании и никакого отношению к MIT не имеет.
А так, интересно, конечно…
А конкретно про смерть Lisp'а проскакивало в том длинном обсуждении на ЛОРе. Сейчас трудно будет найти, сорри.
Поэтому вы правы: всё относительно и иногда данные становятся кодом и наоброт. Это, собственно, то, о чем я говорил изначально.
Есть несколько замечаний:
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>При этом, как видите, никаких излишних сущностей не создается.
1. получить через API данные о постах пользователя «lookat»
2. получить из кеша профиль пользователя 123
Методами каких классов они будут, каким образом будет происходит специализация? Если бы накидали пару строчек кода, было бы вообще супер… (А я взамен могу показать, как это будет выглядеть в Common Lisp)