Stodin DSL. Тема 5. Графический редактор (пиксель-арт).

Меня это не развлекло. Уходи.

Выглядит интересно.

Я правильно понял, что язык появился как средство борьбы с излишней многословностью C++?

Вероятно, да. У меня когда-то был проект на микрокомпьютере с uCLinux. Прототип проекта был на Питоне, а затем я его переписывал C++. В процессе переписывания стало ясно, что для моей задачи не нужна была ни гибкость динамической типизации Питона, ни низкоуровневость C++. И таких прикладных задач много. Вот я и выделил некоторое примитивное, но достаточное подмножество.

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

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

А, ну тогда ладно, пойту стодин дсл накачу.

У Нима подход такой: внесём в язык все парадигмы, которые знаем. У Стодина подход: выкинем всё что можно и ещё немного того, что нельзя.

Как иллюстрация этого возьмём управление памятью. У Нима несколько сборщиков мусора и возможность ручной сборки. У Стодина нет сборщика мусора, нет ручной сборки, нет сложной move-семантики. Но при этом данные в куче можно динамически выделять и перемещать между процедурами без использования глобальных переменных. Возможно, тут будут какие-то ограничения. Их я и прощупываю проектами, типа этого редактора.

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

А в качестве хобби интереснее своё делать.

Вот это, кстати, проклятие опенсорса (но одновременно и его движущая сила).

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

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

Кстати, я посмотрел исходник, def — это определение функции? Или это как-то по-другому называется?

И если я правильно понял, синтаксис зависит от отступов, это то, за что я очень не люблю Питон (надёжность хромает).

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

Кстати, я посмотрел исходник, def — это определение функции?

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

синтаксис зависит от отступов,

Да. У меня скобок нет совсем. Никаких. Ни фигурных, ни круглых, ни квадратных, ни треугольных.

это то, за что я очень не люблю Питон (надёжность хромает)

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

В принципе, ничего не мешает сделать вариант, где блоки кода выделяются скобками. Просто мне этого не надо. Я наоборот всё время запинаюсь о скобки. Тем более, что у меня сохранилась привычка от старых редакторов сразу ставить две скобки, а потом возвращаться для ввода содержимого. Современные редакторы сопротивляются такому поведению и автоматически то добавляют скобку, то удаляют. Приходится каждый раз искать, как подправить это автодополнение.

Зачем, если есть aseprite?

aseprite - интересный проект, хоть и коммерческий. Понятно, что он более продвинутый. Моя цель была не в создании редактора, а в испытании языка программирования, в создании зачатков GUI библиотеки. Пока что GUI появилось, а библиотека - нет. Но она, вероятно, не может появиться без ООП с полиморфизмом.

С другой стороны, я каждый день что-то рисую карандашом. Пытаюсь перейти на цвет. С красками возиться неохота, цветные карандаши имеют тусклый цвет, а у фломастеров проблема с количеством получаемых оттенков. Как вариант - такой редактор. Тем более, с разрешением 80x80 картинка много времени не занимает.

Ну и третье. Я предполагаю, что это будет ступенью к редактору простейшей анимации. Тоже сделать небольшое разрешение, например, 160x90 квадратов. Это уже будет серьёзное испытание для ЯП, после которого я буду уверен в жизнеспособности технологии.

цветные карандаши имеют тусклый цвет

Это совершенно надуманная проблема. Графитовым карандашам тоже далеко до угля по глубине чёрного. Но конечно, всё ещё очень сильно зависит как от самих карандашей, так и от бумаги. Возьми нормальные. Сейчас даже на Алике за копейки продают достойные карандаши.

И ты на Ютубе-то посмотри что народ «карандашиками» вытворяет.

метапрог пиксельартовский?

Смысл в том, что я вначале писал свои проекты на Паскале, потом переписывал на Дельфи и ActionScript, потом на C++, Питоне, C#… И не потому что я такой любитель поизучать что-то новое, а потому что индустрия решила, что больше не будет поддерживать определённые технологии.

перепиши на Ada. такой приятный паскаль, с pragma C import и прочими ништяками.

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

или вот про Аду, компилятор GNAT:

1. собираем через gnat : gcc -c -fdump-spec-ada … *.c

2. получаем автогенерированные привязки к си (с теми самыми pragma(C,import,…)

3. про C++ привязки не сильно сложнее, но сам ABI более хрупкий.

=> получаем

пакетный менеджер Alire

например, как установить про Alire

сам язык очень приятный. код легко читается как песня.

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

ну в целом по индустрии понятно что никто не почешется переписывать всё на очередной новомодный язык только потому что он тут появился, инфа 100%.

почему не взлетели те же лисп-машины, или смоллток-машины, или оберон/активный оберон? примерно поэтому.

уже есть код на си, который работает. и трогать его боятся. переписывать его на каком-то компонент паскале особого смысла нет. поэтому например, в той же A2 появляется PROCEDURE{C} в активном обероне, а в Аде – pragma(C,import,…)

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

другое дело, про автоматическую генерацию привязок к тому же легаси си коду.

добавляем например один ключик -fdumpspec-ada и получаем привязки на аде + собранный сишный код.

и возможность структурировать по package, параметрическим типам и т.п. как угодно.

плюс достаточно выскоуровнево структурировать – в смысле task/entry, SPARK, etc.

опять же, кодогенератор использовать общий с обычным gcc (или llvm-gcc)

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

прикольный проект.

А чем это лучше Aseprite?

Почитал комментарии, свой вопрос снимаю.