что CL имеет смысл

True

и создание новой IDE для него имеет смысл

False, Emacs же есть, зачем что-то ещё?

Ты кто по жизни?

И зачем ты живёшь?

имеет

только 1С смысла не имеет, сорян

Windows уже есть, зачем что-то ещё?

Если предоположить что бессмысленное имеет смысл, то нет смысла спрашиват об осмысленности чего-либо. На вопросы исключающие использование диалектики и логики лучше отвечайте самостоятельно. Тем более что как показывает практика такие вопросы задают персонажи желающие услышать какой-то один ответ не зависимо от объективной реальности и чьего бы то ни было мнения. Получить «правильный» шансов больше отвечая на него самостоятельно, мы же наверняка не знаем что ты хочешь услышать. Да и большинству не очевидно что ты хочешь получить заранее определенный ответ, остальным насрать кто и что там хочет им бы свой словесный понос извергнуть.

Вообще говорят, что Visual Studio Code лучше атома. Там и поддержка Closure есть, https://spin.atomicobject.com/2017/06/22/clojure-development-with-visual-stud... может, стоит присмотреться - может, там есть какие-то киллер-фичи, на которые нужно равняться и которые можно позаимствовать.

100% и имеет. Пилить и UI и бек самому - ты свихнешься от объемов работы. Взять какой-либо опен сорс редактор (атом, лайтейбл) - отличная стратегия для твоей задачи.

Уж лучше Visual Studio Code. Там очень хорошо с архитектурной точки зрения построена работа плагинов.

А в чем именно это проявляется?

Большая часть вещей принудительно вынесена в воркеры, что позволяет не тормозить UI на токенизации и построении автодополнений. Нельзя клепать свой UI (это действительно плюс).
Сам редактор кода достаточно хорош оптимизирован, он как минимум старается не перерисовывать текст выше изменений.

clcon уже давно жизнеспособен, и он тоже на open-source редакторе. Да, кое-чего не хватает. Просто мне нужно упражнение для изучения JS и того, что вокруг него :)

Надо будет посмотреть, спасибо.

Судя по видео, atom-slime умеет делать почти всё, что нужно. Надо допилить отладчик и инспектор. Для Visual Studio Code поддержка лиспа гораздо более слабая (или я просто не нашёл). Т.е. лень говорит за atom-slime. А кто из них менее тормозной?

лень говорит за atom-slime

Ну с таким подходом есть просто emacs.

А кто из них менее тормозной?

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

Но как бы они оба не огонь и до памяти жадные.
Вот тут парень намерял что code медленнее.
https://medium.com/@caspervonb/why-i-still-use-vim-67afd76b4db6

Atom - уг, но tk ещё хуже.

В том же VSCode - TS.

да хоть кложа =)
https://github.com/michey/clj-vsc

В том же VSCode - TS.

JS - подмножество TS.

Разве TS не «компилируется» в JS?

Да, но валидная JS-программа является и валидной TS-программой.

Имеется в виду, что чистый JS является валидным TS кодом => входит в TS как часть, подмножество.

Понял. Я думал у TS другой синтаксис.

Спасибо. Жесть, конечно. Но на самом деле я уже понял, что в OpenSource есть та же проблема, что и в торговле - фиг кому впаришь.

Atom-slime скачан больше 10000 раз, а clcon - не более 200, я думаю. При том, что clcon по фичам приближается к настоящему SLIME, а в чём-то и превосходит. А в Atom-slime нет инспектора и показа стека в отладчике.

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

Насчёт кложи я пока пас - моя задача сейчас выучить JS, не более того.

Найдена проблема лиспа в 21 веке. Это Дениска

Логично было бы писать IDE для CL на CL, а не использовать недоязычки

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

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

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

