Top #6 на hacker news, поздравляю :)

Да, именно в этом и есть мысль. Нужен язык, который был бы лиспом. Т.е. вместо емакс лиспа можно использовать какой-нибудь другой лисп. А Go это ниразу не лисп. Никакой тебе гомоиконности.

Т.е. чтоб выйти в Top #6 на hacker news, надо предложить подобную глупость? Ну ок, буду знать

Настолько Go популярен, да.

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

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

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

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

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

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

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

Не надо говорить за всех. Он пилит в своё удовольствие. Если для emacs появятся более мощные и удобные средства параллелизации я, например, буду рад. А что ты сделал для хипхопа emacs, кроме демотивирующего старческого брюзжания?

Не надо говорить за всех.

А я за всех и не говорю.

Он пилит в своё удовольствие.

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

Cколько уже было таких переписывателей емакса, и чем это все закончилось? Проще написать свой принципиально новый текстовый редактор на базе https://electron.atom.io/ и туда скомпилировать Go через https://github.com/gopherjs/gopherjs

Вот вам и будет, стильно, модно, молодежно.

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

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

Ну я тоже не брошусь писать для emacs на go. Но конкретно в том посте было:

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

А это может принести пользу сообществу. CSP по образу go я бы хотел видеть в emacs, это было бы удобно. Я бы мог и сам этим заняться, но мотивация не настолько сильная - пока хватает запуска долгих задач в фоне с помощью async. Я отдаю себе отчет, что постоянно порождать/убивать новые процессы довольно тяжелой emacs lisp машины неоптимально, но переписывать долго, а работает и так.

Автор дал ссылку на свой реп и он там активно пилит. А ты тут только кричишь «ненужно». Некрасиво.

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

Стоп. Вот давайте разберем по пунктам, что он там понаписывал на хабр https://habrahabr.ru/post/331134/ и что конкретно он пилит. Во-первых автор сначала просто предлагал встроить какой-то там еще язык в Emacs.

Вы когда-нибудь искали альтернативу Emacs Lisp'у? Давайте попробуем добавить в Emacs ещё один язык программирования.

Идея, как по мне, вполне здравая. Смотрим дальше

Предположим, что мы выбрали Go. Как вы будете использовать Go для взаимодействия с редактором?

Почему Go? Автор может ответить на вопрос «почему Go?»? Что в Go такого примечательного? Почему не другой диалект лиспа? Вот кстати ссылка по теме: https://www.emacswiki.org/emacs/WhyDoesElispSuck

Как вы будете использовать Go для взаимодействия с редактором? Ваши варианты:

1. Использовать Emacs модули для запуска Go функций. Вдохновение можно черпать из проекта go-emacs.
2. Найти (или написать) интерпретатор Go, встроить его в Emacs путём патчинга или теми же C модулями, а затем вызывать eval из редактора.
3. Транслировать Go в Emacs Lisp байт-код.

Автор, как вы можете видеть, почему-то выбрал Go(обсуждение того, какой же язык лучше встроить в Емакс, не было), и даже предложил несколько вариантов того, как туда встроить этот самый Go. Ну отлично. И какой же вариант был выбран автором из этих трех пунктов? По-моему третий, если посмотреть на теги https://github.com/Quasilyte/goism — emacs-lisp-bytecode.

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

А ты тут только кричишь «ненужно». Некрасиво.

Если бы автор для начала устроил дискуссию вида «А какой бы вы хотели увидеть язык в емаксе? Чем не устраивает emacs lisp?» то это было бы отлично, и я уверен, что есть намного более подходящие языки для впиливания их в emacs. Но автор, как мы видим, пошел совершенно иным путем.

Автор, как вы можете видеть, почему-то выбрал Go

Автору нравится go, этого достаточно. Судя по реакции сообщества, у него есть единомышленники.

Так вот, я считаю что добавлять Go в elisp путем компилирования Go в elisp байткод — наихудший из предложенных вариантов. И у меня есть обоснования. Но автор меня естественно не будет слушать, он уже начал там что-то пилить свое.

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

«А какой бы вы хотели увидеть язык в емаксе? Чем не устраивает emacs lisp?» то это было бы отлично, и я уверен, что есть намного более подходящие языки для впиливания их в emacs. Но автор, как мы видим, пошел совершенно иным путем.

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

Я с тобой согласен, что go язык для данной цели неподходящий, но не чувствую от этого такой боли, как ты.

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

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

Далее. Если уж Go, то:

1. Одна из фич Go это его компилируемость в натив. Транслируя Go в elisp байткод, мы эту фичу убиваем.
2. Одна из фич Go это возможность легкого взаимодействия с кодом на Си. Компилирование в elisp байткод позволит нормально реализовать эту фичу?
3. Одна из фич Go это многопоточность. Компилирование в elisp байткод позволит нормально реализовать эту фичу?

Ну всё в твоих руках - бери и начинай встраивать другие языки, чего зря языком чесать?

Такие попытки уже вроде как предпринимались, см. например Guile-Emacs

И, как мы можем наблюдать, закончились они НИЧЕМ. И я очень сильно сомневаюсь, что у автора результат будет иной

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

Аналогично.

Одна из фич Go это его компилируемость в натив. Транслируя Go в elisp байткод, мы эту фичу убиваем.

Согласен.

Одна из фич Go это возможность легкого взаимодействия с кодом на Си. Компилирование в elisp байткод позволит нормально реализовать эту фичу?

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

Одна из фич Go это многопоточность. Компилирование в elisp байткод позволит нормально реализовать эту фичу?

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

