Оптимизации в Common Lisp

Там имакс.

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

однако стоит всё-же признать что без лисп-машин лисп на х86_64 это эмуляция и костыли, много костылей. Это всё не к тому что всё настОлько плохо. нО,, аппаратная тегированная память для типов, специальные инструкции для бигинтов и многое другое говорит о том что увы.. язык для современной процессорной архитектуры это сишка, в силу того что спека со времени Фон-Неймана не менялась. Смысл лиспа, как языка на этом всём, в случае оптимизации теряется напрочь. Увы это фак т

Вот да, было бы круто!

Книги по CL есть почти на любой вкус и уровень, начиная от Land of Lisp и PCL.

А вот учебных курсов по технологии разработки на CL, которые связывали бы «книжное знание» с актуальной практикой, можно сказать, что совсем нет.

А вот учебных курсов по технологии разработки на CL, которые связывали бы «книжное знание» с актуальной практикой, можно сказать, что совсем нет.

Я думаю их нет по причине отсутствия актуальной практики в CL.

их нет по причине отсутствия актуальной практики в CL

Ряд проектов на CL активно развивается, а актуальной практики нет?

Ряд проектов на CL активно развивается, а актуальной практики нет?

Я понимаю что мы всех хотим чтобы лиспы были популярнее, чем они есть, но три с половиной проекта это не актуальная практика. Большая часть программистов проходит свой профессиональный путь не догадываясь о существовании CL.

Большая часть программистов проходит свой профессиональный путь не догадываясь о существовании CL.

Миллионы мух предпочитает гумно не догадываясь о существовании мёда.

Спасибо за доклад!

Но чисто технический момент. Есть видео в лучшем, чем 720p разрешении? А то толком ничего не видно на экране.

С момента знакомства с Lisp’ом хочу lisp для совсем мелких однокристаллок. Типа всяких PIC10/12/16/18 и прочих ATTiny.

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

Миллионы мух предпочитает гумно не догадываясь о существовании мёда.

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

нишу Go вполне мог бы занять какой-нибудь лишп

Для этого лиспу пришлось бы сначала пережить жэстачайшее обрезание.

Для этого лиспу пришлось бы сначала пережить жэстачайшее обрезание.

А пришлось бы? Нужны были бы примеры «делай вот так и HTTP запрос вжух-вжух» и аналог go <func>. В Go даже модули появились не то чтобы давно.

Ну, для С++ встроенный ассемблер сейчас не важен

Плюс к этому, совсем упоротые могут включить в проект листинг на любимом диалекте, и линковаться из C/C++ к объектнику ассеблера.

Миллионы мух предпочитает гумно не догадываясь о существовании мёда.

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

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

Айтишечка тут не хуже и не лучше.

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

Всё так. Но её ж не один-единственный Бженчковский целиком придумал.

три с половиной проекта это не актуальная практика

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

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

мог бы

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

но раз этого не происходит, значит индустрия в CL не нуждается

Обратите внимание, решь шла об интересующихся CL, а не об индустрии в целом.

Вы ведь не против, что кто-то интересуется CL?

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

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

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

задачи общего програмирования, хоть и могут быть на нем реализованы но в вырвиглазно-черезжопной манере

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

Обратите внимание, решь шла об интересующихся CL, а не об индустрии в целом.

Нет, речь шла об индустрии в целом. Интересующиеся найдут себе источник информации самостоятельно, на то они и интересующиеся

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

Это очень оценочное суждение. Метапрограммирование на LISP в разы проще прочитать, чем шаблоны C++. Можем сравнить какой-нибудь код.

чем шаблоны C++.

а вы не читайте шаблоны с++ и не пишите их без надобности.

а вы не читайте шаблоны с++ и не пишите их без надобности.

Это бессмысленное заявление, шаблоны это по сути база для любой структуру данных.

шаблоны это по сути база для любой структуру данных.

шаблоны в с++, это такая приблуда, чтобы классы ручками не писать. и не более. можно написать ЛЮБУЮ на с++ программу без единого шаблона.

