LINUX.ORG.RU

среда для clojure: emacs или vscode?

 , ,


0

3

Недавно пришлось настраивать среду разработки для окамля. Плагины для vscode оказались пшиком, емакс помог. Какова ситуация с clojure? Среды от jetbrains почему-то не вызывают восторга, но можно тоже рассмотреть.

Контекст: я более-менее свободно работаю в Common Lisp в slime в emacs, хотя последние годы это было крайне редко (на лиспе стал писать в своей оболочке «Яр»). В остальном мой любимый редактор - это VSCode. Скорее всего, если буду играть в clojure, там же будет и что-то другое, связанное с java, js, clojurescript. Т.е. всеядность среды тоже имеет значение. В Емакс я только с лиспом действительно много работал, к остальному не знаю даже, как подступиться.

★★★★★

CIDER есть, многих устраивает.

Для OCaml видимо без разницы. В любом редакторе используется merlin.

Статистика использования редакторов Clojure: https://clojure.org/images/content/news/2020-02-20/deps.png

Artamudo ★★ ()
Последнее исправление: Artamudo (всего исправлений: 2)
Ответ на: комментарий от Artamudo

Ну не знаю, я не смог завести в vscode, хотя приложил определённые усилия. Сложилось ощущение, что люди сделали прототип и бросили его. Это было где-то год назад, может, с тех пор что-нибудь поменялось. А в емаксе (tuareg и merlin) всё по инструкции встало совсем быстро, правда, я там сделал ошибку, что стал пытаться перейти к определению из директории build. Может из-за этого и vscode у меня не сработал…

den73 ★★★★★ ()
Ответ на: комментарий от den73

Заодно, чтобы уж два раза не вставать, насколько велика востребованность специалистов? У меня с работой вроде бы всё норм, но что-то я уж совсем заскучал-загрустил. Работаю чем-то средним между архитектором и менеджером в довольно экзотической области, практически не кодирую (да и не хочется писать на C++, Яве или Окамле). Скорее всего, это просто возраст, но понятно, что после лиспа человек всегда чувствует себя инвалидом, переходя на другие языки. Вот и хочется выяснить.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Заодно, чтобы уж два раза не вставать, насколько велика востребованность специалистов?

Небольшая конечно. Зато Clojure на Западе самый высокооплачиваемый язык:

https://insights.stackoverflow.com/survey/2019#technology-_-what-languages-are-associated-with-the-highest-salaries-worldwide

EXL ★★★★★ ()
Ответ на: комментарий от kookoo

Да не хочу говорить, а то я ведь одиозная личность и фрик, опозорю контору. Вакансии на hh по clojure есть, правда, меня ни на одно собеседование почему-то не пригласили, опыт CL не подошёл им.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от EXL

Это было ожидаемо, вот и придётся, похоже, потренироваться. А может быть лень станет. Ну ещё теоретически можно попробовать на работе внедрить.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от kookoo

Ага, только работу на ней хрен найдёшь

Сложилось впечатление, что вакансий по clojure раз в 30 больше, чем для Common Lisp. В основном веб и интерпрайз в java-экосистеме, но и другие варианты.

alienclaster ★★★ ()
Ответ на: комментарий от alienclaster

Согласен, что во много раз больше, насчёт 30 не уверен. Большинство CL-ных вакансий доступны только в Европе или США, для удалёнки из России они вряд ли вообще сработают. А по Clojure обычно есть в Москве 1-2 штуки.

den73 ★★★★★ ()

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

zarkone ★★ ()
Ответ на: комментарий от alienclaster

Сложилось впечатление, что вакансий по clojure раз в 30 больше, чем для Common Lisp. В основном веб и интерпрайз в java-экосистеме, но и другие варианты

