В очередной раз погрузился и просканировал ретроспективу программирования ... Как следствие автоматизации процесса ввода команд с пульта управления были введены карты (перфокарты, ленты, диски) и условная адресация, выражающаяся в именовании блоков памяти. С тех пор, принципиально, ничего не изменилось, к клавиатуре прибавился терминал, который стал сенсорным, но с тем же принципом "курсорного интерфейса". Что главное. Программирование - тотальная интерпретация. На физическом уровне - организация памяти с метафорой складирование объектов, каталогизация для организации доступа и автоматизация перемещения ... То же самое в абстракциях - выделение и символизация не только объектов, но и их референций и, соответственно референций между объектами и референциями и, собственно, между референциями, которые и есть абстракции. В результате практики выделилось несколько базовых схем, которые в разных комбинациях перемешиваются. Важно, что между интерпретацией машинного кода и целевой прикладной программой несколько уровней трансляции перед интерпретированием. Когда мы говорим о двух классах ПО - системном и прикладном, это и есть попытка регулирования процессов интерпретации и компиляции. Можно для каждого процесса программировать интерпретатор в его машинный код или ассемблер или выбрать универсальный транслятор или один из его интерпретаторов и расширять его в сторону моделирования специальной темы (предметной сферы, конкретной проблемы). А можно ещё оптимизировать "посредников" интерпретационного процесса ... Следует выделить несколько концепций с реализованными моделями, которые универсализируют нижний уровень (машинный или ассемблерный код) - Fortran, Oberon, С/C++, Forth, Lisp, APL, Smalltalk, ... Prolog, Erlang, Rust ... Java ... HTML, XML, XSLT/JavaScript ... и так далее, ряд можно продолжать, а выделенные отражают, практически, все базовые концепции без коррекции курса на распределенный гипертекст в сети. Так или иначе, жизнеспособность проектов поддерживается либо коммерческими корпорациями, либо сообществами апологетов. Оба типа институализации не гарантируют развитие любого проекта. Более того, даже право обладатели и авторы, отказываются от развития своих проектов ... В сухом остатке остаются только модели, концепции и опыт их реализации, интерпретации ... и инструменты, позволяющие пройти рутину со скоростью превышающей, предыдущую эволюцию, особенно, если выбрана оптимальная схема. Так вот, выбранные паттерны, а именно, Tiddlywiki и Rebol оптимально синтезируют весь эволюционный процесс программирования, каждый ориентируясь на свой "нижний уровень". Задача - специфицировать этот нижний уровень, смоделировать его и может даже реализовать.
Принципиальный комментарий! Ещё раз ... Для анализа практики моделирования можно выделить следующие базовые структуры - пару (*,*), пару пар ((*,*), (*,*)) и специальную пару (*, (*,*)). И следует всегда помнить, когда именуется пара (референция), а когда "физический" объект! Ну и, соответственно, сконструировать оптимальную базовую спецификацию, с возможностью переименования объектов, ситуаций и процессов.
1.34 Контр 2.34 Конфликт 3.34 Концерн 4.34 Координация 5.34 Копия 6.34 (Корка) Корпус 7.34 Космос
