Почти 11 лет.

Расскажи тогда какое будет управление памятью: ручное или GC или декларативное?

В том же BMP такая структура. Там может быть написано, сколько бит на каждую цветовую компоненту и маски для их извлечения.

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

@r_mustang как там твой конфиг менеджер?

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

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

да, мы знаем, что ты очень гибок

Рабочий прототип этого есть?

нет

Этот троллинг не очень уместен. Между тем что есть на самом деле и попыткой прогнуть - огромная пропасть.

это не троллинг

Это что-то типа Prolog?

Например, можно взять тот самый Image, с 16 битным цветом и второй с 32 бита. Можно скастить первый ко второму и рантайм повысит битность изображения автоматически, основываясь на совпадении имён и логических типов полей (логически что int16, что int32 - это числа).

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

Мне кажется, ему не хватает ЯП от @devoln , чтобы конфиги были быстрыми и динамическими

да, ты прав!

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