Да, потому что Clojure — это такой язык скриптования встроенной базы данных для жавы. Отсюда и такие средние зряплаты. Как лисп оно совсем никому не интересно. Меня больше всего удивляет то, что находятся фанаты ClojureScript, которое в мире JS вообще ни к селу ни к городу, потому в мире JS нет спроса на многопоточную логику, а в остальном CS — это достаточно тонкая и ненужная надстройка над базовым языком. Если бы это был какой-нить ML (привет F#), то без скобочек это было бы менее и более востребовано. Но, как грица, дареному коню в зубы не смотрят.

byko3y ★★ ()
Ответ на: комментарий от commagray

При чём тут мёртвый Mercurial?

Не более мертвый, чем SVN или Perforce. То, что школьники выбирают Git в роли централизированного репозитория, то есть, не имея ни малейшего понятия почему это делают — еще не значит, что все остальные VCS не нужны.

byko3y ★★ ()
Ответ на: комментарий от byko3y

Как лисп оно совсем никому не интересно.

Очень сильное утверждение.

Да, потому что Clojure — это такой язык скриптования встроенной базы данных для жавы. Отсюда и такие средние зряплаты.

Это вполне себе лисп, и смысл он имеет именно как лисп. А зп там выше, чем для джавы обычно - странновато просто как для «скриптования».

alienclaster ★★★ ()
Ответ на: комментарий от alienclaster

Да, потому что Clojure — это такой язык скриптования встроенной базы данных для жавы. Отсюда и такие средние зряплаты.

Это вполне себе лисп, и смысл он имеет именно как лисп

Допустим, я переписал фичи Clojure на диалекте ML:

https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/records#cod...

Что я потерял из лиспа? Напоминаю, что сами разрабы Clojure не поощрают применение макросов: макросы у них существуют только во время компиляции, и потому имеют значительные ограничения по сравнению с обычными функциями.

А зп там выше, чем для джавы обычно - странновато просто как для «скриптования»

И у руби выше, и у F# выше. Потому что предложение меньше и ответственности больше. Есть большая размница между говномикросервисом на питоне и какими-то финансами на F#.

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

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

anonymous ()
Ответ на: комментарий от byko3y

Что я потерял из лиспа? Напоминаю, что сами разрабы Clojure не поощрают применение макросов

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

макросы у них существуют только во время компиляции

На то они и макросы.

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

Вообще ортогональные инструменты.

alienclaster ★★★ ()
Ответ на: комментарий от byko3y

И у руби выше, и у F# выше. Потому что предложение меньше и ответственности больше. Есть большая размница между говномикросервисом на питоне и какими-то финансами на F#.

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

Да, потому что Clojure — это такой язык скриптования встроенной базы данных для жавы. Отсюда и такие средние зряплаты.

Почему столько не платят за скриптование на jruby, groovy итд?

alienclaster ★★★ ()
Ответ на: комментарий от anonymous

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

Во-о-от, и ты тоже не знаешь, какие преимущества у SVN над Git есть.

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

20$ за человека в год — это не «ультра-дорогое авто».

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

пока они не перешли на еще более умер-мега-херовину собственной разработки (и которая недоступна никому извне компании).

anonymous ()
Ответ на: комментарий от alienclaster

Выбросил из лиспа макросы - получил питон

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

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

И чо? А в Си используются указатели — и что? Я могу сделать только один вывод — макросы лиспа не нужны (вне лиспа).

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

Вообще ортогональные инструменты

А я спорю? Они независимы, потому в своей программе на лиспе ты описываешь два мира — мир компиляции и мир выполнения. Пока здоровый человек на ML, или на худой конец хаскеля, имеет единый мир логики программы.

byko3y ★★ ()
Ответ на: комментарий от byko3y

ClojureScript, которое в мире JS вообще ни к селу ни к городу, потому в мире JS нет спроса на многопоточную логику

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

Nervous ★★★★ ()
Ответ на: комментарий от byko3y

два мира — мир компиляции и мир выполнения.

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

Пока здоровый человек на ML, или на худой конец хаскеля, имеет единый мир логики программы.

А когда твоей программе нужно сгенерировать другую программу, начинаются манипуляции со строками? Не в курсе, как это делается в этих ваших хаскелях %)

Nervous ★★★★ ()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от alienclaster

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

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

