Rodegast
Я не понял зачем ты этот язык делаешь и во что ты хочешь его компилировать

Levitanus
для самообразования

Начинать надо с планирования.
wiki. модель водопада
wiki. scrum

Чтобы планировать, нужно изучить UML. Там всё сначала рисуешь, а потом уже нарисованное реализуешь.

Также нужен трекер, для постановки и отслеживания задач и багов.
wiki. трекеры

Также нужна система контроля версий.
wiki. git

Вот когда у тебя это всё будет налажено, можешь приступать к разработке. Сложную систему без всего этого не реализуешь.

py.user.next
Начинать надо с планирования.

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

py.user.next
Также нужна система контроля версий.

на странице содержания ссылка на github

py.user.next
Также нужен трекер

https://dmitryivanov.net/

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

Я так понимаю, и так, и так не есть гуд. Может что-то упускаю?

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

Ну это поначалу только. Ты знаешь, что такое метод разработки “сверху вниз”? Тут писал пример.
То есть сначала нужно написать все абстракции, сделать для них заглушки, а когда они работают правильно, тогда и переходить к замене заглушек на настоящие реализации функций. При реализации заглушек с ними делается всё то же самое: пишутся абстракции, делаются заглушки, проводится тестирование работы до правильного выполнения, идёт переход к реализации заглушек.
Прикидки кодом ты можешь делать, но это не должно управлять разработкой проекта.

Levitanus
Тем более, что по существу, половину архитектуры кодом реализовать, фактически то же, что и в UML расписать.

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

Levitanus
Ну и, если говорить про рисование - у меня уже пачка листов разрисована

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

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

py.user.next
те знают, что каши там и близко быть не должно.

Levitanus
Я так понимаю, и так, и так не есть гуд. Может что-то упускаю?

Я тут согласен про кашу. Вы тут про детали спрашиваете, а мы тут даже близко не понимаем что вы хотите сделать. Что мы можем посоветовать?

Наш диалог примерно так выглядит-

Вы: Мне тут саморезом на 20 мм или на 25 мм прихватить?
Мы: А что вы делаете?
Вы: Кашу манную варю.
Мы: ???!@/ Длинный саморез не берите а то не влезет.

Нужно четкое описание рабочего процесса использования того что вы пишете. До винтиков!
Возьмите паузу Подумайте.

> Начинать надо с планирования.

Начинать надо с определения предметной области т.е. нужно сначала определить для чего этот DSL вообще нужен, определить наиболее оптимальный синтаксис языка и от этого отталкиваться. Всякие UML, SCRUM и прочее нужно для командной разработки, если нет команды то на них можно забить.

> Я так понимаю, и так, и так не есть гуд. Может что-то упускаю?

Вот посмотри видео про DSL может быть и поможет: https://www.youtube.com/watch?v=Qf0TjcBG1oI

Rodegast
Всякие UML, SCRUM и прочее нужно для командной разработки

Для индивидуальной разработки это тоже всё нужно. Если ты пишешь небольшой скрипт, который потом не будет дописываться, этим можно пренебречь (и даже системой контроля версий). Другое дело, если ты пишешь что-нибудь на полгода и больше, где будут версии, архитектура. Да ты просто не вспомнишь всех аспектов программы, если через три года решишь поднять её до следующей версии или просто обнаружится баг, который надо будет исправить (бывает такое, что из-за обнаружившегося бага ты не можешь сделать дело (ты пытаешься что-то сделать и вдруг оказывается, что ты не можешь этого сделать, а почему - а потому что баг какой-то)). У меня просто сборки программ такие сложные, что я в одной сборке и установке программы, которые писал сам, могу разбираться потом целый день, если открываю программу на доработку через год или два. То есть, например, есть тестирование программы, как понять, какие тесты уже написаны, а какие нет? Пока ты пишешь поначалу там что-то, ты это всё помнишь: помнишь код самой программы; помнишь, что ты уже протестировал и что нужно ещё протестировать; помнишь, зачем это делать вообще. Когда же ты отложил программу и у тебя другие программы есть, то при возврате к первой программе ты уже не помнишь ничего, только в общих чертах. Не помнишь, что там тестируется даже и есть ли там вообще тесты какие-нибудь. И вот чтобы не перечитывать её код весь, чтобы не перечитывать все тесты заново (а их там уже дофига), чтобы помнить, что нужно тестировать, у тебя должен быть покрывальщик тестов подключен. Он ходит по всему коду, компилируется вместе с ним и в результате показывает, какие фрагменты кода покрыты, а какие - нет. Так вот, чтобы подключить покрывальщик тестов к проекту и чтобы его результаты складывались в удобное для программиста место, нужно столько всего написать в сборщике проекта, там такие детективы нужно разгадывать, такие запутанки нужно проделывать, - реально программировать надо, составлять алгоритм сборки, чтобы всё-всё-всё учесть и чтобы ничего не поехало потом. Короче, это DevOps на полную катушку - сисадминство с элементами программирования.

