cloj
()() metalanguage in Clojure
github: https://github.com/ponyatov/cloj
- generative metaprogramming
- host language: Clojure
- multiple target languages:
- Python | Django
- Erlang/Elixir | Phoenix
- Rust
- embedded C/C++
- deployment platforms:
- VPS / generic Linux
- embedded Linux (Buildroot)
- Cortex-M embedded devices (STM32)
- final programming model:
- bootstrap via system self-application
- distributed object runtime for Web and IoT applications
- language model mixes elements of Smalltalk, Python, Elixir, and Clojure
generic code templating and inheritance
an open set of hypotheses
- most projects share a lot of code
- code can be inherited between projects as constant or parametric code snippets
- coding patterns and algorithms stays more or less the same between multiple
programming languages
- code generation can be used for transforming algorithm defined in a generic form, into multiple target languages
- code patterns can be distilled from some concrete code into a generic form and shared and reused between many projects
- some languages lacks of code checking facilities
- generic code analyzer can improve code quality, and increase the programmer productivity via minimizing debug efforts
- every programming language stack has its own pros and cons
- these features can be migrated to any required language
- by reimplementing them and adding as automated boilerplate code, and/or
- via using of emulating virtual machine (interpreter)
- these features can be migrated to any required language
- such alike generic code manipulation system can be usable in a real contract work
- without implementing anything from the above
- it works even at the level of string interpolation/concatenation and writing of plain text files
- it can be used only in the mode of grossmeister's secret weapon because
the volume of knowledge and understanding which you must transfer to your
colleagues makes it impossible to share
- rich and deep documenting definitely does not help due to the increase of complexity introduced by this documenting
- never ever speak about you use such a system with anybody, especially with your colleagues or employer because it scares them
terms
- code distilling
- reimplementing some feature again and again in the trying to found the most stable code form
- host language
- the programming language in which code transformations are written
- it must be flexible and dynamic as much as possible
- it does not matter how it is memory effective, or fast
- the best variant for the host language is the Lisp dialect even with
its alien's syntax
- I myself fought a lot with recommendations of Lisp for this task, but practice shows it's the truth -- while you are trying to use any other human-friendly host language like Python, finally you are finding yourself in implementing your own Lisp on objects 8)
- The program self-application and self-modification is the must-have property, including first-class macroses, and language orientation especially on the AST-like data structure transformations.
- Clojure is good here because it has multiple parens types, it is more or less known and mature language closer to the mainstream, and it internally works over objects & JVM stack.
- JVM integration lets you use any mature tools from the Java world, targets on compiler design or code analysis, such as ANTLR, Graal, Java-based IDE integration, GUI/visualization, etc. Also, you can directly generate bytecode and run it on JVM as the off-the-shelf runtime.
- the programming language in which code transformations are written
- target language any language in which you generates the code, and next runs the
- backend-compiler (or interpreter)
- mainstream language compiler which builds distribution binary or script package
Clojure
Python
Django
Erlang/Elixir
Phoenix
Rust
embedded C/C++
- Cortex-M (STM32)
- embedded Linux
embedded Linux (Buildroot)
Clojure как noSQL in-memory СУБД
Dmitry Ponyatov, [18.12.20 22:40]
а видел кто-нибудь статьи, рассматривающие кложу или лисп не как язык программирования, а с точки зрения "это такая хитрая in-memory no-SQL СУБД на (само)вычисляемых данных" ?
чтобы ломать у питонистов/жавистов блокировку на принятиё ее как средства разработки
предлагаешь такой использовать, они начинают вопить "что это за инопланетная херня?!"
а ты в ответ: ну вот смотри, ты же не пытаешься на SQL сайты писать, и применять свои ООПшные привычки?
теперь берём noSQL, там тоже нет такого, чтобы из классов мухоморы строить, это тоже такая специфичная среда вещь в себе, возможностей побольше чем в табличных БД, и язык свой специфический
ну вот, и на Лисп/Кложу — тоже смотри как на некий движок БД, только он умеет данные не просто хранить, и делать по ним поиск, но и вычислять новые по старым
ну а чтобы вычислять, нужен какой-то способ определить способ этого вычисления — для этого как раз функции и есть
только это не те функции как в питоне — любая функция это такой же блок данных, только движок БД умеет этот блок выполнять внутри себя, подавать на вход исходные данные, и полученные новые данные хранить
и система заточена на работу с контейнерами данных, как в обычных языках программирования — списки, массивы, скаларяные значения типа числел и строк, и всякие развесистые стуктуры, которые из этого всего можно налепить
ну и определение функции — тоже в этот набор входит, в виде вложенного списка, только движок БД её может выполнять (через интерпретацию)
а поскольку всё это поверх JVM крутится, можно налепить интерфейсы с чем-угодно, не используя больше никакой внешний язык программирования типа Python/Django которые обычно используются для построения интерфейса между СУБД, пользователем, и внешними сервисами
Clojure это своего рода движок БД, причём настолько мощный и расширяемый, что позволяет прямо на нём строить программные системы
ну например, те же MySQL/Postgres имеют средства подключения к другим СУБД в виде external table — и тут также можно делать, только из JVM доступны все её низкоуровневые фичи вплоть до сокетов + можно прицеплять любые Java-библиотеки, вообще любые
мне просто кажется, что если с такой точки зрения рассматривать — у обычного императивного пхпшника не будет срабатывать "ой вай еще один язык учить, да ещё такой шизнутый"
они уже привыкли, что когда начинаешь работать с какой-нибудь странной штукой типа Mongo или GraphQL, приходится её собственный язык осваивать, и это в общем и не сложно — ну да, еще один специфический синтаксис, приходится что-то почитать, может даже в чужом коде покопаться
но при этом не срабатывает рефлекс попыток натягивания совы на Pythonские привычки, и воплей "да тут классов вообще нет! как этим пользоваться вообще можно?"
а с другой стороны — нет соблазна делать на этом вообще всё, как бы у каждого типа СУБДшки есть своя какая-то ниша приложений: кто-то под реляционку и табличныые данные десятилетиями затачивалось, кто-то с деревьями удобно шуршит, в кого-то можно логи терабайтами совать и оно там чего-то себе может посчитать по ним
ну вот у Clojure тоже своя ниша — ворочать сложные многосвязные структуры данных, не слишком большого объема (чтобы в ОЗУ умещались), и одновременно можно на этом изобразить сервер приложений, и запхать туда на Java что угодно если уже готовых встроенных средств не хватило
Telegram posts
https://t.me/LanguageDev/21258
Ilmir:
Разумеется, я не могу говорить за всех - у нас для этого есть @relizarov (но он, похоже, ливнул из чата). Моё мнение - в будущем, непонятно, насколько скором, такие вещи будут доступны любому. К сожалению, один язык может покрыть потребности всех пользователей только если он расширяем. Уже есть подобное в других языках в виде макросов и компиляторных плагинов. Единственное отличие Котлина в таком случае - это малокровная поддержка в ИДЕ. Когда я писал свой компиляторный плагин, после его написания поддержка в ИДЕ, гредле и мавене свелось к примерно 10-20 строк на каждый из плагинов. Разумеется, в случае фейсбучного плагина поддержка в ИДЕ потребовала немного больше усилий.
Dmitry:
Расширяемый язык и IDE?.. Косясь на clojure... не, ну наф наф! Повторить подвиг, и вырастить ещё одного еМакса Франкенштейновича -- это надо хорошо упороться. Хороша кложка к обеду, но не до такой же степени :)
Vladimir Kazanov:
Ну вроде Емакс жил, живет и здравствует; да и clojure тоже. Опять же, visual studio code, который как бы емакс-на-js, тоже в полном порядке.
Чем вас расширяемые редакторы и языки не устраивают?
Dmitry:
Наоборот, только на них и можно толком работать, не вырывая волосы. Но их достоинство одновременно является и недостатком — чуть шаг влево вправо от компьюнити, и всё (библиотеки, расширения) нужно писать самому. По крайней мере, это возможно т.к. система открытая.
Проблема: требуется определённый уровень от программиста, я вот только-только до Лиспа созрел, и то только потому что
- (а) самое главное: придумал как встроить любой странный язык в рабочий процесс, но не тащить его в прод (достаточно только ядра языка без либ и фреймворков)
- (б) сам подолбался со своим языком пока не понял что я похоже всё время пытаюсь переизобрести что-то, но мешает синтаксис и хочется что-то лиспоподобное с прямой работой с АСТ
- (в) обошёл ментальный блок, рассматривая Лисп не как язык, а как такой особый вид нереляционной СУБД для структур данных — с этой т.з. не хочется натягивать привычную сову на новый синтаксис и семантику, имея бэкграунд что каждая СУБД имеет свою узкую область использования, и свой уникальный языковой интерфейс
ЗЫ: прикольная очепятка, не буду исправлять
Dmitry:
(а) компиляторы стремятся строить бимодульно из бэкенда и фронтенда, с языками можно сделать то же самое
- фронт-язык — пишете на чём хотите,
- любые извращения Lisp/Clojure, Haskell, Smalltalk,...
- чем динамичнее тем лучше, причём удобнее без типов,
- в идеале с REPL,
- производительность и потребляемые ресурсы практически не важны
- бэк-компилятор/интерпретатор
- то что вам диктует рынок/работодатель/заказчик/легаси,
- наоборот чем больше проверки кода тем лучше (навороченные типы, линтеры, стат.анализаторы)