Что-то слишком уж убог этот JS :( Посмотрю хоть на этот атом, перед тем как принимать окончательное решение. ... Посмотрел ... Это какая-то антиутопия :(

Куда катится мир...

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

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

Напрашивается вопрос: а зачем тогда нужен CL?

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

Данная темя - не для обсуждения нужности CL.

Вряд ли подхватят - ведь atom-slime умер, так и не родившись, аналогичная судьба ранее постигла плагин к Eclispe, а также разные другие проекты. Поэтому, если делать - то для себя и рассчитывая только на себя. Я пока не вижу себя пользователем атома, если честно сказать. И кстати, он не сумел родиться за целых 3 года.

Атом - тормозное УГ на JavaScript.

Tk не тормозит, но страшен как война, ибо дефолтные темы вида «привет из 90-ых», а системные он подхватывать не умеет.

Так что из двух зол выбирают меньшее - лучше оставь tk.

А лучше перепиши на мейнстриме в виде Qt/gtk (если интересует поддержка офтопика, то однозначно Qt, он более кроссплатформенный и не тянет с собой кусок линукса).

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

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

Далее, меня пугает настройка. То, что список последних файлов является пакетом - это страшно. Страшно, что есть пакет для максимизации текущей панели. В редакторах 90-х, написанных на каком-нибудь Turbo Vision, всё это было готово - можно было сразу начинать работать. Основной функционал редактора моего выбора должен быть по умолчанию, он должен быть продуман, согласован, иметь высокое качество, документирован. А тут - какой-то Емакс-Вим, т.е. пока ты начнёшь работать, нужно будет сначала его настроить - так и жизнь пролетит.

Хотя я в целом консерватор и скептик, может это я перебдел.

Qt/gtk не пермиссивно лицензированы, не могу, к сожалению.

А вот JS - это как раз хорошая сторона атома, поскольку он очень популярен, в отличие от tk.

Ладно, при следующем заходе на эту тему посмотрю на vscode.

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

Ну как бы все не от хорошей жизни ищут заменители для js. ClojureScript, ReasonML, OCaml, ScalaJS, PureScript, TypeScript - тысячи их. js больше интересен как платформа для разработки, нежели как язык.

Даже если бы лицензия и подходила, у меня сейчас задача попрактиковаться в JS с пользой для дела, Qt тут не в тему. Мне кажется, что в clcon работа с окнами устроена лучше, чем в атоме, она опирается на оконный менеджер ОС, а не на свой нарисованный. Может быть, это мне так кажется, потому что «своё не пахнет», но пока это так. Так что пока похоже, что переписывание clcon на атом не приведёт к созданию IDE, которую я смог бы использовать вместо clcon. Делать это ради продвижения лиспа я тоже не стану - я уже много пытался делать для продвижения лиспа, никем не был понят, устал и в конце концов понял, что если я не буду продвигать лисп, то не умру и вполне найду чем ещё заняться.

Мне js тоже интересен именно как платформа. Ну и плюс как ремесло.

а ничего так что atom-slime будет весить на порядок больше всего прочего, включая и проекты на 10 лет вперёд ?

В свете остальных проблем это неважно :)

В свете остальных проблем это неважно :)

фига себе у вас там проблемы :-) что затащить и держать в проекте целую инфраструктуру как два пальца об асфальт

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

с другой стороны, вы основной и насколько понимаю единственный автор и пользователь системы. А тут уже куда левая нога пошла :-) Чего советоваться-то.. Желание освоить JS вполне обосновывает всё.

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

А JS можно изучать и на других задачах.

а что за проблемы с вводом кириллицы ?

у нас (tk во все поля, но основная платформа - оффтоп, linux постольку поскольку) проблем с вводом кирилицы не наблюдалось.

собственно отчасти потому и не совсем понимаю причин попыток отказа от tk - всё нужное есть, ничего лишнего нет. И всегда можно достроить :-)

Открыл другую тему. проблемы Tk в офтопике Причина попыток отказа единственная - заброшенность Tk и малость сообщества. Ну и плюс к тому, приложение на Tk из веб-браузера на сегодня никак не запустишь, а на JS - вполне. Я не говорю, что имеет смысл всё запускать из веб-браузера, но это ныне модно :)

А JS можно изучать и на других задачах.

Теоретически можно реализовать CL на JS и всё это внутри среды разработки на базе JS. Человеко-часов уж очень много из-за объёма стандарта CL