И, как мы можем наблюдать, закончились они НИЧЕМ.

Ты просто не в теме. В последнем релизе guile vm полностью поддерживает исполнение кода на elisp, хотя пока и не умеет его оптимизировать (т.е. будет работать сильно медленно). Ну и команды guile и emacs активно обсуждают дальнейшие планы в рассылке.

Да, еще важный момент. https://golang.org/pkg/unsafe/ — это с компилированием Go в elisp байткод ну никак не реализовать. Или я неправ?

https://golang.org/pkg/reflect/ с этим думаю тоже будут проблемы

Думаю, что с unsafe и reflect действительно будут проблемы. Но лучше уточнить у quasilyte, так как я, в отличие от него не ковырял go ast, или какое там промежуточное представление преобразуется...

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

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

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

Автор хочет активно вызывать из emacs маленькие функции, написанные на go.

Целью является вызывать Emacs Lisp функции из Go кода без накладных расходов. А ещё некоторые из них инлайнить и вообще рассматривать как интринсики (уже достигнуто).

Go выбрал из-за простоты написания под него прототип за один вечер.

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

Я не изучал этот вопрос достаточно глубоко.

Основные сигнатуры для взаимодействия с reflect: https://golang.org/pkg/reflect/#ValueOf https://golang.org/pkg/reflect/#TypeOf Обе принимают `interface{}`. Тот в свою очередь хранит `(cons type object)`. То есть принципиально `reflect.Value` не обязан быть более магическим, чем `interface{}`, у нас в самом объекте есть всё нужное для реализации методов рефлексии (type содержит всю информацию о типе).

Обратный путь идёт через `reflect.Value#Interface()`, который также возвращает `interface{}`.

Если в runtime уже реализованы интерфейсные типы и type assertions, то я не вижу особых сложностей в пакете `reflect`.

Пакет `unsafe` сложнее, тем более он вообще не вполне обычный пакет в Go. Ещё он неслабо зависит от того, каким именно образом будут эмулироваться указатели внутри Emacs Lisp.

Не «на нём прототипировать», а «его прототипировать». Язык forth в частности из-за простоты реализации многим симпатичен. Лиспы - аналогично, многие берут этот синтаксис просто потому что парсеры писать намного проще.

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

Еще хуже — надеяться на чужую помощь, когда делаешь нечто такое, что почти никому не нужно.

Еще хуже — надеяться на чужую помощь, когда делаешь нечто такое, что почти никому не нужно.

Ответ довольно прост: я на помощь не рассчитываю. Если она будет - отлично. Если нет - не катастрофа.

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

Это на практике делает невозможным эффективную реализацию, например, расширяемых массивов на C с лисповой мордой. На каждый вызов вашего `ext-vector-ref` будет аллокация, из-за чего в разы будет медленнее, чем в случае с нормальной встроенной функцией. Разница в скорости на порядки, что-то близ «в сотни раз». Для конкретных цифр мне нужно будет найти код, который это проверял.

а как это сейчас выглядит в Xemacs? там вроде были нормальные векторы и массивы.

но тот же slice из Go эффективно реализовать будет сложнее. Если очень интересно, могу поделиться, почему.

tl;dr : ты хочешь за собой тянуть половину рантайма Го, про мусорщик, горутины, слайсы и интерфейсы, зачем?

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

Го тут как-то не очень.

или на Nim писать модули к емаксу, там тоже AST макросы есть и GC отстреливаемый. опять же, оно в сишечку компелируется, то есть на ним теоретически понадобятся только хитровыдуманные макросы.

Хороший point, но я всё-таки не так часто именно с AST работаю в Emacs коде.

неявно, ты работаешь именно с ним. ибо функции емакса это и есть S-выражения, AST.

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

идеальный emacs

лично для меня идеальным емаксом был бы какой-то более простой рантайм типа Emact с встроенным ISO ISLISP OpenLisp + допилить раскраску и батарейки.

ценность Elisp сомнительна кроме одного: он уже есть, и под него уже есть 10500 расширений, включая тот же org-mode. вот кстати, пример расширения, где активно гомоиконность, макросы и прочие лисп-штучки используются.

ещё TeXmacs со встроенной Guile интересный в кишках: 1) нормальные модули 2) структурный редактор 3) асинхронность.

они хочут твой моск!!!

атака зомбей емаксовых

автоматизируй это

то, что лиспокод это AST — великая сила на самом деле.

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

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

или управление внешними программами через eepitch

на GoLang без скобочек смерти всё это как-то не очень получится.

e-scripts

tl;dr : “eev is a library that adds support for e-scripts to Emacs”

Язык forth в частности из-за простоты реализации многим симпатичен.

интересная реализация flua, форт на lua.

e-scripts on running flua

the e-scripts I use to upload flua :)

Flua itself - the files whose names start with «demo» are generated

https://github.com/vkazanov/elang

прикольно!

а тесты можно на кукумбере написать, в BDD стиле: ecukes

а если допилить этот питон до Nimrod, то можно будет на нём и модули к емаксу писать (через си через загрузку .so)

вообще на кукумбере более человекопонятнее, чем на елиспе.

и довольно-таки широкий список действий.

пример теста

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

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

говорящая киберутка спешит на помощь!!!111адын адын

неявно, ты работаешь именно с ним. ибо функции емакса это и есть S-выражения, AST.

Что значит «неявно» работаю с AST?

Для меня "(+ x y)" - это само по себе не работа с AST, даже если формат записи - S-expressions.

Контекст был таков:

Слайсы подходят для активного преобразования AST?

Если не трудно, раскроете свою мысль?