Синдром Эллочки-людоедки и lisp

Понятно, над пунтком 2 в кложе поработали. А над путктом 1?

Как борются с этими проблемами местные лисперы. Особенно с первой.

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

как запомнить кучу классов в стандартной библиотеке

Я использую сразу несколько языков, буду путаться и все такое. Я уже писал, в той же java мне нужно помнить минимум ключевых слов, а также приблизительно что именно импортировать. А дальше IDE подскажет и выдаст доктип. Emacs тоже подскажет, но функции неструктурированны и вынесены в общее пространство имен.

Читаем «The Complete Idiot’s Guide to Common Lisp Packages».

что буду в большой команде использовать lisp, та и не годиться он для этого

На clojure|clojurescript масса крупных проектов, особенно в веб-разработке.

И не путай CL и emacs lisp. Не понимаю как можно писать на нем что-то серьезное когда он создавался как язык расширения emacs. Там даже классов нету (вроде).

На clojure|clojurescript масса крупных проектов, особенно в веб-разработке.

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

Не понимаю как можно писать на нем что-то серьезное когда он создавался как язык расширения emacs.

Мне как-то было лень на новом маке поднимать всю девелоперскую обвязку. Потому, начал писать на emacs lisp. Оказалось довольно практично, плюс немалый кусок CL там реализован. Ну и батареек для моих задач полно. Когда завезут FFI и нормальную многопоточность из коробки, будет годный язык общего назначения. И уже сейчас он быстрее python будет, правда в виде байт-кода. Кроме того не исключено появление JIT-компилятора

Там даже классов нету (вроде).

давно

Хотелось бы импорта a-la python import my-package as mp

http://www.sbcl.org/manual/#Package_002dLocal-Nicknames

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

С другой стороны простота концепции, когда первый аргумент s-выражения - функция, а остальные єлементы - параметры, имеет свой неприятный побочный эффект: огромное, неструктурированное пространство имен.

Во-первых, в Common Lisp есть пакеты. Они могут быть использованы как квалификаторы при обращении к именам из пакета: (foo:bar baz). Во-вторых, несмотря на «во-первых», в Лиспе принято использовать префиксы в именах функций и методов, т.е., если имеется класс baz, и его метод bar, то называть этот метод следует как baz-bar, а не просто bar. Да, это избыточно, но так делают почти все опытные лисперы-практики, а не теоретики-кукаретики.

Второй нюанс, ХЗ, может зависит от конкретной реализации. Все функции из заргуженных пакетов валятся в одно пространство имен.

Это ты про Emacs Lisp. Есть такой момент, поэтому нормальные люди просто используют префиксы к именам.

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

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

Совершенно верно. Классический Лисп больше подходит для одиночек-исследователей или для небольшой «притёртой» команды.

А галлеру, с ее текучкой, похоронит.

А вот для этого уже лучше Racket с его модулями и контрактами.

А по вопросу №1 можешь что-то сказать?

А по вопросу №1 можешь что-то сказать?

Если я правильно понял, первый вопрос о проблеме загрязнения пространства имён какого-нибудь пакета. Я уже ответил - в Лиспе принято использовать префиксы в именах функций и методов, т.е., если имеется класс baz, и его метод bar, то называть этот метод следует как baz-bar, а не просто bar. Например,

(defpackage my-package
  (:use cl)
  (:export person person-name set-person-name))

(in-package :my-package)

(defclass person ()
  ((name :reader person-name
         :writer set-person-name)))

Как видишь, имена методов имеют префиксы person- и set-person-, хотя можно было бы использовать имена name и set-name. Т.е. это, по сути, «правило джентльменов», да.

Когда завезут FFI

Держи. http://diobla.info/blog-archive/modules-tut.html
В 25 ещё завезли.

в той же java мне нужно помнить минимум ключевых слов

в lisp ключевых слов ещё меньше.

А галлеру, с ее текучкой, похоронит.

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

ИМХО этой выдержке и дисциплине нужно учиться самому программисту, а не оставлять специально язык с ограничениями типа того как своим путём пошёл проект Racket.

Просто это вот все - джентельменское соглашение, правила хорошего тона.

Я тебе больше скажу: соглашения — это единственный 100% работающий инструмент. Все остальные способы, не смотря на бравурные рапорты о достижении небывалой эффективности — имитация «правильного поведения», которая работает на 100% только при использовании тех же соглашений.

...и emacs lisp. Не понимаю как можно писать на нем что-то серьезное когда он создавался как язык расширения emacs. Там даже классов нету (вроде).

В базовом языке нет, но на нем сделали объектную систему. Кое-чего нет в реализации, но в целом сойдет. Но я эту библиотеку не использую.

