Более лучший Лисп

2. Следующий стандарт CL? Да тут в ветке УЖЕ договориться не могут, а обсуждается то пока сущая ерунда. А без поддержки большей части сообщества - кто будет реализовывать новый стандарт?

самое главное, ЗАЧЕМ?

Где взяться людским ресурсам для формирования нового стандарта и его реализации? Я подобного «источника» не вижу.

ну учитывая картинку с общим количеством пользователей лиспа исчо — да количество людишек урядных — грустно всё с широкими немытыми народными массами.

а вот технически, не всё так плохо — скорость разработки новых лиспов (условно, это Arc, Shen, ISOLISP, EuLisp, Схема ) по сравнению со старыми — впечатляет.

что вообще нужно?

1. одну вменяемую, легко обозримую и верифицируемую (желательно, формально, как в изялиспе) спецификацию.

2. одну полноценную, вменяемую референсную реализацию.

3. набор библиотек по типу CPAN/CTAN/CRAN/Ruby gems/ Python egg/Goggle Go пакеты/... с пакетным менеджером, который умеет скачивать, компилировать, собирать, контролировать версии пакетов — то есть, с поддержкой ЖЦ разработки, типа maven/sbt/quickload.

4. какой-то набор идиом. типа, rosetta stone. или, «гугло Go для программистов из C++/Java/C#».

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

дело за организаторами. пока маловато людей.

для «нового, лучшего лиспа» имело бы смысл срыть эти исторические наслоения, и начать заново.

возможно. Но опять-же - кто? где? когда? за чьи бабки? Я про стандарт - не про реализацию. Если начинать с «рефренс-реализации», то, опять-же - кто будет принимать решения «надо/не надо» и «так/этак»? Хотя так проще - можно попытаться начать курочить, например, тот-же sbcl, отбрасывая (или не используя) «ненужное» - как в своё время начинал Qi, только «глубже» и «категоричнее».

дак в той же схеме модулей и поболее будет.

Ты про стандарт? Возможно. Но я думаю, что схема «рядом» настолько, что ожидать «маститых схемеров» в создании нового лиспа - пустое дело.

Даже свободный компилятор есть (OpenLisp).

справедливости ради, он не совсем свободный — open в смысле «Open Systems», а не Open Source. то есть, свободно раздаются бинарники под 50+ сборок под разные ОС и архитектуры — там есть интерпретатор, но не полноценный компилятор (компилирует через си, или через LAP). тот же интерпретатор есть в emact (кстати, емакс в полмегабайта, с конфигами на openlisp-е и недополноценным SLIME из коробки (ближе, скорее, к inferior-lisp-mode)) .

кристиан, автор опенлиспа — конечно крут, и вызывает уважение (особенно то, что опенлисп существует года с 1988, все 50+ сборок под все ОС легко собираются нужным makefile, элементарно встраивается и расширяется).

но его блин, ценовая политика за полную, non-GPL версию и полноценную встраиваемую версию — вызывает недоумение. почти эйфель по деньгам.

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

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

вот и кирпичеКАД подтянулся, например.

нооо... где, блин, сообчество?

самое главное, ЗАЧЕМ?

Ну вот действительно многим CL-никам видятся необходимыми те или иные изменения, которые без стандартизации так и останутся уделом «просвещённых», либо вообще невозможны.

что вообще нужно?

Я бы сказал, что нужна «идея-фикс», способная увлечь достаточную часть «лиспофилов». И хоть какая-то преемственность, ибо, глядя на трудозатраты на тот-же sbcl (а до него - на cmucl), становится не много не по себе, ибо [пока] - это лидер в плане скорость + качество компиляции + качество rt. А получить очередной, пусть и навёрнутый, интерпретатор - ни кому не упёрлось, ибо «сотни их».

Скажем в проекте hu.dwim сделана внутренне-целостная система (логгер, юнит-тесты, интеграция с asdf, интеграция с slime, слой взаимодействия с БД, ORM, web-сервер, зависимые (вычислимые) слоты, улучшенный синтаксис, ...). Фактически, на его основании можно писать новый стандарт.

как бы этот «новый стандарт» выглядел? что он описывал бы? стандарт на что, на API?

почему он был бы лучше старого?

Другая крайность — den73 с <особым ламповым синтаксисом>

почему собственно это что-то необычное? если нотация уместна и удобна, её стоит делать

