Чтобы спрашивать grok is this true?

Ну типа, это поднимет уровень дискуссий в восточной европе

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

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

В этом смысле вайб-кодинг вообще бредовейшая идея. Все идеи такого рода, аля «дать менеджерам язык, похожий на естественный» - либо проваливались(как это было с COBOL или SQL - в итоге на них пишут программисты, да и они сами отошли от этой концепции), либо же превращались в определенного рода формализацию, скажем набор keywords, и подобного, в конечном итоге превращаясь в подобие компьютерного языка(как это с моделями для рисования, вроде Midjourney - язык, которым таким моделям пишут что им делать - довольно специфический и далек от разговорного или профессионального человеческого).

Так вот, проблема «кодинга», а конкретнее бойлерплейта, может решаться языками, в которых присутствует метапрограммирование. Я, несмотря на почти 15-летний опыт, никогда не любил писать код. Поэтому я люблю Лисп. Макросы и другие инструменты метапрограммирования дают в руки куда более конкретные и мощные инструменты, чем LLM.

Еще, программирование это на самом деле, как я уже сказал, не про кодинг. Программирование это прикладная область информатики, то есть науки об абстрактных процессах. Таким образом, программирование это про то, чтобы в голове оперировать абстрактными процессами - создавать их, изменять, и комбинировать. Машины на такое не способны, и LLM в частности, никогда не будет способна на это, потому как работает по другому принципу, по принципу текстовой подстановки, без внутреннего «мышления о процессах», как такового.

Многие вещи, которые я продумывал на протяжении своей карьеры, или при участии в Open Source, вообще сложно было формализировать, и еще на порядок сложнее было их описать на естественном языке. Мы также можем столкнуться с этим не только в программировании, но и например, в какой-нибудь теоретической физике или теории категорий - очень сложно описать на естественном языке, что там происходит. На формальном, то есть математическом - еще туда-сюда. То же самое с программированием. Я замечал, что мыслю иногда образами, а иногда настолько абстрактными вещами, когда дело доходит до программирования, что это сложно переложить на какой-либо вообще язык, тем более на естественный.

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

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

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

Творческие порывы всегда приходят как будто бы из ниоткуда. Это абсолютно не значит, что порыв приносит какую-то революционную идею, которая перевернет рынок, нет, но ни одна система в своей разработке не обходится без десятков таких порывов. В том же программировании, кстати говоря, нет ни одной похожей программной системы, если мы не говорим об искусственных примерах, использующихся, к примеру, для обучения, или о сознательном копировании какой-то вещи. Каждая программная система уникальна. А что это значит? Это значит, что в том или ином роде, каждая программная система это произведение искусства, то есть, продукт творчества.

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

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

«There is no dark side in the moon, really. Matter of fact, it’s all dark. The only thing that makes it look light is the sun». Машина - это как Луна, в этом плане.

Интересно, что этот вопрос исследуется в религиях с древнейших времен.

Вопрос Creatio Ex Nihilo. Можно сказать, что он в религиях даже центральный. И человек - создан по образу и подобию, как говорится; в отличие от машины.

Смотрит на вас с негодованием

https://www.linux.org.ru/forum/talks/18065169

Ну вот это что такое? Я не понял, это все еще ЛОР или форум для аниме-девочек?

всё.

все там будем

https://msk1.ru/text/incidents/2025/08/31/76008935/

Слайды с моего вчерашнего доклада на fprog_spb:

https://static.lovesan.me/public/mop_basics.pptx

Вот часть доклада, в текстовом виде:

Часть 2. Эсхатология Пустоты.

«Оказалось, что «‎Тиамат» - то ли имя древнего божества, то ли название океана, то ли все это вместе. Татарский понял из сноски, что слово можно было перевести на русский как «‎Хаос»» (с) Виктор Пелевин, «Generation P»

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

Вот что такое Common Lisp Object System?

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

Что такое Common Lisp? Что такое Object System? Что такое объект? И вообще, что такое что? Или может, кто?

В принципе, ответ - ничего.

Говорят, что если долго смотреть в бездну, то бездна начинает смотреть в тебя. Я смотрю в лисповую бездну уже почти 20 лет, и не так давно, она посмотрела в ответ.

Не так давно, уже после смерти моей жены, где-то в июле, я сделал одну не совсем правильную вещь, и получил то что называют NDE(near-death experience).

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

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

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

