А есть ли ЯП, которые умеют обходиться без системы сборки?

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

QBasic ?

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

Если напишешь, то да

Если напишу? Т.е. никто ещё ничего подобного на нём не написал? Как-то подозрительно.

У вас какая-то каша. Никто не заставляет вас использовать системы сборки. А кодогенераторы есть для многих языков.

Что вы сделать хотите?

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

Для питона есть distutils (и setuptools). Но для сборки, например, deb, потребуются внешние зависимости, а там мб будут биндинги, хз не вникал. Ещё есть tox, скорее всего он чисто питонический, но я не ручаюсь, ибо никогда не задавался этим вопросом.

Go собирается с помощью тулзы и компилятора которые написаны на нём же, там же тесты и не только. Это считается?

С большой долей вероятности в npm такое есть и для ноды.

чтобы кодогенератор был не внешней тулзой, а просто либой, причём, в идеале, ещё и стандартной

библиотеку предоставляющие self-hosted систему сборки и тестирования?

именно библиотеку, лучше стандартную, но никак не тулкит

distutils setuptools

нет, судя по названиям, не оно

Go собирается с помощью тулзы и компилятора

опять мимо

Что вы сделать хотите?

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

Насчёт Go - видимо, авторы действительно, сделали шаг в сторону того, о чём я говорю, но здесь пишут, что для чего-то чуть более сложного всё равно требуется какой-то gox

https://habr.com/ru/post/249449/

т.е. без внешней тулзы всё равно не обойтись

Разделение на «тулзу» и «просто либу» в self-hosted языках столь тонко, что этот тред не имеет смысла.

В питоне кодогенерация не нужна, сам язык достаточно динамический, что там можно делать что угодно без внежних тулз. Поэтому аналог hibernate - https://en.wikipedia.org/wiki/SQLAlchemy это просто библиотека.

Racket: https://docs.racket-lang.org/racquel/generation.html

Кодогенерация — зло. Тот же ORM в нормальных языках запихивается в библиотеку.

нет, судя по названиям, не оно

Это библиотеки.

А, так вот о чём он говорил. В жабке ORM надо генерять? Ужас.

Компилятор — это тоже тулза.

Например, на которых можно сделать ORM не отдельной тулзой, как Hibernate в жабке

В каком месте Hibernate это отдельная тулза? Набор библиотек, просто чтоб 10-20 jar'ов не качать в отдельный каталог появились сборщики которые об этом заботятся. Hibernate не требует манипуляций с байткодом в момент компиляции, потому никаких дополнительных плагинов в сборщике для hibernate не нужно.

Само собой, но не внешняя по отношению к языку.

Там почти весь тулчейн запускается как сабкоманды утилиты go, ключая компилятор, то есть тогда и всё остальное не внешнее. Хотя я твою логику разделения вообще не понял.

Все дополнительные шаги сборки ты тоже можешь описать прямо на Go и запустить с go run.

Ну, в общем, да, похоже на то.

Однако в документации к ней пишут, что она сама полностью работать не умеет и ей нужен какой-то RunSnake command line tool https://docs.sqlalchemy.org/en/latest/orm/examples.html

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

Forth, что ли?

Ну это очень похоже, на то, о чём я говорю, вопрос только в том насколько оно мощное.

https://habr.com/ru/post/337158/

Несмотря на солидный возраст, утилита make не теряет актуальности и популярности у тех, кому приходится собирать приложения (хотя бы под *nix). Вот и среди Go-разработчиков этот инструмент весьма распространен.

меня вот это смущает, если там всё так хорошо, то почему от мейкфайлов не спешат отказываться?

Набор библиотек, просто чтоб 10-20 jar'ов не качать в отдельный каталог появились сборщики которые об этом заботятся.

вот! в джавке нельзя это всё сделать просто пользуясь самой джавкой на этапе сборке, нужен мавен или ещё какая фигня

В python'е любой модуль/пакет может быть написан одновременно и как библиотека, и как исполняемая единица (__name__ == '__main__', __main__.py).

RunSnake command line tool

GUI Viewer for Python profiling runs.

О, да, без гуёвого профилировщика ORM работать не умеет.

Да, по части кодогенерации он, похоже, умеет то, что я хочу. А как там живётся без мейкфайлов? Оно умеет отслеживание зависимостей, изменений, вот это вот всё?

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

command line tool
GUI Viewer for Python profiling runs.

