, особенно под конец, вскрылись многие механизмы мышления. Если человек хочет что-то запомнить, а потом вспомнить, то существуют конкретные способы этого достичь. Можно так же более эффективно управлять мышлением, если понимать различие между разными видами мышления по порядку развития, такие как:
Возьмём для примера бизнес, подавляющее большинство использует таблицы. Раньше это был Microsoft Office Excel, в наше время многие переходят на LibreOffice Calc, что в принципе почти одно и тоже с точки зрения базового функционала. И не только для документации, для интернет магазинов тоже преимущественно предпочитают набирать данные в таблицах, а потом импортировать в CMS.
Метапрограммирование
Следующим пунктом вспоминаются системы метапрограммирования, такие как JetBrains MPS. Лично я без понятия как там всё работает, но могу провести точно такую же аналогию, где CMS соответствует системам метапрограммирования. И то и другое решение специализировано, но вот таблицы нет.
Впрочем вспомнил я об этом немного по другой причине. В JetBrains MPS решили отказаться от парсера и генерировать код в одном направлении. Я не знаю, что у них там сейчас, но что если взять таблицы и точно так же использовать генерацию в одном направлении, то есть из них в код.
Привет мир
Приступим к тестированию идеи. Лично я буду использовать Geany в качестве IDE.
1) Терминальные символы — это минимальные элементы грамматики, не имеющие собственной грамматической структуры.
2) Нетерминальные символы — это элементы грамматики, имеющие собственные имена и структуру.
Предположим нужно смещать уровни вложения, то есть перемещать ячейки влево, вправо с помощью команд вырезать и вставить.
Для этого можно использовать универсальную формулу:
=CONCAT($B##;..)
=CONCAT($B##;..:..)
Где ## это номер текущей строки в которой находится формула, а .. ячейка терминала или диапазон нетерминалов.
Так же сделан стандартный отступ от левого края уровня 1:
=CONCAT(CHAR(10);" ")
Хотя следует понимать, что отступы могут быть и внутри строки. Все они вынесены в столбец B чтобы сэкономить место на значимые терминалы и нетерминалы, отсюда и усложнение формул.
📦 Прототип _ [ ] x
Файл Правка Вид Инструменты Окно Справка
📦 Prototype _ [ ] x
File Edit View Tools Window Help
Стоит отметить, что этот метод хорош тем, что благодаря одинаковой ширине и высоте ячеек можно легко дублировать интерфейсы. И понятное дело изменение нетерминалов, или если нужно даже терминалов сменит текст.
Диапазон того же меню не обязательно держать на листе lua.сетка, можно сложить нетерминал подобно программе и дать на него ссылку. Да и в принципе здесь рассмотрен лишь простейший случай без амперсандов и прочего, но принцип от этого не изменится.
Здравствуйте, Dym On, Вы писали:
DO>Коллега, а можно, в общих чертах, так сказать, крупными мазками намекнуть: а какую проблему ты решаешь?
V>Предназначение
V>Для чего нужна подобная система:
V>1) микроконтроль
V>2) метаданные
С помощью метаданных можно управлять изменениями в коде. Например, есть функционал (features) A, B, C, но он раскидан по строкам и файлам. Чтобы добавить конкретный функционал C, нужно внедрить его внутрь строк или вставить несколько строчек в разные файлы, и так же обратная операция удалить функционал. Тоже самое касается, если нужно посмотреть или изменить код. По сути это классический CRUD. Но я же не зря начал с темы про мышление, ведь изначально никак не задокументировано где конкретно находится функционал A, B, C, эта информация существует лишь в голове написавшего программиста, если уже не забылась.
Или микроконтроль:
V>отступ/функция
V>отступ/уровень/1
Для примера отступ между названием функцией и параметрами это не тот же самый отступ, как в других местах. Всё это определяет стиль форматирования кода. Но гораздо важнее управление самим кодом, возможность ставить ссылки. Это позволяет проводить множество операций из науки логики. К примеру, const в C++ это ключевое слово, но используется в разных конструкциях по-разному, просто авторы языка решили назвать это одинаково. Причём они назвали всё по-английски.
Или другой случай нужно выполнить операцию сравнения из науки логики между конструкциями выполняющими одно и тоже, но в разных языках или программах. Сама же работа приведённая выше это анализ, когда код разлагается в таблицу, а потом синтез, когда он собирается в нужную конструкцию. Смысл в том, чтобы не повторять терминалы или даже нетерминалы создавая код и прочие таблицы.
В конечном итоге код это не просто какой-то текст, он парсится и преобразуется в абстрактное синтаксическое дерево. Из конструкций языка можно создать собственные конструкции, но в тексте всё это никак особо не обозначено. У меня уже давно много вопросов. Например, является ли сплошной текст идеальной формой записи кода, и ответ явно нет, нежели да. Целесообразность хранения мелких деталей производства программ в голове, а не на внешнем носителе. Как работать с сильно возросшими объёмами данных, где данные это так же программы и библиотеки алгоритмов.
И я уже написал в самом начале, что бизнес при работе с данными использует таблицы, а могли бы писать сплошной текст как программисты. Может бизнесмены поголовно идиоты, они не знают, что есть редактор простого текста — являющийся высшей формой эволюции для работы с данными? Потому проверить идею таблиц совсем не повредит.
Да́нные — зарегистрированная информация; представление фактов, понятий или инструкций в форме, приемлемой для общения, интерпретации, или обработки человеком или с помощью автоматических средств (ISO/IEC/IEEE 24765-2010).
Данные (вычислительная техника) — поддающееся многократной интерпретации представление информации в формализованном виде, пригодном для передачи, связи, или обработки (ISO/IEC 2382-1:1993).
Метаданные (от лат. meta — цель, конечный пункт, предел, край и данные) — информация о другой информации, или данные, относящиеся к дополнительной информации о содержимом или объекте.
Структура данных (англ. data structure) — программная единица, позволяющая хранить и обрабатывать множество однотипных и/или логически связанных данных в вычислительной технике.
Тип данных (тип) — множество значений и операций над этими значениями (IEEE Std 1320.2-1998).
Объе́кт (в программировании) — некоторая сущность в цифровом пространстве, обладающая определённым состоянием и поведением, имеющая определённые свойства (атрибуты) и операции над ними (методы).
Состояние (информатика) цифровой логической схемы или компьютерной программы является техническим термином для всей хранимой информации, к которой схема или программа в данный момент времени имеет доступ.
Те́кстовые да́нные (также те́кстовый форма́т) — представление информации строкового типа (то есть, последовательности печатных символов) в вычислительной системе.
Ба́за да́нных — представленная в объективной форме совокупность самостоятельных материалов.
Модель данных — формальная теория представления и обработки данных в системе управления базами данных (СУБД).
Схема базы данных включает в себя описания содержания, структуры и ограничений целостности, используемые для создания и поддержки базы данных.
Структуры и типы данных
Чем отличается структура (строение) данных от типа данных? Если вчитаться в определения, то ничем. Если ориентироваться на реальный мир, то структура должна иметь некое взаиморасположение данных в памяти, а не только однотипную обработку. Но в итоге всё сводится к интерфейсам с помощью которых происходит управление данными, а внутреннее устройство вторично.
Опять же если взять C/C++ и некоторые другие языки, то встроенные типы это по сути машинные команды, а вот структуры это типы определяемые пользователем. Иначе говоря в высокоуровневых языках программирования и то и другое является определёнными конструкциями.
Объекты и состояния данных
При формализации некой системы гораздо удобнее пользоваться конкретными, а не абстрактными понятиями. Это значит вместо структур и типов проще ориентироваться на объекты и их состояния. Для примера, понять как работать с неким общим списком имён сложнее, чем если представить списки имён в разных состояниях, таких как пустой список имён "", или список имён с несколькими именами "Вася; Коля; Миша;".
снимок экрана 01
категории типы состояние
математика/арифметика/число/пи вещественное одинарное 3,14159265
литерал/строковый/мир/привет строка unicode Привет мир!!!
литерал/строковый/мир/пока строка unicode Пока мир!!!
Может быть говорить об этом несколько преждевременно до глобального разбора программ, но раз уж эта мысль пришла мне в голову, то сразу её запишу.
Сразу вылезают два очевидных недостатка:
1) Код содержит лишние данные, такие как маркеры изменений, и чем они больше, тем больше засорения.
2) Управлять изменениями нужно не только на уровне строк, но и на уровне подстрок, чего не наблюдается.
Упрощение таблицы
Произведены следующие улучшения структуры таблицы.
3) Жёлтый цвет это строки ссылочных нетерминальных данных
Пример:
строка 6
=$B$39 =$C$39
В строке располагаются ссылки на литералы. Номер строки, в данном случае 39, должен совпадать в обоих столбцах, так как есть две ссылки, на описание и на сам терминал. Комментарий должен быть всегда в одном и том же столбце, таком как B. Сама же ссылка на терминал может смещаться для удобства чтения по уровням:
столбец D уровень 1
столбец E уровень 2
столбец F уровень 3
столбец G уровень 4
Знаки доллара в номерах ячеек поставлены для того, чтобы правильно срабатывали операции с блоками ячеек:
1) Вырезать, копировать.
2) Вставить.
4) Оранжевый цвет это строки объединённых нетерминальных данных
CRUD — акроним, обозначающий четыре базовые функции, используемые при работе с базами данных:
1) создание (англ. create, примечание: база данных insert),
2) чтение (read, примечание: база данных select),
3) модификация (update),
3) удаление (delete).
Предположим у нас есть две разновидности функционала:
Таким образом стирая все строки со ссылками на функционал "печатать/приветмир" можно его удалить, ведь новый код будет сгенерирован автоматически. Так же можно ориентироваться на эти метаданные чтобы прочитать, изменить или добавить текущий функционал.
Благодаря микроконтролю можно осуществлять массовые операции в том числе и внутри строк кода.
Управление тегами
Древовидные теги навроде
печатать/приветмир
или
препроцессор/директива/начало
можно использовать для того, чтобы вкладывать один функционал, терминалы и прочее в другие.
Но что, если в код будет включён заголовочный файл для того, чтобы создать функционал, но благодаря нему будет создано несколько видов функционала. В этом случае можно применять точку с запятой для добавления нескольких тегов.
печатать/приветмир;печатать/покамир #include "функционал.hpp"
печатать/приветмир ...
печатать/приветмир использование функционал.hpp
печатать/приветмир ...
печатать/покамир ...
печатать/покамир использование функционал.hpp
печатать/покамир ...
И соответственно при удалении строка включения заголовочного файла не будет удалена пока не будут удалены все теги описывающего её функционала. Такое решение это то, которое первое приходит в голову, но если у кого есть идеи лучше, пишите.
Все о ней слышали, но никто её не видел. Настало время вывести архитектуру на чистую воду.
Общепринятого определения архитектуры программного обеспечения не существует. Так, сайт Software Engineering Institute приводит более 150 определений этого понятия.
Люди дают каждому определению своё название. Если названия нет, то и понятия нет, или по крайне мере оно не может быть представлено в словесной форме. Для того, чтобы это исправить, нужно всего лишь придумать название. Иными словами каждая архитектура должна как-то называться, например, "нисходящая процедурная" архитектура, архитектура "недетерминированной машины состояний" и так далее.
Следующий вопрос, каждая ли программа имеет архитектуру? Здесь и далее я буду считать, даже если это не чистая архитектура, а смешанная. Отсюда вытекает простой вывод, приведённая выше программа "привет мир" для языка C++ так же имеет архитектуру или может опознаваться как программа на некой архитектуре или архитектурах.
Лично я буду считать, что архитектура это конструкция проходящая через всю программу. Но при этом не нужно думать, что её можно описать с помощью функционала.
Таким образом:
1) Функционал
2) Нетерминал
Превращаются в:
1) Функционал
2) Архитектура
3) Нетерминал
Функционал имеет более высокий уровень абстракции, тогда как архитектура и нетерминалы являются конструкциями, где архитектура опять же имеет более высокий уровень абстракции по сравнению с нетерминалами.
Где "процедура/нисходящая" это общее название архитектуры, а "процедура/нисходящая/точкавхода" и "процедура/нисходящая/включения" элементы конструкции. По идее можно было бы убрать название архитектуры из элементов конструкции архитектуры и писать лишь "точкавхода" и "включения", так как в одной программе должна быть одна архитектура.
Между тем более сложные архитектуры могли бы иметь персонализированные элементы, такие как процедуры "процедура/приветмир", "процедура/покамир". И здесь не нужно путать функционал "приветмир" и "покамир" и общие элементы архитектуры, такие как "процедура" и другие, которые воплощают этот функционал.
Расширение метаданных
Помимо терминалов и нетерминалов воплощающие код программы добавлены метаданные для управления функционалом и архитектурой. Подумайте как ещё можно использовать возможности метаданных и напишите в комментариях.
Программирование таблиц решений, Хамби, 1976
Книга посвящена изложению методов трансляции с одного из непроцедурных языков программирования — с языка таблиц решений. Программы, написанные на этом языке, позволяют удобно описывать сложные ситуации, возникающие при системном анализе. Таблицы решений представляют собой новый перспективный метод программирования, который находит применение при решении многих задач системного анализа. Книга предназначена для разработчиков АСУ, системных аналитиков и системных программистов, занимающихся разработкой трансляторов. Она может служить учебным пособием для студентов, изучающих методы трансляции.
Вот эта таблица:
Таблица принятия решений (таблица решений) — способ компактного представления модели со сложной логикой. Аналогично условным операторам в языках программирования, они устанавливают связь между условиями и действиями. Но, в отличие от традиционных языков программирования, таблицы решений в простой форме могут представлять связь между множеством независимых условий и действий.
Диаграмма состояний (или иногда граф переходов) — графическое представление множества состояний и функции переходов. Представляет собой размеченный ориентированный граф, вершины которого — состояния конечных автоматом, дуги — переходы из одного состояния в другое, а метки дуг — символы, по которым осуществляется переход из одного состояния в другое. Если переход из состояния q1 в q2 может быть осуществлен по одному из нескольких символов, то все они должны быть надписаны над дугой диаграммы.
Таблица переходов — табличное представление функции δ. Обычно в такой таблице каждой строке соответствует одно состояние, а столбцу — один допустимый входной символ. В ячейке на пересечении строки и столбца записывается состояние, в которое должен перейти автомат, если в данном состоянии он считал данный входной символ. Пример таблицы переходов для автомата, заданного в виде графа по рисунку 1 приведена справа.
Следующее состояние
Входной
символ a Входной
символ b Любой
другой
символ
p0 p1 p0 p0
p1 p1 p2 p1
p2 p3 p4 p2
p3 p3 p5 p3
p4 p4 p4 p4
p5 p3 p5 p5
Но у меня, особенно это видно в последней упрощённой версии, нет никакой трансляции из одного языка в другой. По факту представлен тот же самый код, то есть даже не абстрактное синтаксическое дерево, а разобранный на терминалы код, который при сложении соответствует оригиналу один в один. Лично я не нашёл как это называется, и я ни разу не встречал подобное решение с метаданными в литературе. Если кто знает, пусть напишет.
LVV>>А ты в принципе читал книжку Хамби Программирование таблиц решений? LVV>>Я ее еще в советское время читал. V>Сейчас посмотрел, это абсолютно другое.
Дело не в трансляции, а в таблицах решений.
Очень неплохой инструмент в некоторых случаях.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
V>>Сейчас посмотрел, это абсолютно другое. LVV>Дело не в трансляции, а в таблицах решений. LVV>Очень неплохой инструмент в некоторых случаях.
Это всё относится к потокам управления, те же операторы ветвления, машины состояний и прочее. В общем всё то, что строится на безусловном и условном переходе из машинных команд процессора.
У меня примерно такие вопросы.
1) Что представляет из себя код?
2) Нужно ли писать уже написанный кем-то код заново?
3) Почему так сложно пользоваться чужими решениями?
И я решаю задачу основываясь на следующих принципах:
1) Код остаётся в исходном виде.
2) Дублирование исключается ссылками на ячейки и диапазоны ячеек.
3) Метаданные образуют дополнительные слои описания.
Конструирование кода в ходе развития программирования переусложнено. Сделать же что-то отличное крайне проблематично, да и получим ещё один бессмысленный язык. Множество особенностей, которые якобы помогают думать на самом деле не помогают.