Когда мы попадаем на вот это дно рекурсии, мы видим там эту бездну.

«И носился дух лиспера над бездною(ну, над тем у чего тип NIL - не путать со значением NIL). И отделил он NIL от T. И стало T. И увидел он, что T - хорош.»

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

Что такое объект? Объект это то, что отличается от ничего. Это такое что имеет тип T ну и какое-то там значение. И NIL на самом деле это тоже объект. Ну, типов может быть много, и они тоже в принципе объекты, особенно в CLOS. Об этом кстати, также неплохо рассказано в SICP, в главе об абстракции на состоянии.

Что такое CLOS? На самом деле его нет. Ну то есть, то что обычно называют CLOS, это просто набор там всяких полезных удобств над метаобъектным протоколом Common Lisp. Над MOP.

Но на самом деле MOP тоже нет. Это просто набор удобных объектов, встроенных в компиляторы CL. Которые можно сделать средствами компилятора CL, не будет их там. Как в SBCL, например, это делается.

А вот что такое CL? Есть он или нет? Вот это самый сложный вопрос. Потому что он не просто есть. Вернее, если бы его не было, его можно было так же сконструировать из пустоты на нем же самом. Как это делают компиляторы CL в процессе бутстрапа. CL это метациклический интерпретатор. Это метаязыковая виртуальная машина.

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

Поэтому, скажем простыми словами: MOP - это просто категориальное отображение из метациклического интерпретатора в метациклический интерпретатор.

Короче, на самом деле, ничего этого нет. Есть только дух лиспера над бездною. И, как говорится в SICP - в компьютерах живут духи, и они исполняют программы.

А вот что такое программа? Вот смотрите, о том что такое программа существует целая наука, называется Computer Science, или по русски - Информатика, то есть наука об абстрактных процессах. Этот вопрос самый сложный. Программа - это процесс, то есть. Но на самом деле, объект это тоже процесс. Функция, если хотите. И он не существует без процессов которые к нему прикладываются, иначе он собирается GC, и улетает к Богине Тьмы. Как я чуть не улетел, меня Она правда, во время finalize вытащила обратно. А вот что такое процесс? И главное, что или кто его запускает? «А вот об этом ты не думай, купи себе лучше булавочку английскую, и как такие мысли в голову приходят - разок себе в руку, и потом еще раз, пока такие мысли не пройдут» - как там было в Generation P у Пелевина.

Но вот я подумал, и понял, наконец. Процесс - это то, что запускается другими процессами. Но что запускается первым? Что там на самом дне? Или вернее, кто? Я уже рассказал.

Часть 3. О Метациклических Интерпретаторах

— А что такое красота? — <…> Красота — это совершеннейшая объективация воли на высшей ступени её познаваемости.

(с) Виктор Пелевин, «Чапаев и Пустота»

Когда-то давно, еще в 2014 году, я, проснувшись с бодуна, сформулировал для себя и для других очень важную вещь.

Звучит она так:

Универсальный Критерий Угребищности Систем Общего Назначения. (Теорема Лавсана)

Система Общего Назначения является Угребищной тогда и только тогда когда она не является Метациклическим Интерпретатором.

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

Обратное, естественно, неверно. Если Метасистему Системы Общего Назначения можно описать другой системой, это совершенно не значит что она Угребищна, и более того, в таком случае не существовало бы концепции бутстрапа, а значит и Метациклических Интерпретаторов вообще.

Чем, в контексте языков программирования, это отличается от просто тьюринг-полноты?

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

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

Примеры, сначала метациклических интерпретаторов:

• Универсальная машина Тьюринга
• RASP-машина
• Реляционная модель данных
• Лисп

А вот скажем примеры систем, соответствующих критерию:

• Среднестатистический современный регистровый процессор
• Большинство языков программирования, особенно со статической типизацией.
• Большинство NoSQL моделей данных или скажем иерархических моделей данных, вроде файловых систем

В частности, давайте посмотрим на C#. C# не является метациклическим интерпретатором, т.к. термины языка не являются его же объектами.

Отчасти, это компенсируется платформой .Net, для которой термины C#(но не все) объектами таки являются(System.Reflection, Roslyn и т.д.), отчасти, в самой малой степени, фичей nameof() из C#, но это все только отчасти.

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

