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

Смотрю его книгу:
На страницах 53-54
на странице 57

Смотрю его код. И вижу у класса chunked-stream метод chunked-stream-stream, у класса chunked-input-stream методы chunked-stream-input-chunking-p, chunked-stream-input-index, chunked-stream-input-limit, chunked-input-stream-extensions, chunked-input-stream-trailers...

Так что не надо своё мнение приписывать известным людям.

Как видишь, это не только моё мнение.

chunked-input-stream методы chunked-stream-input-chunking-p, chunked-stream-input-index, chunked-stream-input-limit

Вот Вам и контрпример прямо в Вашей цитате: методы не начинаются на chunked-input-stream. Префикс к обобщённым функциям бывает, если он определяет протокол, к которому относятся функции. Но не класс.

P.S. Нашёл, кто придерживается Вашей точки зрения.

Accessor names generally follow a convention of <protocol-name>-<slot-name>, where a «protocol» in this case loosely indicates a set of functions with well-defined behavior.

...

By default, an abstract base class name is used as the notional protocol name, so accessor names default to <class-name>-<slot-name>; while such names are thus quite prevalent, this form is neither required nor even preferred. In general, it contributes to «symbol bloat», and in many cases has led to a proliferation of «trampoline» methods.

...

You must not use generic functions where there is no notional protocol. To put it more concretely, if you have more than one generic function that specializes its Nth argument, the specializing classes should all be descendants of a single class. Generic functions must not be used for «overloading», i.e. simply to use the same name for two entirely unrelated types.

More precisely, it's not really whether they descend from a common superclass, but whether they obey the same «protocol». That is, the two classes should handle the same set of generic functions, as if there were an explicit DEFGENERIC for each method.

(с) https://google.github.io/styleguide/lispguide.xml?showone=CLOS#CLOS

методы не начинаются на chunked-input-stream.

Во-первых, часть методов начинается: chunked-input-stream-extensions, chunked-input-stream-trailers. Во-вторых, другая часть методов начинается с chunked-stream - но у него там и класс такой есть под названием chunked-stream, который является родительским для chunked-input-stream. Почему автор не поместил эти методы в родительский класс - вопрос к нему как к проектировщику. Я считаю, что он не прав, но это такое.

P.S. Нашёл, кто придерживается Вашей точки зрения.

А, ну вот :-) Хотя я, честно-честно, не имею к тем ребятам отношения :-)

часть методов начинается

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

Например, есть рекомендуемый другими уважаемыми людьми метод называния аксессоров <field>-of.

Что касается префикса-протокола, то в новых библиотеках стараются протокол указывать в имени пакета, а не в имени функции. То есть вместо chunked-stream-input-chunking-p должно быть chunked-stream:input-chunking-p.

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

Эх, загрузить из файла или по сети неведомое описание на DSL и наметаконпелировать классы и всякое такое в свой пакет, а потом просто всё махом грохнуть, и как-будто ничего не было, и вот прям щас загружай по-новой - счастье! И некоторые программки на DSL расширяли сам движок DSL, привнося нужные себе фичи, которые в изначальной архитектуре предусмотрены не были, и это тоже потом откатывалось в исходный вид. Адепты C++ и XML вдвоём это за полтора года не смогли переписать на «нормальных технологиях», так оставили :)

А как ты запоминал 100500 функций базовой поставки? Или просто самое необходимое, а остальное гуглил?

И, чтоб 2 раза не вставать: ты такой вот use case emacs-а не используешь А как вы используете emacs? ?

А как ты запоминал 100500 функций базовой поставки? Или просто самое необходимое, а остальное гуглил?

В основном, всё самописное в конторе было. Александрию и т.п. не пользовались. Моменты по взаимодействию с осью, FFI, мультипроцессингу и особенностями имплементации (LW) смотрел в официальной документации. Автокомплитом того, не знама чаво, никогда не пользовался, даже когда на плюсах тыкал. Так же, как и дебаггером для пошаговой отладки или даже брейкпойнтов.

И, чтоб 2 раза не вставать: ты такой вот use case emacs-а не используешь А как вы используете emacs? ?

10 лет назад я в Емаксе делал всё, даже читал почту и смотрел сайты (когда вебдваноль в файерфоксе надоедал вконец). Ну терминалов ещё пачка была открыта, в Емаксе это неудобно. Сейчас почти вся работа в консоль перекочевала, Емаксом пользуюсь, как чуть более удобным mcedit'ом.

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

А какую это все приносило практическую пользу?

Да какая нафиг анонимность, это всем известный Серёжа Марков же. И он просто ужас какой говнокодер.

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

внезапно, http://www.cheat-sheets.org/#Lisp (и 10500 других)

исходники на LaTeX: здесь

А какую это все приносило практическую пользу?

One ring to rule them all. Одна софтина все текущие и будущие варианты ПЛИС-прошивок поддерживала, и имела одинаковый набор фич для всего.

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

cheat sheet выше с 26 страницами.