Да, потому что Clojure — это такой язык скриптования встроенной базы данных для жавы. Отсюда и такие средние зряплаты

Почему столько не платят за скриптование на jruby, groovy итд?

А где по ним статистика? Та же Scala намного выше жавы находится.

byko3y ★★ ()
Ответ на: комментарий от byko3y

Выбросил из лиспа макросы - получил питон

Либо ты не знаком с питоном, либо сильно преувеличиваешь.

Если убрать из лиспа макросы - какие у него останутся преимущества перед условным питоном или джаваскриптом? Если что, потенциально даже репл можно прикрутить в эти языки. Все остальные фичи лиспа - это сугубо про реализацию (компиляторы, clos, mop, разработка в образе и прочий рантайм).

И чо?

А то, что ты ты писал:

Что я потерял из лиспа? Напоминаю, что сами разрабы Clojure не поощрают применение макросов

Если ты используешь ML - значит у тебя нет макросов (или нормальных макросов). К чему пассаж про не поощряют?

А в Си используются указатели — и что? Я могу сделать только один вывод — макросы лиспа не нужны (вне лиспа).

Странное утверждение. Макросы просто нужны и все, желательно такие, чтобы удобно было генерировать хостовой язык. А лисп-нелисп это уже дело стопятидесятое. Лисп интересен именно по совокупности «фич», основные из которых - макросы, repl и ... <подставь что-нибудь сам по вкусу>.

А я спорю? Они независимы, потому в своей программе на лиспе ты описываешь два мира — мир компиляции и мир выполнения. Пока здоровый человек на ML, или на худой конец хаскеля, имеет единый мир логики программы.

В лиспе тоже есть этот «единый мир» + дополнительный. Какие у тебя претензии к макросам?

alienclaster ★★★ ()
Ответ на: комментарий от anonymous

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

Perforce не умел в облако/распределенное хранилище. Это единственная причина, почему гугл решил перейти от перфорса к Piper. Ни одна DVCS (git, hg, bazaar, bitkeeper) не потянет даже сотой доли объема репозитория гугла. MS попыталась использовать Git для репы Windows на 300 Гб, но быстро передумала, когда выяснилось, что «git status» выполняется 8 минут, а «git checkout» — 3 часа.

Piper не доступен никому за пределами гугла, потому что ни у кого больше нет такого объема внутреннего кода в одной репе (миллиарды строк плюс нетекстовые данные).

byko3y ★★ ()
Ответ на: комментарий от byko3y

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

Проблема питона в том, что это фундаментально ненадежный инструмент.

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

Почему столько не платят за скриптование на jruby, groovy итд?

А где по ним статистика?

Там же? Или рынок для них столь незначительный, что они в нее не попали. А кложа попала, внезапно. Несмотря на инопланетный синтаксис, лишп и появление на 20 лет позже руби. И даже позже groovy, который никому особо не нужен. Совпадение? Не... Нет.

Та же Scala намного выше жавы находится.

Scala - скриптовый язык? Сформулируй какую-то мысль тезисно, а то непонятно, к чему тут «скриптовость» кложи.

alienclaster ★★★ ()
Ответ на: комментарий от Nervous

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

Да. Вся clojure построена на многоверсионных типах данных, STM, атомах, агентах. Если выкинуть эти вещи из языка — в нем остается что? Беспонтовая обертка над жавой.

byko3y ★★ ()
Ответ на: комментарий от Nervous

два мира — мир компиляции и мир выполнения.

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

Я тебе поясню, что и почему случилось. Разраб сначала запилил лисп на JVM по образу и подобию Common Lisp, то есть, макросы были во время компиляции и во время выполнения, можно было во время выполнения генерировать лисповые структуры и тут же выполнять их. То есть, что-то среднее между компилируемыми и интерпретируемыми языками.

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

Возникла необходимость выполнять оптимизации более агрессивно. Решение было довольно логичным — выкинуть самые медленные фичи из времени выполнения. А самые медленные фичи — это кодогенерация с макросами. Макросы стали доступны только во время выполнения, при этом простые функции доступны и во время компиляции, и во время выполнения.

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

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