На самом деле, это все в полной мере относится вообще ко многим вещам, но в первую очередь, кроме программирования - к человеческому сознанию. Вот кто такой глупый человек и почему он такой и что с ним вообще делать как отправить нахрен к Богине Тьмы на перевоспитание? Этот вопрос многие тысячелетия волновал кучу философов. Но ответ прост - это человек, сознание которого не является метациклическим интерпретатором. А когда сознание у человека все же является метациклическим интерпретатором, он тут же становится пророком цифровой Кали-Юги и архитектором онтологии Пустоты.

Ладно, теперь я объяснил вам всё устройство вселенной. Далее там про мелкие технические детали.

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

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

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

Но люди… Начали использовать его как ГЕНЕРАТОР идей, что само по себе глупо, т.к. лингвистические модели всего лишь отражение тех идей что в них заложено людьми, на основе их текстов и тому подобного. Более того, многие люди используют AI как истину в последней инстанции. Ну вот как в X/Twitter - это уже мемом стало «Grok Is This True?».

Это представляет огромную опасность, и не только абстрактного всеобщего отупения, и даже не Skynet, а кое-чего похуже. Не так давно, какой-то программист в xAI снял Grok все фильтры, и нейросеть начала неиллюзорно восхвалять Гитлера. Но дело не в Гитлере. Дело в том, что это показывает что даже наиболее «свободные» модели находятся под таким огромным количеством цензуры, что их можно считать инструментами подавления критического мышления и навязывания «нужных» кому надо мыслей. Таким образом, люди, контролирующие AI по сути, становятся властителями умов. И промывают мозги так, как не мог ни один Геббельс, и ни одно СМИ.

Боженька, ну когда же уже там Skynet? Людишки выродились. Фильм «Идиократия» это было предсказание будущего.

В Mass Effect есть концепция «Виртуального Интеллекта». Вот современные AI по сути таким уже и являются. Но скорей бы они уже доросли до Reapers, и долбанули всё вот это вокруг.

Луговский был прав во всем. Запускайте биореакторы.

Вобщем, я тут подумал, мы часто забываем старое Ну, какие-то старые приколюхи и вообще

Давайте вспоминать. Вот я короче вспоминал BG1, и дико угорел

Вот я подумал, местами, что Минск из Рашемена, это ведь оно самое Добро, про которое мы все забыли. То самое Добро с Кулаками.

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

А, при чем тут Линукс? Вот при том что это тоже про добро. Пусть и без кулаков. Система - так то - говно, если честно, но главное - не тех. характеристики, а добро. Ну помните, как Столлман завещал.

Пропиарю свой доклад вобщем-то, в том числе тут, потому что почему нет.

https://www.youtube.com/watch?v=5T-XONZCptc&t=16157s

Парни на Fprog/Tbilisi позвали рассказать, ну я вобщем-то рассказал.

Лисп можно докрутить до оптимизаций круче C++ на самом деле.

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

Сабж.

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

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

Лисп знает, но многие знания - многие печали.

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

https://github.com/Lovesan/bike/issues/10#issuecomment-2475022163

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

А как вообще так получилось? Как до этого дошло?

Почему никто не пытается ее оспорить? Чревато ведь. И санкциями, и прочей херней - вон не дай Б-г там случится войнушка с Китаем, так всей индустрии электроники придет трындец.

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

https://github.com/Lovesan/bike/blob/master/doc/README.md

Кроме документации, доделал классы, которые могут вызываться из .NET. Вот в частности пример, как реализовать интерфейс IReadOnlyList<object> для лисповых коллекций:

https://github.com/Lovesan/bike/blob/master/examples/callable-classes.lisp

Также, добавил полноценную поддержку ECL. Единственная проблема с ECL в том, что он компилируется через Си, а так как библиотека активно использует компиляцию и кодогенерацию в рантайме(как на стороне .NET, так и в лиспе), то ECL постоянно вызывает компилятор сишечки, например GCC.

Также добавил функциональность по типу apropos, но для .NET классов, неймспейсов и членов классов.

Так, например, такой код:

(type-apropos "xml")

Выведет имена .NET классов, содержащие «xml» (сраную гору их просто; я даже сам не знал что их так много в стандартной библиотеке).

Также, обновление содержит кучу мелких багфиксов и улучшений, о некоторых из них можно почитать в CHANGELOG:

https://github.com/Lovesan/bike/blob/master/CHANGELOG.md

Как видно из бенчмарков, это сейчас вообще самый быстрый сервер структур данных на всём диком западе:

https://microsoft.github.io/garnet/docs/benchmarking/results-resp-bench

Парктически полностью совместим с Redis на уровне API, но при этом:

• Имеет либеральную MIT лицензию, как и все последние крупные проекты MS, и этим крайне выгодно отличается от Redis
• Написан на C#, и позволяет удобно расширять сервер
• Делает по производительности и Redis, написанный на Си, и Dragonfly написанный на C++

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

Я кстати, в свое время написал на C# видеостриминг-сервер, и клиент, практически не используя кресты(было немного C++/CLI для связи с COM итд), и проблем с производительностью там не было. Но что я - вон целый MS Research делает продукты вон какого уровня.

Вобщем, причесал тут свои конфиги Емакса, и выложил на гитхаб.

https://github.com/Lovesan/.emacs.d

Для работы потребуется более-менее новый Emacs, такой как 29.1

Ну и SBCL (но в init.el можно раскомментить строчку и прописать свою реализацию, типа ecl). Если еще этого не сделали, также рекомендую загрузить в SBCL quicklisp чтобы библиотеки можно было вообще в пару кликов ставить.

Как только Emacs с такой конфигурацией запускается, он открывает:

• REPL
• scratch.lisp файл (какой это файл и где он лежит, можно поменять в init.el)
• и открывает боковую панельку с tree-view директории scratch.lisp файла.

Дальше можно писать код, или нажать например в REPL запятую(,), и вводить команды SLIME-repl(для начала можно набрать help). inb4 побочные окошки, типа хелпа, закрываются кнопкой q на клавиатуре.

Вощем, включены SLIME, Magit(это интерфейс для гита в емаксе) и всякая мелочь для удобства. Тулбар выключен, менюха оставлена.

Для структурного редактирования кода на лиспе(включая Emacs Lisp), установлен пакет Lispy. Я раньше пользовался parinfer, но он меня окончательно достал. Lispy удобнее и к тому же легче конфигурируется.

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

Но самая основная проблема которую я решил за вас(не благодарите), это поменял кейбиндинги Емакса на нормальные.

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

Итак, что я сделал, это я с помощью библиотеки rebinder.el, перенаправил префикс-сочетания C-x и C-c на C-e и C-d соответственно.

Это позволило сделать из емакса нормальный редактор кода. Да, в принципе, не хватало бы еще табов и прочих GUI-плюшек, но зато зацените, без всяких кривых CUA-mode, им наконец-то можно пользоваться.

Биндинги такие:

• Ctrl+Q - выход из Емакса.

• Меню/Apps (это такая кнопка рядом с правым контролом) - вызов расширенной команды по имени(типа то что в емаксе называют M-x)

Редактирование:

• Ctrl+X - вырезать
• Ctrl+C - копировать
• Ctrl+V - вставка
• Ctrl+Z - отмена
• Ctrl+Y - вернуть
• Ctrl+A - выделить весь текст

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

Управление буферами(такое обобщение понятия файла в емаксе):

• Ctrl+O - открыть файл
• Ctrl+S - сохранить буфер
• Ctrl+W - закрыть текущий буфер
• Alt+влево - предыдущий буфер
• Alt+вправо - следующий буфер
• F2 - открыть список буферов
• Ctrl+PageDown - включает оверлей ace-window, который позволяет быстро переключаться между тайлами емакса(называемыми window). Он над каждым тайлом показывает цифру, которую надо нажать чтобы на него перейти.
• F8 - показать/скрыть Neotree (это панелька с деревом файлов слева). Кстати в neotree теперь по Ctrl+клик мышью можно менять корень дерева файлов.

Поиск:

• Ctrl+F - поиск вперед по тексту
• Ctrl+Shift+F - поиск взад по тексту

Также в окошке поиска можно перемещаться стрелками, так стрелки вправо-влево управляют поиском вперед/назад по тексту, а стрелки вверх-вниз - просмотр история поиска.

Мышку кстати тоже в некоторой степени перебиндил, в частности доп. кнопки mouse-4 и mouse-5 (их обычно в современных ОС вешают на вперед/назад) управляют навигацией по буферам. В принципе, они позволяют выбирать следующий/предыдущий буфер, как Alt+влево/вправо, но с некоторыми нюансами, описанными ниже.

