Emacs 26.2

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

Нда.. «клуб теоретических пользователей» - что вы сделали со стандартным поиском? - какие дополнения вы используете часто? - сколько строк вы пишете на elisp?

С чего начать освоение emacs?

Я начинал с этого: https://www.emacswiki.org/emacs/Evil#toc1

Эм, во-первых важно, поскольку функция является именованной лямбдой.

Во-вторых, специфика лиспов в теории позволяет ввести столько скобок, сколько нужно. Одинарная кавычка же прижилась.

Некоторые вещи в Emacs можно поконфигурить через X Resources

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

(describe-function 'autoload)

К сожалению, autoload никак не поможет не загружать файлы, которые уже были загружены при старте. Более того, насколько я понимаю, нет функции, которая бы позволила выгрузить вон функциональность того же меню, например.

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

{a: 666, b: "hello", c: [1,2, {txt: "Hello"}]}

plist’ы же. ХЗ как в elisp, но в CL было бы как-то так:

'(:a 666 :b "hello" :c (1 2 (:txt "Hello")))

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

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

Отредактировать файл lisp/loadup.el, насколько я могу предполагать(возможно не только).

Конкретно меню-бар полностью выгрузить не получится, т.к. основная его гуёвая отрисовка в сишной части. И сама идея так себе, т.к. многие major-mode и бог весть что ещё могут его использовать(вписывать свои пункты как минимум).

Без ковыряния в исходниках скорее всего никак.

Оно еще и на подсветке кода тормозит дико. Это же, впрочем, и к виму относится

Специально провел эксперимент. Заметные глазом подлагивания начинаются на файлах > 300 тыс строк.

ИМХО, твоя претензия сравни претензии к камазу, за то, что тот тормозит при попытке потащить им локомотив с рудой.

// nvim

как убрать из него некоторые ненужные детали.

Ради чего?

не загружать файлы, которые уже были загружены при старте.

Какую проблему ты решаешь? Если проблему ублажения тараканов в голове, то ты ошибся форумом.

Emacs one love 💗

Это лицемерие какое-то 😠

https://github.com/emacs-mirror/emacs/commit/9344612d3cd164317170b6189ec43175...

Лисп умер когда умерла идея о символьном ИИ

Лисп умер потому что был закрытой системой. Изначально это не только не доставляло проблем, но было даже преимуществом, т.к. позволяло работать с компом на более высоком уровне чем «стопки перфокарт». Но когда появились развитые инструментальные средства, операционные системы и идея разделения обязанностей, лисп-системы с их закрытостью не смогли вписаться в новую реальность. Туда же отправились и форт-системы, и бейсик-системы и т.п. Далеко за примерами ходить не нужно, тот же emacs - типичная лисп-система «всё в одном»: и редактор и БД и браузер и WM и т.д. Свой замкнутый самодостаточный мирок, которому и операционная система по большому счёту не нужна.

Напоминает system-d в наши дни, как ни смешно сие звучит :) И финал будет примерно такой-же.

а JavaScript это Scheme +

JavaScript это не потомок Scheme. JavaScript — это выкидыш, который к сожалению сумел выжить.

Напоминает system-d в наши дни, как ни смешно сие звучит

Маятник качнулся в обратную сторону. Не удивительно, ведь оказалось, что у открытых систем есть свои недостатки. Микроядра, например, так и не взлетели, классический unix-way тоже оказался для многих задач не так хорош. Открытость несёт дополнительные накладные расходы и тут напрашивается очевидная параллель с теорией фирмы в экономике - открытость имеет преимущества только начиная с определённого масштаба. В связи с этим монолитный systemd вполне может быть лучше чем рассыпуха мелких скриптов. К тому же технологии написания программ стали лучше в смысле управления сложностью, поэтому теперь стали выгодными монолиты бОльших размеров чем раньше.

Эм, во-первых важно, поскольку функция является именованной лямбдой.

Выше читай.

Во-вторых, специфика лиспов в теории позволяет ввести столько скобок, сколько нужно. Одинарная кавычка же прижилась.

Выше читай.

Тоже выше читай %)

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

А в clojure?

Basic системы выжили, и живут теперь в .Net! Ну а форт он для маломощных машин. Но это «все в одном» конечно его губит, но я бы не сказал что это обязательное что то.

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

Он повторит историю Иксов и Вяленого.

История повторялась в прошлом, повторяется сейчас и будет повторятся в будущем...

Лексикон всё равно лучше всех

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

На lisp написаны все системы компьютерной алгебры (ну кроме Mathematica, оттого в ней так много багов). Я регулярно использую Reduce (он не на Common Lisp, а на Standard Lisp, который был до Common). Иногда использую Maxima, FriCAS (это форк Axiom - очень красивая система).

Basic системы выжили, и живут теперь в .Net!

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

форт он для маломощных машин

Всё равно что сказать, ассемблер - для маломощных машин. Уровень языка никак с мощностью не связан.

я бы не сказал что это обязательное что то

Это следствие закрытости, и да, это фича. Классическая работа с лисп-машиной это работа с образом, т.е. там не нужны, например, файлы и файловая система, ведь все переменные сохраняются. Все «программы» в лисп-системы - это функции этой лисп-системы, ну и т.д. Редакторы, браузеры, WM и всё, всё, всё будет у тебя внутри этой системы, её частью.

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

Да, для всяких МК! На нем пишут там постоянно, на в обычных ПК на нем пишут вставки разве что.

Слово и Дело

В своё время это был просто топчик! Такие бы таблички в org-mode завезли бы, была бы сказка.

