Здравствуйте, Sm0ke, Вы писали:

S>Я действительно хочу учавствовать в разработке нового ЯП!

Тогда давай начнёшь с определения целей.

1. Общая направленность — системный, прикладной на какой-то класс задач.
2. Процедурный, функциональный, что-то посредине.
3. Управление памятью: ручное (как в C, C++), автоматическое полностью (как в Java, C#), на владении ссылками (Rust), смешанное.
4. Уровень фиксации типизации — статическая, динамическая.
5. Уровень жёсткости типизации. Например, насколько разрешён integral promotion и по каким правилам.

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

S>Си++ хорош, но слишком переусложнён. Его стандартники делают с ним, то что хотят они — и это не всегда чего хотим мы.
S>Когда методы определяются внутри самого класса, то класс постепенно разрастается и превращается в монстра великана.
S>Мне кажется более наглядным, когда в программе данные определяются отдельно от действий над ними.

Для большинства это менее наглядно, но пусть. Что-то похожее есть в Rust с его impl-ами для типа. Смотрел это? Какие впечатления?

S>Я предлагаю создать свой язык вместе. У меня есть идеи, чтобы их обсудить.
S>Фичи языка:
S>*- Ячейка — это может быть: локальная переменная, параметр функции, свойство модуля, и т.д.

Смущает термин "ячейка", но пусть.

S>*- Возможность работать с типом, как со значением. Тип такой ячейки будет $type
S>*- Имена системных типов начинаются к примеру с символа $ (но это можно указать в конфиге, как и другие начальные символы).

Неееет!!!! Это однозначный путь к бардаку. Хватит нам и споров snake_case/CamelCase/mixedCase. Ты представляешь себе, что будет, если ты будешь подключать файл из одного такого режима к проекту с другим режимом?
Разрабатывая язык, сразу рассчитывай на то, что на нём будут писать что-то на миллион строк и половина авторов будут условными индусами, которым похер на всё, кроме зарплаты.
Подобные элементы синтаксиса обязаны быть жёсткими и безальтернативными!

S>Таким образом добавление системных типов не будет конфликтовать с уже написанным пользовательским кодом.

Для такого давно придумали пространства имён. Но редкие конфликты с автоматической переделкой — не проблема.

S>*- Императивный кусок кода помещается в фигурные скобки и имеет тип $seq (sequence).

Тогда надо сразу сказать, что будет в неимперативных кусках.

S>* По сути sequence — это как лямбда без параметров.

Только с автозахватом из внешнего контекста? Уточни.

S>Символ восклицательный знак после ячейки с функцией — применить её к последующему выражению (просто чтобы не писать круглые скобки if_first([])).

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

S>if_first — выполняет sequence каждого условия до тех пор, пока не встретит первое правдивое, и тогда выполнит sequence действие из значения пары.
S>if_each — будет проверять все условия, даже после того как встретит правдивое.

S>Такая штука ведь нагляднее, чем городить огород из if else if else ?

Да. Но сравнимо с тем, если будет явное elif.

S>Функцию вывода на консоль или в файл можно сделать чтобы она принимала sequence. Так она итератором будет вычислять элементы $seq — выражения, и выводить их результат, пока не они не закончатся, или не возникнет ощибка вывода / исключение, при которой оставшиеся выражения не будут вычислены.

Пока что вижу закос под пачку современных языков — что-то среднее между Zig и Ruby.

S>Запятая — разделитель опциональный.

Вместо LF или вообще? Надо уточнить.

S>coords = #struct ( x y )

Я бы делал, что есть набор слов, которые по умолчанию опознаются как ключевые (например if, while, func), а если нужно их сделать идентификаторами, то поставить, например, $ впереди.

S>Ячейка результата вызова функции #ret

По-моему, этот подход в основном признан менее удачным, чем явное return как оператор.

S>Ведь структуры передаются по указателю, как и прочие значения системной категории _compound

Это плохо. Например, математики тебя побьют. struct complex { float real, imag; } — во многих ABI передаётся в двух регистрах. Это эффективно. А ты предлагаешь откатиться обратно.

S>Все категории типов (значение $cat) произрастают из базовой _any, включённой во все типы по-умолчанию.
S>Категория — это просто категория, она не хранит в себе данных. Каждый тип может принадлежать своему набору категорий.
S>В программе можно проверить их принадлежность. Это может быть полезно при динамической типизации.

Интерфейсы или типажи (traits)? Есть причина вводить новое слово для того же?

S>Категории можно использовать как обычные значения в программе, их сравнивать, использовать как ключ в $map.
S>Ведь тип $cat пренадлежит категории _map_key

Вообще обычно говорят более математически — hashable или linearly orderable.

S>Собственно нужны ли категории и шаблоны в языке — под вопросом.

Нужны. Только продумать надо.

Итого
У тебя нет killer feature. Без неё это не выйдет за пределы одного условного диссера.