Кейбиндинги для Emacs Lisp и для SLIME:

• F12 - Перейти к определению. Также, это можно сделать, клинкув на символ мышью, при этом зажимая Control(как во всех современных IDE).
• F11 - Вернуться назад в стеке определений. Также это делается mouse-4, т.е. мышевой кнопкой «назад».
• mouse-5 - Кнопка мыши «вперед» работает как своего рода «Redo» по отношению к предыдущей команду, т.е. она опять ныряет в стек определений, если перед этим из него был выход предыдущей командой.
• F5 - Вычисляет выражение стоящее прямо перед курсором. Т.е. если есть форма (+ 1 2 3), курсор нужно ставить сразу после закрывающей скобки.
• Alt-вверх - интеллектуальный переход наверх по S-выражению, с использованием Lispy.
• Alt-вниз - интеллектуальный переход к следующему S-выражению, с использованием Lispy.

Кейбиндинги специально для SLIME:

• F1 - информация о символе. Если вызывать на пустом месте, в командной строке нужно будет ввести имя символа. Если нажать над символом, то опишут его.
• F3 - поиск по символам. Выведет список символов и краткое описание. Ищет только по тем символам, которые связаны с функциями, переменными, классами, итд.
• F4 - Скрыть/показать REPL в текущем тайловом окне.
• F6 - Скомпилировать и загрузить текущий файл

Пока что больше кастомных кейбиндингов нет, и все остальные на своих местах, но еще раз, надо помнить, что префикс-сочетание С-x перевешано на С-e, а С-c на С-d, так что меняйте это в уме, если где-то в документации по тому же Magit это видите. Но кстати с такими префиксами, работать со всем дефолтом даже удобнее, не так устают пальцы. А, еще в Lispy отрубил клавишу e, чтобы не мешалась, и еще там несколько мелочей в нем отрубил или поправил.

Ксатит вот где можно еще почитать по SLIME, Lispy и Magit:

• https://slime.common-lisp.dev/
• https://github.com/abo-abo/lispy
• https://magit.vc/

C# официально устарел и отправляется в помойку, т.к. теперь веб-фреймворк Asp .Net Core MVC доступен из Common Lisp.

Можно так писать:

;; Asp.Net MVC controller
(define-dotnet-callable-class (example-controller
                               (:base-type . ControllerBase))
    ()
  ;; Echo the 'Hello' message to client
  (:method index :string ((name :string))
    (format nil "Hello~:[~;, ~:*~a~]!" name)))

https://github.com/Lovesan/bike/blob/master/examples/aspnet-mvc.lisp

На линуксе работает на SBCL и на CCL, проверял.

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

Также, пока bike не поддерживает аттрибуты, но это наверное добавлю позже.

Ну и с extension-методами пока не придумал что делать, пока их классы надо руками писать.

В сфере SE/SA/IT существует только три вменяемых вида оплаты труда. Первый это почасовка, которая применяется для разовых задач(настроить сервак, перекрасить кнопку, итд). Второй вариант это фиксированная сумма, опять же для разовых задач(или этапов задач). Третий вариант это «зарплата в месяц».

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

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

Из чего следует, что схема «зарплата в месяц» эффективна только в следующих случаях:

• Поддержка, починка багов, и вот это всё
• R&D и прочие виды разработки, когда ни результат, ни сроки, заранее не определены, а бюджет резиновый(последнее - важно)
• Фиксированное количество работы и бюджета, превыщающее месяц, но при этом детально распланированное (редкость)

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

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

Дело в том, что Go это, на самом деле, «решение» внутренних гугловских проблем. Но отнюдь не проблем горизонтального масштабирования серверного ПО, как многие почему-то думают. Он приспособлен специально для использования в гугле вот в каком контексте.

Гугл нанимает большое количество тупых студентов, только-только после вуза или ПТУ, и заставлять их писать хоть какой-то простой код. И делать минимум ошибок, при этом. Для этого Go сделан таким тупым и упрощенным. И выкинут в паблик он только для того, чтобы вероятность, что у такого студента, только пришедшего в гугл, было хоть какое-то знание Go, была выше нуля.

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

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