Да, для всяких МК! На нем пишут там постоянно

Для MK можно писать на чём угодно, для этого есть кросс-компиляция.

Да, например можно собрать ReactOS и писать на C#, думаю 2кб озушки хватит на это дело!

Лисп умер когда умерла идея о символьном ИИ

Лисп умер потому что был закрытой системой.

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

https://www.tiobe.com/tiobe-index/

-> scheme + lisp + clojure = 0.813%

добавим туда elisp, пускай будет почти процент.

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

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

1% * экспрессивность. лисп нихрена не умер.

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

с чего вы все взяли, что он умер?

hh.ru -> lisp -> 0

История повторялась в прошлом, повторяется сейчас и будет повторятся в будущем...

Очень может быть, но на данный момент systemd до этого далеко.

историю Иксов и Вяленого

Вяленый что-то слишком вял пока. Мне так кажется, что я до заката эпохи иксов так и не доживу.

Напоминает system-d в наши дни, как ни смешно сие звучит :)

не напоминает, ты что то путаешь

И финал будет примерно такой-же.

им все будут пользоваться?

с чего вы все взяли, что он умер?

Он умер в идейном смысле. Физически он умереть не может, разумеется.

версия о «закрытости» звучит неубедительно

В чём неубедительно?

scheme + lisp + clojure

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

а что конкретно ты понимаешь под закрытостью? возможность взаимодействия с окружающей средой (ffi)?

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

что конкретно ты понимаешь под закрытостью

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

пример, где лисп бы не затащил в силу своей закрытости

Переломным моментом, ИМХО, стало распространение многозадачности. Что в CL, что elisp это до сих пор через жопу.

почему лисп, почти самый популярный язык в конце 80х, просто не развили в нужном направлении

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

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

Но есть и встречный процесс. A docker image, конечно, не соответствует один в один образу лиспа, но идейно они занимают одну позицию исполняемого «всё в одном» файла.

идейно они занимают одну позицию исполняемого «всё в одном» файла

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

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

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

Ради чего?

Ради добра и справедливости, конечно.

Какую проблему ты решаешь? Если проблему ублажения тараканов в голове, то ты ошибся форумом.

Упырь мел. Я, в отличие от местных троллей и тех, кто готов их подкармливать, решаю техническую проблему, а не пережёвываю в сотый раз тему про лисп и скобочки. Если на этом форуме разрешено только троллить и почёсывать своё ЧСВ, то для указания на это есть модераторы.

По твоему описанию к «закрытым системам» можно причислить, например, java. Это так? Если нет, то в чём разница? А если да, то почему тогда java взлетела?

Упырь мел.

Да не напрягайся так.

Но какая _техническая_ проблема требует решения в виде отключения загрузки компонентов Emacs-а? Тормоза? Потребление ресурсов? Что-то другое?

Но какая _техническая_ проблема требует решения в виде отключения загрузки компонентов Emacs-а?

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

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

Тормоза? Потребление ресурсов? Что-то другое?

Да.

избыточность

Что это значит?

отсутствие задач которые

И это тоже. Какую-то подзадачу можно решить скриптом на питоне, а можно и на лиспе или Go. Работать будет совершенно одинаково.

Переломным моментом, ИМХО, стало распространение многозадачности. Что в CL, что elisp это до сих пор через жопу.

а что сейчас не устраивает?

https://lispcookbook.github.io/cl-cookbook/process.html

есть несколько подходов, и не через какой-нибудь GIL, а «Modify a shared resource from multiple threads» с мьютексами и семафорами.

почему лисп, почти самый популярный язык в конце 80х, просто не развили в нужном направлении

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

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

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

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

определяй интерфейс в лисповой библиотеке -> готовь его через ffi -> профит. концептуальной сложности я тут не вижу.

на практике есть embedded варианты, которые бы могли это делать. примеры:

https://stackoverflow.com/questions/3223592/embedded-language-lua-vs-common-l...

https://chriskohlhepp.wordpress.com/advanced-c-lisp/embedding-lisp-in-cpluspl...

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

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

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

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

о том и речь что задачи которые ставились и /или возлагались на лисп и машины https://ru.wikipedia.org/wiki/Лисп-машина себя исчерпали в силу многих причин в т.ч. https://ru.wikipedia.org/wiki/Зима_искусственного_интеллекта . имхо бизнес не выдержал и спросил: «ну и где ваш интеллект? и где формальная теория? нет?! и денег нет!»

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

Собственно, я тоже думаю, что причины непопулярности у лиспа скорее социальные. Была академическая культура с лиспом, была культура хакеров с С, sh и perl. Академическое сообщество сдулось, а промышленное программирование взлетело в стратосферу. И инструменты разделили судьбу породившей их среды.

Слишком глубоко копаете. 99% виденных мною программ на python или ruby можно заменить один в один кодом на CL.

И чё ты мне предлагаешь такого вычитать?

Что прикладных программ нет? В userspace нет, не считая эмакса, а среди систем компьютерной алгебры и доказательства теорем лиспа более, чем достаточно. Особенно с учётом ML.

В остальном сейчас для нормальных задач проще использовать julia, читай лисп без скобок(гомо-язык с настоящими макросами).

что мешает CL быть одним из этих

Одним из этих пожалуйста, но речь не об этом. Попробуй сделать docker на лиспе. Можно конечно, но это будет что-то вроде JavaBeans.

Попробуй сделать docker на лиспе.

А какая разница делать докер на лиспе или на го? Это же просто обвязка вокруг ядерных cgroups и разных пространств имён.

Тут ещё можно Worse is better вспомнить.