https://www.gnu.org/software/emacs/manual/html_node/eieio/index.html

Лиспе принято использовать префиксы в именах функций и методов, т.е., если имеется класс baz, и его метод bar, то называть этот метод следует как baz-bar, а не просто bar.

В функциях смысл имеет такое, а вот с методами обобщённых функций большого смысла не вижу.

Вот чем этот код лучше чем:

(defpackage my-package
  (:use cl)
  (:export person name))

(in-package :my-package)

(defclass person ()
  ((name :accessor name)))

(defmethod (setf name) :after (value (person person))
  ...)

?

В функциях смысл имеет такое, а вот с методами обобщённых функций большого смысла не вижу.

Смысл в том, что это как раз решает проблему ТС - «огромное, неструктурированное пространство имен», потому что все обобщённые функции имеют префикс класса, тем самым, структурируя пространство имён и делая работу автодополнения внятной Так делают все опытные лисперы (привет Эдмунду Вайтсу). Посмотри на его код, например.

Если я правильно понял, первый вопрос о проблеме загрязнения пространства имён какого-нибудь пакета.

Не. Про то, что кучу встроенных функций хорошо бы разнести по пакетам. Например acos вынести в math/acos, а row-major-aref в arrays/row-major-aref, sbit в arrays/sbit и т.д.

в lisp ключевых слов ещё меньше

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

Например, тем, что теперь в пакете my-package могут быть 2 или 10 функций name, которых не видно в автодополнении этого вашего SLIME.

Не. Про то, что кучу встроенных функций хорошо бы разнести по пакетам.

Это то же самое, что задать им префиксы.

В базовом языке нет, но на нем сделали объектную систему

Не совсем так. В CL тоже нет. CLOS там в виде библиотеки. Ну и eieio входит в стандартную поставку emacs-а. Так что теперь это лишь детали реализации.

Это то же самое, что задать им префиксы.

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

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

Очень убого, только для твоих модулей.

The most important things this file defines is:
An emacs_value opaque type which is used to pass Lisp values to and from Emacs.
An emacs_runtime structure which is used to get an environment pointer.
An emacs_env structure that contains function pointers to the API.
...
You need to build Emacs with module support (it is disabled by default) and you need the emacs_module.h header.
...
Emacs modules must be GPL compatible. To enforce that Emacs checks for the presence of the plugin_is_GPL_compatible symbol before it loads a module.

Здесь лучше, хоть и не из коробки.

А как получил такой результат дополнения?

CL-USER> (my-package:)

Поставил курсор после двоеточия и M-x slime-fuzzy-complete-symbol.

Хотя наверно лучше s/name/name-of

Это даже с :local-nicknames работает.

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

Для галер строгого режима в промышленых реалиазациях включая sbcl есть блокировка паакетов. Паэтому случайно организовать там нестандартный cl:car не получится из-за умолчальной блокировки #<PACKAGE «COMMON-LISP»>. Свои пакеты тоже можно блокировать. Сверху можно повесить надзорный обработчик исключения.

Для галер строгого режима в промышленых реалиазациях включая sbcl есть блокировка паакетов

like

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

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

если имеется класс baz, и его метод bar, то называть этот метод следует как baz-bar, а не просто bar

Угу. А если потом появился наследник baz'а foo, то его новые методы будут foo-*, а унаследованные — baz-*. Как в GTK при работе из Си: методы одного объекта gtk_font_button_set_title, gtk_button_set_label, gtk_bin_get_child, gtk_container_child_get, gtk_widget_child_focus. Обрати внимание, что *child* размазаны по трём разным префиксам. И всё это надо помнить.

Не говоря уже, что писать (sequence-build (sequence-first x) (sequence-rest x)) после двадцатого повторения sequence начинает утомлять и если вдруг решил заменить тип переменной со списка на массив, то приходится исправлять все функции доступа.

или с кратким справочником на манер такого

Вот такое http://hyperpolyglot.org/lisp

Подойдёт?

Видишь костыль - сделай его библиотекой и нет костыля

Это в цитатник. Прямо таки закон развития любых программных систем.

Про то, что кучу встроенных функций хорошо бы разнести по пакетам.

Это можно сделать самому. Я начинал: https://github.com/Kalimehtar/cl-std

с кратким справочником на манер такого - нет.

http://clqr.boundp.org/download.html

методы, которые выясняются по автодополнению и доктипу

Смотрю, программирование вслепую очень популярно.

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

Надеюсь, вам никогда не придется переквалифицироваться во врача.

Ну нет, на врача учиться нужно.

Смотрю, программирование вслепую очень популярно.

Норма для тырпрайза. Я тоже бывало так писал на сисярпе. А что ж его учить прикажете?