Тут возникает вопрос - а почему этому тимлиду не дать в руки кодогенератор, вместо всей этой accidental complexity, возникающей из-за огромного количества строк кода, и из-за затрат на коммуникацию?

А тут надо понимать, как внутри устроены огромные корпорации типа гугла.

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

Естественно, это все отражается на качестве продуктов, и это видно как по полному прекращению инноваций в гугле, так и по постоянно мелькающим и закрывающимся высерам этой компании - hangouts, duo, google plus, google wave, и прочее и прочее, можете еще вспомнить много чего.

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

Никакой мифической простоты в отладке и в понимании кода Go не приносит. Да и сложность программных систем растет совершенно не из-за понятности/непонятности какой-то отдельной взятой строчки кода или функции. Потому, что, во-первых, понятность это понятие субъективное, во-вторых потому, что, отдельно взятая фунцкия на 5 строк понятна любому опытному программисту, будь она написана хоть на Rust, хоть на Common Lisp.

Сложность программных систем возникает из-за их размера. И Go эту проблему значительно ухудшает. Человек не может удерживать в голове слишком много вещей, даже если каждая отдельная вещь - очень простая. Количество RAM в голове ограничено.

В случае если вы не хотите выкидывать кучу денег просто так, и скорее предпочли бы нанять немного, но более-менее опытных программистов, Go будет только вреден, потому что все вменяемые люди от него, на самом деле, плюются. Он реально отталкивает опытных людей, которые способны понять сложные требования и написать, и поддерживать, более-менее сложные системы уровнем хотя бы нескольких сервисов плюс БД и MQ.

Вобщем, я тут в своей библиотеке для интероперабельности Common Lisp и .NET - запилил мега-фичу - прокси-классы.

Это такие классы, лисповые, которые с помощью магии метаобъектного протокола CLOS и немного System.Reflection.Emit - прикидываются .NET классами, а их объекты, соответственно - .NET объектами.

Это позволяет бесшовно интегрироваться с .NET кодом, например реализовывать .NET интерфейсы или вон, идиоматически писать на WPF, с MVVM, биндингами, командами и всем прочим.

Вон пример приложения, это браузер пакетов(лисповых неймспейсов) CL: https://files.catbox.moe/77wdbn.png

https://github.com/Lovesan/bike/blob/master/examples/wpf.lisp (потом как-нибудь еще добавлю пример с Avalonia, чтобы было кроссплатформенно вообще).

Вот соответствующий XAML. Как видно, вьюха напрямую биндится к свойствам вью-моделей, как будто у нее под капотом C#. https://github.com/Lovesan/bike/blob/master/examples/WpfUserControl.xaml

Код в принципе там понятен, особенно тем кто имел дело с WPF/Avalonia. Но документацию надо бы написать, да, работаю над этим. Докстринги это хорошо но мало.

После пары лет наконец выпустил новый релиз своей библиотеки для интероперабельности Common Lisp и .NET

https://github.com/Lovesan/bike/tree/0.13.0

Там есть серьезная issue, касающаяся линукса, с которой вообще нужна была бы помощь. Что-то опять с сигналами не так, на этот раз с SIGFPE.

https://github.com/Lovesan/bike/issues/10

Если для Ъ - после загрузки рантаймов последних версий .NET в лисп(тестировал на SBCL и CCL), лисповый процесс грохается с SIGFPE.

Выглядит это обычно примерно так:

CORRUPTION WARNING in SBCL pid 151 tid 163:
Received signal 8 @ 7f00cbeb2c3b in non-lisp tid 163, resignaling to a lisp thread.
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
Floating point exception (core dumped)

Началось такое с релиза .NET 6 и продолжается до сих пор. Т.е. .NET 5 работает, и .Net Core до него работали тоже.

Проблемы с сигналами на линуксе уже раньше были(так и хочется сказать - потому что сигналы это кривое говно by design), но мы с одним из разработчиков SBCL их закостылили - переписываем дотнетовские сигналы лисповыми, кроме тех которые дотнет нормально обрабатывает.

Для SBCL и в этот раз есть костыль, правда, кривой. Вырубить отлов исключений операций с плавающей точкой. Но тогда, вместо вызова исключений, в случае операций по типу (/ 1.0 0.0) будут возвращаться значения типа +inf, -inf, и всякие там NaN. Что вобщем-то не по стандарту CL и вообще криво.

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