По UML-схемам ты потом вспоминаешь, что сделано и что ты ещё хотел сделать год назад.
А Scrum даёт возможность определять сроки собственной разработки, очерёдность фич. Там же и короткие периоды разработки, и выкатка фич на лету идёт, и сами фичи можно встраивать в процесс не изначально, а внепланово. Ты не можешь с одной, не очень-то нужной фичей сидеть два месяца - жалко времени. Заранее придумать всё ты тоже не можешь, иногда идеи появляются только в процессе разработки и их надо как-то по-быстрому встроить в общий процесс. Почему от модели водопада стали отказываться в мире - потому что модель водопада хороша только для фиксированных проектов, она не позволяет вдруг внезапно в середине разработки взять и добавить кусок функциональности, придуманной только что.

> Короче, это DevOps на полную катушку - сисадминство с элементами программирования

Вот именно! Что бы задействовать всю эту машинерию тебе придётся приложить значительные усилия. С UML-ом та же беда, схемы должны отражать реальную структуру объектов, а значит тебе придётся постоянно тратить усилия на их актуализацию.
Будут ли всё это оправдано при индивидуальной разработки? Не думаю.

Rodegast
Вот именно! Что бы задействовать всю эту машинерию тебе придётся приложить значительные усилия.

Не, настройка только занимает время. Задействование потом сводится к простым командам типа “make tests-coverage”. Вот эта штука заготавливает Makefile-файлы и shell-скрипты, затем спускается в нужную директорию и запускает make уже для приготовленных Makefile-файлов. Дальше там снова что-то нужное готовится и для этого всего запускаются приготовленные ранее shell-скрипты. Выглядит всё так, что ты ввёл команду и она пошла собирать; потом собрала и стала выполнять тесты, которые на экран уже пишут результаты. А после всего вывода у тебя есть информация о выполненных тестах и в нужной директории лежит всё покрытие всех исходников этими тестами. При этом в каждом получившемся файле, в его комментарии стоит название проекта, его текущая версия и копирайт с текущей электронной почтой для фидбека. Всё это редактируется в одном месте проекта, поэтому достаточно поменять одну строку в одном файле описания проекта, чтобы при следующей сборке по всем файлам на любых уровнях произошла замена той же электронной почты или даты последней сборки. Имя проекта, которое используется также для регистрации в операционной системе при установке программы, также записано лишь в одном файле описания (абстрагировано до шаблонной строки), поэтому со временем уже есть проекты, чьи настройки можно просто напрямую копировать в новый проект и в них не нужно долго что-то настраивать, только поменять файл описания проекта.

Rodegast
С UML-ом та же беда, схемы должны отражать реальную структуру объектов

Схемы можно дорисовывать, потому что делаются они в программе, которая хранит их в виде xml-файла. Перед добавлением класса просто рисуешь его в программе, а потом уже в код добавляешь. И потом уже коммитишь это всё вместе. Получаются актуальные данные. При этом UML действует, как обычная блок-схема, - проясняет будущий код и не даёт запутаться.

Вот у него (автора топика) проект. Я там на GitHub'е почитал у него, там не то что даже коммиты странные, а просто сам проект выглядит в виде обрывков. То есть он что-то писал упорно, мотивированно, а получилась ерунда в конечном итоге. Нарисовал бы всё заранее в виде схемы - сразу бы увидел, что писать нечего, так как свалка.

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

Выложи шаблоны для этих настроек на github, тогда и можно будет всё это обсуждать.

> Схемы можно дорисовывать … Перед добавлением класса просто рисуешь его в программе, а потом уже в код добавляешь.

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