Desutorakuta писал(а):
И написание первых двух вариантов занимает обычно больше времени, чем потом реализация остального функционала. Вот я и ищу сейчас решение, что бы такое написать, что бы можно было вокруг единого ядра строить свои проекты.
В таком случае возникает вопрос: что является "естественным языком" для Вашей "машины": отладчик, BASIC, shell, Perl...
Далее входим в цикл:
Пусть у нас в наличии некоторая OC. Уровень ее нам не важен: может, полуразобранный Спектрум, может, MS Excel... Пусть это будет, даже, не ОС в полном смысле слова, для примера не важно. Нам важно, чтобы была "машина", управляемая нашими командами и для которой мы мечтаем писать программы. Для определенности/понятности возьмем, например, MS-DOS. Теперь начнем "изобретать программирование".
0) Программирование нулевого уровня - ручной ввод команд одна за другой. В MS-DOS мы так и делали. Скопировать файл, запустить игру, почистить директорий...
1) Когда мы увидели, что набирать по одной команде лениво, мы начали писать командные файлы (скрипты) - несколько команд "упакованных в одну", возможно даже с какой-то примитивной логикой "если ошибка, то...".
2) Покопавшись в компьютерных журналах, мы узнали, что командные файлы можно научить не тупо выполнять "что прошито", но и спрашивать у пользователя "чего изволите?". Правда, изначально в DOS не было никаких средств для обращения к оператору, но их можно было легко создать или спереть готовые на стороне, не суть. Главное, что мы научились писать, как определил Мур "Программы с вводом".
Пропустим следующий этап и сразу перейдем к (4):
4) Мы стали системными программистами, и можем написать свой BASIC - систему, которая позволяет нам писать программы не на убогом командном языке MS-DOS, даже не знающем, что наш IBM PC может выводить на экран графику, а на крутой машине, умеющей работать с массивами и строками, бибикать ноты и рисовать цветные линии... По сути, мы возвращаемся к (0), но уже на новом технологическом уровне - можем вводить мощные команды, писать продвинутые скрипты-программы и т.д.
Теперь заткнем дыру:
3) Мы ищем способ не только увязывать команды в скрипты, но и создавать новые простые команды (а, заодно, и способы обмена информацией и передачи управления между ними). Т.к. результатом (4) будет новый язык (проблемно-ориентированный), то есть большое искушение назвать то, что, мы делаем на этом этапе, FORTH.
Однако, как ни назови, несомненно одно: нам придется залезть внутрь нашей исходной MS-DOS машины. И начать писать не на исходном языке команд command.com, а в кодах (например, в debug.com). И большая часть нашего BASIC-интерпретатора будет в этих кодах и написана (хотя он и сможет обращаться к MS-DOS, например, для работы с файлами). В случае же использования FORTH-метода "отскок в коды" будет совсем невелик - всего десяток основополагающих слов. Но, все равно, будет.