шаблоны в с++, это такая приблуда, чтобы классы ручками не писать. и не более. можно написать ЛЮБУЮ на с++ программу без единого шаблона.

Можно написать любую программу на brainfuck, дальше-то что?

дальше-то что

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

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

дальше то, что никакой «базой» шаблоны не являются

Являются, почти все библиотеки реализующие что-то общее, делают это через шаблоны. Начиная от STL и заканчивая очередным специализированным параллельным lockless деревом. Отрицать это – значит отрицать очевидное.

Начиная от STL

так stl и есть библиотека шаблонов.

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

все ваши чаяния, если бы, да кабы, да вот как было бы здорово

Вы ведь это сами придумали))

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

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

Можно ли упихать лисп в 64 байта - х.з. Я даже не знаю можно ли лисп или его подобие (без генерации кода лямбдами) реализовать на гарвардской архитектуре. Просто спросил, вдруг у кого-то получилось…

ladder logic иногда слишком туп для эмбедных задач и хочется чего-то более продвинутого. Лисп подошёл бы.

а есть языки в которых нет шаблонов вообще и все работает.

Например? С? Даже списки (<sys/queue.h>, например) реализованы через настолько жуткую макродичь, что туда смотреть не хочется ещё больше, чем в шаблоны.

шаблон это просто удобно иногда. принципиального смысла он не имеет

Шаблон это база для generic’ов. Без generic’ов не существует современного программирования. О чем мы спорим-то? Если ты отрицаешь, что структуры данных должны быть общими и не требовать от писателя каждый раз писать их с нуля под задачу, то нам просто не о чем говорить, ты некомпетентен. Даже в Go это уже поняли и принесли.

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

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

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

и вообще тут обсуждают лисп, а не шаблоны с++

Например? С? Даже списки (<sys/queue.h>, например) реализованы через настолько жуткую макродичь, что туда смотреть не хочется ещё больше, чем в шаблоны.

Ты просто в C++ list не заглядывал, иначе бы посчитал sys/queue.h вершиной элегантности.

namespace std _GLIBCXX_VISIBILITY(default)
{ 
  _GLIBCXX_BEGIN_NAMESPACE_VERSION _GLIBCXX_BEGIN_NAMESPACE_CONTAINER

  template<typename _Tp, typename _Alloc>
    void _List_base<_Tp, _Alloc>:: _M_clear() _GLIBCXX_NOEXCEPT
    {
      typedef _List_node<_Tp>  _Node;
      __detail::_List_node_base* __cur = _M_impl._M_node._M_next;
      while (__cur != &_M_impl._M_node)
        {
          _Node* __tmp = static_cast<_Node*>(__cur);
          __cur = __tmp->_M_next;
          _Tp* __val = __tmp->_M_valptr();
          _Node_alloc_traits::destroy(_M_get_Node_allocator(), __val);
          _M_put_node(__tmp);
        }
    }