* программирование — написание программы, решающей задачу * метапрограммирование — написание программы, пишущей программу, решающей задачу * метаметапрограммирование — написание языка, на котором пишется программа, пишущая программу, решающая задачу

... то есть, любой лиспер рано или поздно приходит к созданию своего языка. такой вот обратный парадокс Блаба

* метаметаметапрограммирование — написание идиом, концепций, понятий, парадигм используя которые создаётся язык, на котором пишется программа, пишущая программу, решающая задачу

... на котором он думает. такая вот лисповая смоляная яма типа Turing tar pit

а я всё жду, когда же они доберутся до

* метаметаметаметапрограммирования, или 4-метапрограммирование — программирование программистов, которые будут создавать парадигмы, идиомы, языки, далее по тексту — которые будут программировать 3-метапрограммистов.

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

это ещё с вавилонской башни повелось.

man «Snowcrash» by Neil Stephenson про язык как метавирус, и Энки прохакир его.

лисп это намшуб

а все эти ваши фреймворки, стандарты, языки, процессы — всего лишь жалкие ме

нооо... где, блин, сообчество?

На таких условиях? Та ну нафиг :)

Из статьи про NIL.

The genesis & eventual failure of this kind of project is always clearly visible (in hindsight) in the shibboleths of the early discussions. One key tip-off phrase is always something of the form, «We'll throw out all the old cruft, start over fresh, and just Do Things Right.» Olin Shivers'

* метаметаметаметапрограммирования, или 4-метапрограммирование — программирование программистов, которые будут создавать парадигмы, идиомы, языки, далее по тексту — которые будут программировать 3-метапрограммистов.

Это давно есть. Называется словом «Менеджмент».

• программирование — написание программы, решающей задачу
• метапрограммирование — написание программы, пишущей программу, решающей задачу
• метаметапрограммирование — написание языка, на котором пишется программа, пишущая программу, решающая задачу

  ... то есть, любой лиспер рано или поздно приходит к созданию своего языка. такой вот обратный парадокс Блаба

• метаметаметапрограммирование — написание идиом, концепций, понятий, парадигм используя которые создаётся язык, на котором пишется программа, пишущая программу, решающая задачу

  ... на котором он думает. такая вот лисповая смоляная яма типа Turing tar pit

  а я всё жду, когда же они доберутся до

• метаметапрограммирование , или 4-метапрограммирование — программирование программистов, которые будут создавать парадигмы, идиомы, языки, далее по тексту — которые будут программировать 3-метапрограммистов.

(капча ancients про шумерчегов, нибиру и аннунаков, гы)

знаем этих. там ещё водятся менагеры, от анг. menagerie, то есть, зверинец.

почему собственно это что-то необычное? если нотация уместна и удобна, её стоит делать

Если она «уместна и удобна» для написания библиотеки - да на здоровье. А если она нужна для её использования, при этом она не «закрыта» (как loop), обязательно требует «включения в рабочий неймспейс» и меняет поведение ключевых символов - к разработке такой нотации нужно подходить оооочень осторожно, а ещё лучше - оставлять альтернативную возможность использования, пусть и «не такую изящную». Ибо очень быстро может встать вопрос о совместимости нескольких подобных нотаций.

3. набор библиотек по типу CPAN/CTAN/CRAN/Ruby gems/ Python egg/Goggle Go пакеты/... с пакетным менеджером, который умеет скачивать, компилировать, собирать, контролировать версии пакетов — то есть, с поддержкой ЖЦ разработки, типа maven/sbt/quickload.

кстати, про пакетный менеджер. вот в Google Go он умеет подсчитывать при скачивании библиотеки в свой проект количество пользователей этой библиотеки. а потом показывает в dashboard-е, сколько пользователей этим пользуется али протухло всё.

ихмо, полезная, годная фича.

Ну вот действительно многим CL-никам видятся необходимыми те или иные изменения, которые без стандартизации так и останутся уделом «просвещённых», либо вообще невозможны.

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

что «невозможны» — вызывает сомнение. скорее, трудоёмки до невозможности, яко же нечистые макросы поганые.

Я бы сказал, что нужна «идея-фикс»,

лисперы, давайте свои версии.

давайте свои версии

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

а ещё лучше - оставлять альтернативную возможность использования, пусть и «не такую изящную». Ибо очень быстро может встать вопрос о совместимости нескольких подобных нотаций.