там какая-то из черепашек врёт, я не стал разбираться, какая, но автозапуск профилировщика как либы тоже нужен

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

так там тоже код генерится, разве нет? есть БД, её прочитали -> сгенерили классы

Можно конечно. Бери, да указывай все jar'ки ручками. Кто тебе не даёт?

Зачем от них отказываться?

Когда всё собирается исключительно с помощью CI, мне обычно лениво писать мейкфайлы, сценарии сборки кладу просто в ‘build_*.sh’ (по крипту цель: rpm, deb, appimage…), остальное в настройках задачи. Но когда нужна ручная сборка, тем более с возможностью установки не отходя от кассы, то тут в дело вступает Makefile, это мастхев.

так там тоже код генерится, разве нет?

Неее.

есть БД, её прочитали -> сгенерили классы

Это делается или ручками или отдельными тулзами для разработки. К самому ORM это никакого отношения не имеет.

или отдельными тулзами для разработки

с чего и начинали )

К самому ORM это никакого отношения не имеет.

в теории, может и да, только без этого ORM нахрен не впёрся

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

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

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

Rly? А ты пробовал писать без ORM? Посредством самописных ActiveRecrod или MyBatis?

с чего и начинали )

Но это не имеет никакого отношения системам сборки.

в теории, может и да, только без этого ORM нахрен не впёрся

ORM нужен, чтобы из бд сделать тоже самое, только в виде структур твоего любимого яп. Как ты это будешь описывать - дело десятое. Можешь хоть динамически создавать структуры, как на питоне, но это как раз таки нахрен никому не впёрлось яве. Не для того берут языки с СТ, чтобы там кодогенерацию разводить. Для этого есть пистон и жс.

самописных ActiveRecrod

пробовал

MyBatis

пишут: MyBatis provides a code generator... MyBatis Migrations is a Java command line tool that keeps track of database schema changes managing DDL files (known as migrations).

Т.е. без внешних тулз и тут не обходится

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

Ну у тебя и будет не язык, а смесь яп с мавеном, причём конченая. Сколько ты знаешь систем сборки для си/плюсов? А почему их столько развелось? А сколько систем сборки для явы?

Microsoft Visual Studio

упорин

так и есть

Т.е. без внешних тулз и тут не обходится

Что такое «внешние тузлы»? У myBatis код генерится из либы по аннотациям или xml. Это - внешняя тулза?

Но это не имеет никакого отношения системам сборки.

прямое

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

Зачем мне ORM, в котором всё руками надо делать? Руками я и запрос к БД напишу.

Внутри языка (любого) это не может быть удобно. Нужна внешняя тулза. И «удобно» — это как раз про мейкфайл.

Зачем мне ORM, в котором всё руками надо делать? Руками я и запрос к БД напишу.

Чтобы из твоей моделки данных сделать запрос а потом смапить его на объект. И тебе полюбому придётся все кучу всего делать руками. Если ты думаешь, что ORM умеют думать за программиста или можно херак-херак и нагенерить говнокода из по схеме твоей субд, то жестоко разочаруешься. Это работает только для примеров бложеков/магазинов из учебников по этим ORM, где 3 таблицы и 2 связи. В реальности у тебя на первой key-value таблице orm превратиться в тыкву.

Внутри языка (любого) это не может быть удобно

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

И «удобно» — это как раз про мейкфайл.

с одной стороны - просто, читабельно, всё хорошо... но как насчёт того, что на голых мейкфайлах ЯП обычно не живут? обычно вокруг них огород из разных CMake и прочей чертовщины

прямое

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

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

обычно вокруг них огород из разных CMake и прочей чертовщины

Как насчёт того, чтоб куча этой чертовщины не просто так? Кому-то не понравились скрипты, он сделал make. Кто-то сгорел из-за make сделал cmake, и т.д. Теперь представь, что make - это часть языка. Если не устраивает система сборки, то что надо сделать? Изобрести новый язык?

поэтому, внимание, кодогенерация является частью процесса сборки

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

сама полностью работать не умеет и ей нужен какой-то RunSnake

ты поехавший что ли? Откуда у тебя такие проблемы с восприятием?

RunSnake заброшен лет 15 назад бтв

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

Есть вполне реальный js или такой же вполне реальный питон. Берешь и вкорячиваешь туда сборку и подгрузку либ с гитхаба, прямо во время запуска главного скрипта. Впрочем ничего писать не надо, там уже есть pip и npm. Хотя подождите, это же и есть системы сборки.