  template<typename _Tp, typename _Alloc>
    template<typename... _Args>
      typename list<_Tp, _Alloc>::iterator
      list<_Tp, _Alloc>::
      emplace(const_iterator __position, _Args&&... __args)
      {
        _Node* __tmp = _M_create_node(std::forward<_Args>(__args)...);
        __tmp->_M_hook(__position._M_const_cast()._M_node);
        this->_M_inc_size(1);

Какой прекрасный С++ код по сравнению с этим сишным нечитаемым монстром:

#define	SLIST_FIRST(head)	((head)->slh_first)
#define	SLIST_END(head)		NULL
#define	SLIST_EMPTY(head)	(SLIST_FIRST(head) == SLIST_END(head))
#define	SLIST_NEXT(elm, field)	((elm)->field.sle_next)

#define	SLIST_FOREACH(var, head, field)					\
	for((var) = SLIST_FIRST(head);					\
	    (var) != SLIST_END(head);					\
	    (var) = SLIST_NEXT(var, field))

#define	SLIST_FOREACH_SAFE(var, head, field, tvar)			\
	for ((var) = SLIST_FIRST(head);				        \
	    (var) && ((tvar) = SLIST_NEXT(var, field), 1);		\
	    (var) = (tvar))

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

Совершенно правильная мысль – если кто-то уже написал std::map, не надо писать std::map заново, без веской на то причины.

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

Я хочу rbtree с произвольным значением. Сейчас в нем только int:

struct RBNode {
    RBNode* parent;
    RBNode* child[2];
    int value;
}

Покажи мне как это записать в C++ без шаблонов и void *.

и вообще тут обсуждают лисп, а не шаблоны с++

И на примере шаблонов отлично видны сильные стороны LISP.

Ладно, признаю, queue.h это была ошибка, он слишком простой.

Покажи мне как это записать в C++ без шаблонов и void *.

Я не пишу на C/C++, но если бы писал...

Что бы шаблоны не раздували код, я бы сделал char value[], и функции которые принимают размер хранимого элемента что бы правильно выделить RBNode.

И лишь поверх этих функций я бы добавил шаблонную обвязку

void RBNode<T>::RandomFunction(T *val) {
  RBNode::RandomFunction(&val, sizeof(T));
}

Чисто для авто-проверки типа и сокращения писанины.

И лишь поверх этих функций я бы добавил шаблонную обвязку

Ты грубо нарушил принцип наименьшего удивления и все равно использовал шаблон. Кажется что проще сразу было шаблон использовать.

Кажется что проще сразу было шаблон использовать.

Тогда он нагенерирует ненужных методов для каждого типа, и нельзя будет использовать элементы произвольного размера. Я вижу одни минусы.

Я хочу rbtree с произвольным значением.

это можно сделать даже на си. пишешь свое дерево с именем типа - T в inc файле. потом пишешь в другом файле

#define T my_type
#include "rbtree.inc"

и тип у тебя стал my_type.

то есть ты тупо текстовой подстановкой получил псевдотеймплейты.

Тогда он нагенерирует ненужных методов для каждого типа, и нельзя будет использовать элементы произвольного размера. Я вижу одни минусы.

Ты только что реализован интерфейсы на Go или struct list_head из ядра. Одно невереное движение и ты получил memory corruption, вытащив не тот тип из структуры, что нужно. Помимо экономии на спичках получили потенциальный RCE. Зачем так делать?

это можно сделать даже на си. пишешь свое дерево с именем типа - T в inc файле. потом пишешь в другом файле

Потом потребуется добавить функцию хеширования для каждого типа и получится уже <sys/tree.h> из OpenBSD. Чем это отличается от шаблонов, напомни?

Потом потребуется добавить функцию хеширования для каждого типа..

что там тебе потом понадобится никого не интернесует. я на вопрос ответил? ответил. либо переформулируй вопрос, либо принимай ответ как есть.

<sys/tree.h> из OpenBSD. Чем это отличается от шаблонов, напомни?

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

Ты только что реализован интерфейсы на Go или struct list_head из ядра. Одно невереное движение и ты получил memory corruption, вытащив не тот тип из структуры, что нужно. Помимо экономии на спичках получили потенциальный RCE. Зачем так делать?

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

Если ты определил RBTree<int> то не сможешь вызвать методы с char*. А внутри идет работа с безтиповыми данными.

В Go совсем по другому сделано, там void *value; а тут я предложил char value[] - Flexible array member.

что там тебе потом понадобится никого не интернесует. я на вопрос ответил? ответил. либо переформулируй вопрос, либо принимай ответ как есть.

Так я и так знаю ответ: тебе не нравятся шаблоны, ты знаешь только сишный препроцессор -> ты пользуешься только сишным процепроцессором.

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

Это твой недостаток.

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

Не, погоди. Вот у тебя два дерева: в одном string, в другом int. Что мешает мне вызвать функцию, которая получает int, на дерево, в котором string?

Если ты определил RBTree то не сможешь вызвать методы с char*. А внутри идет работа с безтиповыми данными.

Если ты шаблонизировал struct RBTree, зачем страдание с char *?