Непростая тема, надо сказать. Короче, есть идея о новом языке. Постараюсь донести максимально интересно и доступно.
Итак, цель - создать такой язык, который был бы пригоден для
разработчиков. Разработчики - это те люди, которые формализуют неформализованное. Пример разработчиков - программисты (это самый лучший и простой пример разработчиков), конструктора, проектировщики, изобретатели, менеджеры-планировщики и т.д.
1 Общие сведенияДавайте возьмём для примера какой-нибудь язык программирования (псевдо-кодовый) и модифицируем его под "свои нужды". В этом и состоит основная идея нового языка - эксплуатация какого-либо известного языка с добавлением
символов неопределённости.
Символы неопределённости:
- ellipsis, многоточие (...) - это основной символ, который мы будем рассматривать,
- question mark (?),
- можно ещё подумать над символом из регулярных выражений (*) - это возможность для добавления синтаксического сахара,
- в определённых языках разработки могут применяться символы "и т.д.", "etc.", "далее - хз", "и другие" и другие. (Внимание! В этом пункте было немного юмора.)
Теперь очень важно до вас донести понятие
цепочки символов, которое изучается в теории языков [программирования]. Имя переменной, имя функции - это цепочки символов. Например, есть переменная "abcdef". Мы можем добавить символ неопределённости, получим "abc...f", тогда переменные "abcdef", "abcolutf" будут удовлетворять условиям
языка разработки.
Мы можем рассматривать перечисление (enum) как цепочку символов, которая может содержать символ неопределённости.
Было:
Код:
enum class Day {Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday}
Стало:
Код:
enum class Day {Monday, Tuesday, Wednesday, ..., Sunday}
Мы можем взять класс и обрезать его.
Было:
Код:
class Time {
private:
int hours;
int minutes;
int seconds;
public:
Time(int h, int m, int s); // объявляем конструктор
// Объявляем три функции для чтения полей:
int GetHours() const;
int GetMinutes() const;
int GetSeconds() const;
};
Стало:
Код:
class Time {
private:
int hours;
...
int seconds;
public:
Time(int h, int m, int s); // объявляем конструктор
// Объявляем три функции для чтения полей:
int GetHours() const;
int GetMinutes() const;
...
};
Мы можем взять параметры функции и обрезать их.
Было:
Код:
Time(int h, int m, int s, int ms);
Стало:
Код:
Time(int h, int m, ...);
Или ещё жёстче:
Код:
Time(...);
А ещё можно умолчать, например, тип данных. Вот так:
Код:
... str = "Some string";
Можно также рассмотреть
набор символов - это символы,
порядок которых не имеет значения. В этом случае символ неопределённости автоматически отправляется в конец.
Было:
Код:
abcdef
Стало:
Код:
abcf...
2 МотивацияНафиг этот язык вообще нужен?
Давайте сравним с
языком программирования. Язык программирования нужен, чтобы компилятор - посредник между программистом и процессором, смог преобразовать код в машинный код.
Язык разработки не предназначен для работы с компилятором. Он необходим для общения разработчиков между собой.
Но! Это было хитростью - сформировать язык разработки над языком программирования. Теперь можно программировать сколь угодно точно, но при этом иногда
не столь точно выражать свои мысли.
3 Есть ли аналоги?Это нормальный вопрос. Аналоги есть - и это
комментарии, которые можно делать практически в любом языке программирования. Комментарии не предназначены для исполнения процессором, но нужны для разработчиков. По сути язык разработки - это упорядочивание правил комментирования в ЯП. Но надо это понимать в узком смысле, когда мы рассматриваем именно языки программирования, а не что-нибудь другое.
Я вижу язык разработки как нечто бОльшее. Просто с языками программирования намного проще.
Я бы добавил язык разработки, например, в САПР типа Автокад/Компас. Ну это те, с которыми я хорошо знаком. Представьте себе, если бы в чертеже детали или сборочной единицы был бы комментарий типа "Эту деталь я разработал по кривому техзаданию от заказчика X, дата 16.09.2025".
4 Практическая реализацияЕсли рассмотреть комментарии в ЯП как некий особый язык, то мы натолкнёмся на определённые правила типа "комментируй так, а не так". Эти правила замечательны... Инновация заключается в том, чтобы вместо свободного комментирования ввести правила некоего нового языка - языка разработки - и мягко интегрировать этот язык в существующий язык.
Выделим в правилах комментирования следующие пункты, которые я поддерживаю, но предлагаю так или иначе реформировать:
- Список "to do". Если класс, функция, список параметров функции или иная цепочка символов завершены, то не должно быть символа незавершённости - многоточия (...). Если вы уверены, что надо что-то дописать в коде, поставьте это многоточие. Таким образом места недоработки можно будет легче отыскать.
- Комментирование debug-строчек. Пометьте строчки или участки кода как debug, чтобы потом не забыть их раздебажить.
P.S. Я может забыл описать какие-то нюансы и аспекты применения
языка разработки, но, мне кажется, пора закруглиться, чтобы не усложнять освоение информации.
-- 16.09.2025, 20:16 --Я наверное упустил упомянуть следующее для стопудового донесения смысла. Есть два варианта:
1. Если есть символ незавершённости (неопределённости) - ... - это сигнал "тут незакончено, надо дорабатывать".
2. Если нет символа - "я тут всё сделал, не надо сюда совать свой нос".
Это очень важные сигналы между разработчиками.
Есть ещё другие типы сигналов, я о них умолчал, но на этапе осознания нового языка [разработки] это неважно.
16.09.2025, 19:19 