а разве это отличается чем-то от тех же RFC, PEP в питоне, и прочих SRFI?

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

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

эта идея недостаточно фикс.

Где—то видел подобную вещь для CL. Попробую найти ссылку

Не пойму в чём это статические касты, то есть чем отличается от change-class.

C change-class:

(defvar *a* (make-instance 'a))
(change-class *a* 'b)
;; здесь в переменной *a* теперь класс с типом b. 
;; Если делать change к предку, можно потерять 
;; данные полей, который только у наследника

C find-method:

(defvar *a* (make-instance 'a))
(funcall
  (closer-mop:method-function 
           (find-method #'test () (list (find-class 'b))))
         (list *a*) nil)
;; здесь мы просто вызвали метод test с параметром *a* так, ;; как если бы его тип был равен b. То есть полный аналог
static_cast<b>(a).test()

P.S. Для совсем полного аналога надо ещё проверять методы предков b и делать проверку, что a можно привести к b.

.... hu.dwim ...

Можно ли использовать эту библиотеку без использования её синтаксиса?

Можно, конечно. Вот здесь http://lisper.ru/forum/thread/46 описывается такое использование (Кстати, автор как раз Archimag. видимо, он тогда ещё на исходники не посмотрел :-)).

Проблема в том, что хочется не только использовать, но и расширять. А для этого приходится читать исходники...

метаметаметаметапрограммирования, или 4-метапрограммирование — программирование программистов, которые будут создавать парадигмы, идиомы, языки, далее по тексту

Не нужно. Человек --- существо, склонное к ошибкам. А роботы пока программировать не умеют. А те, что будут уметь, всё равно будут эквивалентны Lisp-машине.

вот

и кто-то ей уже пользуется, развернул веб-интерфейс на своём хостинге и устроил на этой платформе обсуждение годности библиотек?

Я за тебя должен глушить? А вообще идея годная. Если еще нет — надо предложить архимагу

*гуглить

развернул веб-интерфейс на своём хостинге

А смысл в веб-интерфейсе? Алгоритм есть. Список пакетов в quicklisp у всех одинаковый. Запускаешь и смотришь. Там другая проблема: релевантность результатов.

Вот результаты:

(9 «cl-containers») 
(9 «map-bind») 
(9 «iolib.syscalls») 
(9 «ieee-floats») 
(9 «cl+ssl») 
(10 «contextl») 
(10 «trivial-backtrace») 
(10 «s-xml») 
(10 «asdf-system-connections») 
(10 «cl-opengl») 
(10 «iolib.base») 
(10 «hu.dwim.walker») 
(11 «fishpack») 
(12 «uffi») 
(12 «parenscript») 
(12 «metatilities») 
(12 «iolib») 
(13 «weblocks») 
(13 «trivial-utf-8») 
(13 «kmrcl») 
(13 «hu.dwim.logger») 
(13 «hu.dwim.def») 
(14 «trivial-features») 
(14 «clack») 
(14 «cl-test-more») 
(15 «cl-who») 
(15 «named-readtables») 
(15 «hu.dwim.defclass-star+hu.dwim.def») 
(16 «stefil») 
(17 «mcclim») 
(17 «cl-json») 
(18 «metabang-bind») 
(18 «lispbuilder-sdl») 
(19 «arnesi») 
(19 «parse-number») 
(19 «md5») 
(20 «cl-interpol») 
(20 «eos») 
(21 «swank») 
(22 «clsql») 
(22 «hu.dwim.util») 
(23 «cl-syntax-annot») 
(25 «com.informatimago.common-lisp.cesarum») 
(25 «rt») 
(25 «local-time») 
(25 «hunchentoot») 
(26 «cl-base64») 
(27 «ironclad») 
(28 «trivial-gray-streams») 
(28 «cl-syntax») 
(28 «lisp-unit») 
(29 «puri») 
(29 «hu.dwim.stefil») 
(31 «cffi-grovel») 
(32 «trivial-garbage») 
(34 «usocket») 
(35 «anaphora») 
(38 «cxml») 
(38 «f2cl») 
(39 «babel») 
(40 «cl-fad») 
(42 «drakma») 
(43 «fiveam») 
(46 «lift») 
(47 «flexi-streams») 
(52 «split-sequence») 
(68 «closer-mop») 
(84 «bordeaux-threads») 
(88 «iterate») 
(88 «hu.dwim.asdf») 
(139 «cl-ppcre») 
(140 «cffi») 
(153 «alexandria») 
(351 «cl-glfw-opengl-core») 

Какие их них можно сделать выводы? cl-glfw-opengl-core супер-крут (в 2 раза круче alexandria)? Нет, просто разработчик программы разбил её на 360 пакетов, а общую часть назвал cl-glfw-opengl-core. Аналогично hu.dwim.asdf. По остальным не столь очевидно, но ясно, что может быть накрутка (ненамеренная).

как бы этот «новый стандарт» выглядел? что он описывал бы? стандарт на что, на API?

1. В качестве базовой вместо cl используется hu.dwim.common, который включает в себя iterate, alexandria, metabang-bind, closer-mop, anaphora.

2. Базовый метод определения любых объектов

(def ({объект} {флаги}) ...)

например
(def (function ioe) eval/interpret (form) ...)
(def (with-macro* e) with-profiling () ...)

для новых видов объектов используется
(def (definer e :available-flags "ioed") {объект} ...)

Описание флагов (export, optimize, inline, ...)

Тут же, в каких стандартных окружения какие дополнительные переменные определяются (-body- в macro, -whole-, -definer- и -environment- в definer и т.д.)

3. Классы определяются через def class и имеют аксессоры на слоты в виде {имя-слота}-of.

4. Используется #t = t, #f = nil Фигурные скобки используются для локального переопределения readtable, например, {(with-package :common-lisp) ...}, #* для cond-условий на feature.

5. Стандарты на систему юнит-тесов и её интеграцию с asdf

6 .... я уже устал писать и всё равно это никому не надо

1. В качестве базовой вместо cl используется hu.dwim.common, который включает в себя iterate, alexandria, metabang-bind, closer-mop, anaphora.

Я против таких нововведений. И других остальных пунктов. :)

Я против таких нововведений.

Вот и я про то же самое. Любые изменения, существенно улучшающие язык (радикально уменьшающие количество boilerplate кода) всегда будут кому-нибудь не нравиться. То есть если кто-то что-то даже стандартизует, половина лисперов скажут «я против» и останутся на ANSI CL => получили просто ещё один язык (как Arc).

С учётом того, что кто хочет и так может пользоваться хоть hu.dwim, хоть lisp-interface-library, то стандартизация вообще никому не нужна, потому что ничего не изменит.

Любые изменения, существенно улучшающие язык

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

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

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

Даже самая узкая ниша, в условиях всего мира и при наличии классного продукта

Можешь пример ниши привести? Я сейчас потихоньку пилю бухгалтерию (лавры 1С и кривизна его 1С-бейсика покоя не дают). В качестве киллер-фичи: couchbase в качестве хранилища (скорость) и постоянный контроль инвариантов (расчёт последствий проведения документа: где съедет себестоимость, где станет не хватать материалов и т.д.), но вот нужно ли оно кому-нибудь кроме меня — хз.

но вот нужно ли оно кому-нибудь кроме меня — хз.

release early, release often. - делай, как Вася из соседнего треда. А Петя так и будет пыхтеть над божественном дизайном.

Я сейчас потихоньку пилю бухгалтерию
...
но вот нужно ли оно кому-нибудь кроме меня — хз.

Как минимум мне, теоритически. Хотя я самопальных бухий несколько видел (не на лиспе) и в связи с этим скептически настроен.

Хотя я самопальных бухий несколько видел

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

идейно-плановая база все равно требует обсуждения. И чем ранше ее оборжут и укажкт на недочеты тем лучше.

Ну тогда описание архитектуры:

1. Backend: http://www.couchbase.com/download . Интерфейс к ней в процессе написания.

2. Front-end: https://github.com/Kalimehtar/gtk-cffi (уже всё рабоает, но реализованы не все виджеты).

3. Middle-tier: сервер приложений с бизнес логикой а-ля 1С. В зависимости от *feature* объекты либо по запросу все загружаются в память навсегда, либо в виде weak-ref, либо при каждом чтении берутся из couchbase (у него есть своё кэширование).

Синтаксис

(метод обработка-проведения (поступление)
       (пусть ((дв (новый регистр:товары-на-складах)))
         (для-каждого (стр (товары поступление))
           (пусть ((нов-стр (добавить-приход дв)))
             (заполнить нов-стр стр)
             (уст (период нов-стр) (дата поступление))))
         (уст (поле (движения поступление) 'товары-на-складах) дв)))

стандартный CL также поддерживается (кроме имен функций предметной области)

(defmethod обработка-проведения ((obj поступление))
  (let ((reg (make-instance регистр:товары-на-складах)))
    (dolist (item (товары obj))
       (let ((new-str (добавить-приход reg)))
          (заполнить new-str item)
          (setf (период new-str) (дата obj))))
     (setf (getf (движения obj) 'товары-на-складах) reg)))

Критикуйте, уточняйте, если что неясно.

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

Было бы так, если бы программисты были не люди, а машины, но программистам нравится писать на простых, удобных и мощных языках и не нравится куча устаревшего говна. Т.к. нет индустрии, которая бы стала локомотивом для Лиспа, то остается надеяться на труд энтузиастов, а они не станут писать на C++ или Java, т.к. фана в них давно нет.

простых, удобных и мощных языках

В случае CL третье, очевидно, есть. А простота и удобство вещи субъективные. Причём, в рамках CL простота и удобство достигается выбором нужной библиотеки. Станадртизовать было бы неплохо, чтобы проще было читать чужой код (*-utils откровенно напрягают своим разнообразем методов для решения однотипных задач и отсутствием докуентации). Но, как сказал gensym: на любую библиотеку найдётся кто-то против. А значит стандарт могут сделать либо, например, ребята из SBCL, либо снова мучить ANSI. Или не париться и писать каждому на заточенном под себя лиспе, непохожем ни на чей другой :-)

1. Backend: http://www.couchbase.com/download . Интерфейс к ней в процессе написания.

Странно, вторую 1С-подобную систему на ЛОРе писать собираются - и снова на Couch.

вторую 1С-подобную систему на ЛОРе писать собираются - и снова на Couch.

А можно ссылку на первую? Очень интересно

P.S. CouchDB и Couchbase это очень разные базы.

NoSQL для 1С-подобного напрашивается, потому что в самом 1С начинается нехилое изнасилование СУБД, например, если надо сделать общий журнал за месяц (если в базе 350 видов докуентов, то в запросе объединение 750 таблиц с отбором по результату объедигнения). На любом NoSQL такого хентая нет.

А можно ссылку на первую? Очень интересно

Конечно: Создание своей СУБД + вебсервера + системы автоматизации

Но она никуда не продвинулась, AFAIK.

NoSQL для 1С-подобного напрашивается

Я одинаково мало смыслю и в NoSQL, и в 1С, но сходство между проектами (NoSQL + Erlang и NoSQL + Lisp) навевает грустные мысли.

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

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

Но я думаю, что большинство программистов не особо обращают внимание на язык, с которым приходиться работать (да и кто вообще обещал, что будет легко?). Человек ко всему привыкает. А настоящий фан идёт от создания чего-то нужного и полезного, т.е. непосредственно от инженерной деятельности, а язык второстепенен.

Конечно: Создание своей СУБД + вебсервера + системы автоматизации

Не. У них круче. Они СУБД хотели «принципиально новую сделать». CouchDB им там в комментах предлагали.

У меня проще. Почти все кирпичики уже есть (кроме клиента к couchbase, но на худой конец он с cl-memcached работает). Алгоритмы тоже есть (математика в РФ не патентуется, законы тоже => можно смотреть исходники 1С бухгалтерии). Осталось склеить.

законы тоже => можно смотреть исходники 1С бухгалтерии

Думаю, это будет гораздо сложнее. Но удачи в любом случае.

NoSQL для 1С-подобного напрашивается, потому что в самом 1С начинается нехилое изнасилование СУБД, например, если надо сделать общий журнал за месяц (если в базе 350 видов докуентов, то в запросе объединение 750 таблиц с отбором по результату объедигнения). На любом NoSQL такого хентая нет.

Django'подобное наследование наверное бы спасло. С выделением суперкласса «документ» со всеми общими реквизитами в отдельную таблицу.

Представляю себе расчет зарплаты на MapReduce'ах =)

С выделением суперкласса «документ»

У них так было в 7.7. В 8.0 они сказали, что так делать нельзя, потому как создание документа становится однопоточной операцией. Реально, для бухгалтерии легче не стало, потому что таблица проводок всё равно общая.

расчет зарплаты на MapReduce'ах =)

А что такого? Тем более, что сам расчёт будет на лиспе, а на MapReduce'ах будет только выборка по месяцу/сотруднику из начислений.