Вот конкретно в хаскелях это делается очень удобно, потому что язык изначально проектировался для написания компиляторов на нем. Другое дело, что в «другой программы» должна быть какая-то форма представления. И скорее всего форма будет такая, что ее не получится выполнить в том же хаскеле, в котором программа сгенерирована. Хотя можно сгенерировать и «интерпретируемую» форму. Собственно, примерно как и делают компиляторы Common Lisp, только неявно и безальтернативно.

byko3y ★★ ()
Ответ на: комментарий от alienclaster

Если убрать из лиспа макросы - какие у него останутся преимущества перед условным питоном или джаваскриптом

Ты сравниваешь теплое с мягким. Они тупо разные, они не лучше и не хуже друг друга. Типа: чем язык Си хуже XML?. На чем лучше писать вебсайт: на фотошопе или на Visual Studio?

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

Что я потерял из лиспа? Напоминаю, что сами разрабы Clojure не поощрают применение макросов

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

Макрос — это специфичная конструкция языка Лисп. Если я не пишу на лиспе, то я не использую специфичных конструкций лиспа. Это, однако, не значит, что писать мне станет тяжелее. Например, я считаю, что макросы в Си не нужны совсем вообще, их роль можно переложить на константы, безтиповые функции, и импорты модулей, покрыв таким образом 99% всех применений макросов, а оставшийся 1% уж как-нибудь можно будет переписать.

Почему я должен считать, что потеря макросов лиспа станет для меня потерей? Почему вообще в ML или хаскеле нет макросов — ты не задумывался? Подсказка: макросы убили Common Lisp.

В лиспе тоже есть этот «единый мир» + дополнительный. Какие у тебя претензии к макросам?

В «лиспе» — может быть. Но не в Clojure.

byko3y ★★ ()
Ответ на: комментарий от byko3y

Макрос — это специфичная конструкция языка Лисп

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

Почему я должен считать, что потеря макросов лиспа станет для меня потерей?

Не всем не нужны макросы.

Nervous ★★★★ ()
Ответ на: комментарий от alienclaster

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

На F# можно писать ответственный код, на питоне — нет. Вот тебе и вся аргументация по зарплате. То, что можно сидя в туалете с ноутом ковырять данные наспех склепанным скриптом на питоне, еще не значит, что данный человек стал «программистом на Python». Он прежде всего Data Scientist, а где-то сбоку, в дополнение к этому, он умеет в питон... и еще в десяток языков, примерно на том же уровне (джуниора).

Там же? Или рынок для них столь незначительный, что они в нее не попали

Нет там данных по jruby и groovy. Даже по котлину есть, а по груви нету. И паскалей нету, прикинь?

Сформулируй какую-то мысль тезисно, а то непонятно, к чему тут «скриптовость» кложи

Ну типа в СУБД обычно на стороне сервера выполняемая шняга зовется скриптами. Вот я и назвал скриптами. Хотя Clojure — это компилируемый язык, и клиент-сервера у нее нету, потому что клиент и сервер являются единой программой. Такие СУБД-приложения были очень популярны на микрокомпьютерах в 80-90-х годах, и зачастую языки программирования у них были именно интерпретируемыми. Этот формат забывают — а зря.

byko3y ★★ ()
Ответ на: комментарий от Nervous

Например, запиливания в язык нового синтаксиса, не ожидая милостей от разработчиков языка

В C++ есть перегрузка операторов и метапрограммирование на шаблонах — макросы не нужны?

Почему я должен считать, что потеря макросов лиспа станет для меня потерей?

Не всем не нужны макросы

Где-то у меня была ссылка на вопрос в stackoverflow вроде «покажите практический пример, где макросы clojure были бы полезны?». Что характерно, никто не показал.

byko3y ★★ ()
Ответ на: комментарий от Nervous

покажите практический пример, где макросы clojure были бы полезны

Очевидный defчто-то очевиден

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

byko3y ★★ ()