Машины теорий. Структура линейного текста и ее альтернативы

Алексей Седов, 1997

Уважаемые Господа! Хочу предложить Вам (в сокращении) фрагмент моей старой статьи по ряду проблем построения программ. Статья была написана по другому поводу, чем предлагавшиеся мною ранее материалы, но, надеюсь, она немного прояснит то, что я понимаю под введенными ранее понятиями. Полагаю, ее чтение не оставит сомнений в том, что я не считаю, будто люди мыслят многомерными матрицами. В настоящий момент мне трудно предложить какой-либо иной способ ответить на возникавшие здесь вопросы, чем пересылка в конференцию фрагмента моего архива.

Ниже почти не дается ответов, скорее - проясняются исходные вопросы. Но в структуре знания вопрос важнее ответа! Правильно поставив вопросы, полнее осознав ситуацию и проблему, мы приближаемся к истинному ответу больше, чем пытаясь нащупать его "по наитию". Найти что-то можно, только если знаешь, что искать.

С уважением, A.S.

ТЕЗИС 1. Ограничения и законы познания

1.1. Человеческая способность одновременного оперирования понятиями ограничена в среднем 4-7 чанками (до 12 чанков - у наиболее выдающихся особей Homo sapiens). Для простоты положим, что чанк - это ровно одно понятие с минимальным контекстом, в котором оно используется. Понятно, откуда родились призывы (наиболее знакомые "обычным" программистам по языку С): разбивайте программу на множество маленьких подпрограмм - из стихийного осознания того физиологического факта, что человек не в состоянии воспринять как целостность текст объемом более половины обычной книжной страницы.

1.2. Разработка программы - это всегда процесс постижения разработчиком проблемы, решаемой программой (я не пишу "программистом" только потому, что нанюхавшиеся забугорных веяний снобы теперь нагло обзывают трудягу- программиста "кодировщиком" :-(). Процесс постижения задачи в основном и обслуживают широко распространенные за границей CASE-технологии, весьма мало используемые в ex-СССР. Наши крутые программисты либо слишком умны, либо слишком ленивы, чтобы отделять фиксацию собственного понимания задачи от порождения соответствующего кода на языках программирования. Да и необходимость разбираться в мудреных диаграммах, языках и схемах CASE (а тем более - использовать их самому!) не привлекает. Поэтому большинство отечественных проектов настолько неструктурированно, что нельзя отделить семантический слой решения задачи от чисто кодового средства реализации решения.

Народ ваяет прямо на C++ или Delphi и уверен, что держит Бога за бороду... Компании типа Borland и Microsoft усиленно поддерживают в несчастных эти самодовольные иллюзии... :-)) Из чувства патриотизма (и справедливости) должен заметить, что забугорным программерам тоже не слишком помогают их CASE-технологии в работе с процессом познания задачи, поскольку предназначены они не для этого, а для создание разнообразных frameworks по исходной постановке. Так что обозначенная проблема не знает границ.

1.3. Ввязавшись в процесс постижения чего-либо - всегда итерационную процедуру! - проектировщик не все постигает сразу в окончательном виде. Понимание приходит постепенно, шаг за шагом, слой за слоем. Если проект делается сразу в коде, то это означает регулярное перепрограммирование задачи (хорошо, если частичное!). При этом понятия, казавшиеся поначалу очень важными, постепенно "отходят на второй план", вытесняясь из сознания другими понятиями, более отражающими истинную природу задачи. Но ни в языках программирования, ни в средах разработки программ нет адекватных инструментов как для отражения эволюции понятий, так и обслуживания этой эволюции. Нельзя считать слишком серьезными претензии на это ООП, так как смена одной иерархии классов на другую - это катастрофа проекта (или, мягче выражаясь, его перепрограммирование). Максимум, даваемый ООП в руках настоящего профессионала - это четкая фиксация в виде иерархии классов итога процесса постижения на текущий момент.

Продолжение процесса постижения завтра сделает сегодняшнюю иерархию классов процентов на 75 (скажем так) "неактуальной". Да и в самой иерархии классов нет четкого деления на "уровни понимания" и нет способа указать, "маршрут познания", вне следования которому постижение чужих иерархий часто превращается в мучительную задачу, которая вполне сродни постижению чужого текста программы на Forth, написанного человеком с отличным от "стандартного" мышлением.

1.4. Основной парадокс программирования: конечным продуктом разработки программной системы является исчерпывающее и точное (в идеале) понимание решаемой задачи, которое как раз и не записывается в каком-либо виде и никак не фиксируется. Записывается и фиксируется совсем другая вещь: порожденное пониманием частное решение задачи. Восстановить по решению исходное понимание бывает всегда просто невозможно!

ТЕЗИС 2. Основная проблема программирования

2.1. Сложность есть мера неоднородности. Чем более разнообразны составляющие нечто части, чем более разнообразны образуемые между частями связи - тем выше сложность этого нечто. Сложность вселенной, состоящей из сложенных одинаковым образом одинаковых кирпичей, равна сложности одного кирпича и образуемых им с соседями связей (теорема редукции сложности). Таким образом, сложность выражает не массоэнергетические характеристики мира (см. E=m*c**2), а структурные его свойства, причем весьма емкО и общО.

2.2. Все разработчики программ имеют дело исключительно со сложностью. Программы не имеют ни массы, ни энергии (если отвлечься от параметров исполняющего их hardware). Программы - это чистые структуры, и сложность является одним из основных интегральных параметров этих структур. Борьбе со сложностью и посвящают программисты свою жизнь. Эта борьба обычно вполне безнадежна для программистов, поскольку они не понимают законов мира, в котором пытаются оперировать структурными конструкциями, иерархиями классов или словарями. Программисты - герои "невидимого фронта" боев с колоссальными объемами незнания; герои, которых вооружают негодными погремушками вместо настоящих инструментов постижения истины. Настоящие профессионалы быстро понимают, что разработчики языков программирования типа C/C++ или Pascal/Modula/Oberon и фирмы-производители таких инструментов просто морочат им голову, предлагая вместо серьезных средств всего лишь генераторы случайных блужданий в пространстве состояний задачи. В поисках выхода некоторые пытаются создавать собственные инструменты (обычно - безуспешно), но большинство открывают для себя неязыковые (в смысле ЯВУ) средства программирования типа Forth. Само по себе это уже хорошо, поскольку глупости вроде приоритета значка ++ не застилают теперь им глаза на существо дела. Хотя даже Forth сам по себе (и он - прежде всего!) не дает поначалу никаких преимуществ в работе, кроме реального осознания "размеров бедствия". Но осознание проблемы - уже половина решения...

2.3. А существо дело крайне просто сформулировать: основная проблема программирования - это проблема управления сложностью программы; это проблема "размазывания" сложности вдоль текста программы "ровным слоем" (не слишком толстым, но и не очень тонким - как масло на бутерброде); не допускать "сгущений" сложности важно просто потому, что именно в таких местах сложность легко "перепрыгивает" ограниченные человеческие способности к одновременному восприятию множества взаимосвязанных вещей и в программе появляются не описки, а настоящие ошибки (ограниченность на любом уровне познания понимания задачи нельзя считать ошибкой - это просто имманентная особенность познания, процесс которого, как известно, бесконечен).

2.4. Если попробовать пересказать "своими словами" (без формул) учебник матанализа, то можно обнаружить, что пересказ занимает на порядки больший объем текста, чем "первоисточник", а также непригоден к использованию на практике по причине неспособности дать краткие и внятные рецепты действий в типовых ситуациях. Этот феномен объясняется с помощью понятия "метрика текста", в которое здесь не хотелось бы углубляться. Достаточно отметить, что современные средства программирования являются квази-математическими, поскольку метрики порождаемых ими текстов по мощности не слишком серьезны по сравнению с метриками обычных математических текстов. В чем причина? Причина в том, что математический текст всегда строится В терминах решаемой задачи. А вот средства программирования представляют собой всегда некую жесткую "систему команд", в рамках ограниченной и жесткой семантики которой приходится записывать постановки и решения задач. Процесс "трансляции" содержательной постановки задачи в тексты средств программирования выполняется в подавляющем числе случаев "вручную" и состоит в переводе терминов исходной задачи в термины целевого языка. Этот процесс и есть первопричина всех проблем, а его исключение - цель новой технологии программирования.

2.5. Не вдаваясь в детали реализации инструмента, решающего эту задачу, можно отметить лишь одно непременное условие: новая технология должна представлять собой формализм, немашинный алгоритм (но понятный и простой для человека!), позволяющий всегда записывать постановку задачи и методы ее решения в терминах только самой задачи с привлечением одного-единственного автоматизма: автоматизма разделения и контроля сложности. Цель такого автоматизма - дать полный контроль над любой частью постановки или решения задачи непрограммисту, "активное поле внимания" которого может не превышать обычных 4-7 чанков.

2.6. Сегодня уже известно много способов реализации автоматического разделения сложности. В частности, это логико-матричные методы (например, расширенные таблицы решений), специальные логики (темпоральные, нечеткие и т.п.), методы факторизации, событийно-ориентированные протоколы взаимодействия процессов и т.д. Вопрос представляет не возможность реализации такой системы, а ее форма и конкретный набор используемых средств.

Фрагмент моего ответа по subj из личной переписки

К сожалению, моя книжка "Машины теорий" (рабочее название: "Структура линейного текста и ее альтернативы") находится частично в рукописи, частично - в голове. Subj занимает меня примерно 15 последних лет. По этому поводу я сам не читал ничего связного: так, разные детали. Боюсь, что в предложенном виде теория эта - собственно моя.

Разумеется, идеи там частично мои, а частично - чужие. Например, идею таблиц решений (у меня они используются в качестве матриц связей между параметрами процессов) я вычитал у Хамби ("Программирование таблиц решений", М., "Мир", 1976), а потом "закрепил" статьями из Communication of the ASM за 1976-1985 гг. Идею использовать внутри матрицы связей (да и везде в системе) "словный" синтаксис подсказало мне знакомство с языком Forth (Чарльз Мур), книг по которому вышло очень много. Идея многомерных переменных (включающих в себя всегда одновременно: логическое, арифметическое, графическое, звуковое, текстовое и т.д. значения) в общем-то моя, но ее отголоски можно встретить в ООП и языке C++. Теория сложности (сложность есть мера разнообразия), вероятно, собственно моя, как и представления о метрике текстов (линейные и нелинейные тексты, плоские тексты...), логика по основанию больше двух широко известна в современной математике (см., например, Белнап, Стил, "Логика вопросов и ответов", "Мир", 198?.). И т.д.

Попробуйте почитать книжку Хамби и познакомиться с языком Forth. Примерную, весьма неполную, но технически наглядную аналогию моей системы можно получить так: представить себе язык Forth, у которого все управляющие слова выброшены и заменены модернизированными таблицами решений. Плюс специальная среда для записи текстов. Плюс специальная транспортная структура этих текстов и БД, используемая при их динамической интерпретации. К сожалению, плюс еще много всего, о чем в одном абзаце не напишешь. Аналогично можно сделать, используя вместо Forth языки C/C++/(Object)Pascal, но тогда нужно отказаться от их собственного синтаксиса, приняв, что программа есть многомерная таблица из слов, а уже определения слов строятся по правилам C/C++/(Object)Pascal. И т.п.

Из новых книжек попробуйте почитать: Шлеер, Майер, "Моделирование мира в пространствах состояний", она недавно переводилась, кажется, в киевской "Диалектике". Кстати, если найдете лишнюю книгу, и Вам это будет несложно, пришлите и мне по обычной почте экземпляр - я вышлю Вам деньги, как только потребуется. Здесь тоже есть жаждущие читатели.

В общем-то, порадовать мне Вас пока особенно нечем. Я занимаюсь своей технологией урывками, между зарабатыванием хлеба насущного, и поэтому теория, родившаяся у меня в теперешнем виде несколько лет назад воплощена только частично в рукописи и комплекте соответствующих программ. Правда, я использую некоторые элементы в бизнес-разработках. Получается довольно занятно: производительность труда подскакивает примерно на порядок. Надеюсь, я сумею в будущем завершить эту работу, приведя ее к "публикабельному" виду.

A.S.

Уважаемые Господа!

Если не возражаете, я продолжу посылать сюда небольшие выдержки из своего архива, поясняющие отдельные вопросы, затронутые мною ранее. Надеюсь, это поможет прояснить мой "птичий язык", который стал мне уже привычен, но, наверное, не является общепринятым.

С уважением, A.S.

ТЕЗИС 3. Тупик языков программирования

3.0. В начале 60-х в технологии программирования был совершен тяжелый просчет - были введены и массово распространились современные языки высокого уровня (ЯВУ). Последующее печальное развитие событий (прогресс скорости CPU составил более чем шесть порядков, тогда как производительность труда программистов возросла едва ли на порядок) было следствием ряда характерных черт ЯВУ, не преодоленных по сей день.

3.1. Можно выделить много второстепенных черт ЯВУ, затеяв дискуссии о преимуществах C над Pascal, Java над C++, или наоборот, но все это будут бесполезные споры. Порочен сам принцип современных ЯВУ: вместо инструментов познания, записи, накопления и расширения человеческого опыта в конкретных предметных областях, ЯВУ представляют собой громоздкие, противоречивые, нелепые и ограниченные системы обозначений, придуманные, в основном, для удобства разработчиков компиляторов. :-)) Вся многотрудная деятельность ANSI и ISO, в принципе, почти бесполезна, так как является полным аналогом кампаний по наведению порядка в мире молекулярного хаоса идей, подходов и принципов разработки ЯВУ, основной смысл которых состоит не в том, чтобы гарантировать решение реальных задач в желаемые сроки, а построить очередную систему для обеспечения случайного блуждания программиста в пространстве состояний решаемой задачи. Все существующие ЯВУ были построены в результате логически не обоснованного "озарения" их разработчиков разными видами титанических идей. При этом разработчики ЯВУ полностью игнорировали суть проблем, возникающих при решении мало-мальски серьезных задач.

3.2. Даже если не обращать внимания на темноту, провалы и лакуны, неортогональность и противоречивость семантики ЯВУ, есть еще одна печальная закономерность, свойственная почти всем им: они имеют синтаксис и этот синтаксис - ужасен! Мы так привыкли к хитрым значками и их сочетаниям типа ((((((((())))))))) - Lisp, *++->+= - С/С++, :=@= - Pascal и т.д., - что даже не задаемся вопросом: а зачем все это нагорожено? Ведь, несмотря на все хитросплетения, Pascal и C, например, семантически тождественны в 95% своих возможностей и не имеют никаких преимуществ друг перед другом, являясь оба одинаково плохими (или одинаково хорошими :-) языками... ЯВУ уже 30 лет водят программистов по одному и тому же порочному кругу проблем, ничуть не приближая решение ни одной из них. Более того, проблема ошибок в программах с появлением ООП просто усугубилась, и любой знающий человек сразу скажет, что отлаживать объектные программы куда труднее, чем обычные процедурные.

3.3. Осознание этих истин побудило меня в свое время заняться поисками истинных причин возникновения проблем, являющихся в ЯВУ хроническими, и ничуть не решаемыми ни одним новым ЯВУ - будь то Java, Oberon или C++++...

ТЕЗИС 4. Процессы и параметры, пространство состояний

4.0. Одной из идей, все поставившей на ноги, стало представление о пространстве состояний решаемой задачи. Вкратце это вот что. В мире нет ничего "твердого", мир - это ансамбль взаимодействующих динамических процессов, иногда иерархически связанных, но очень часто - нет (вот причина провала ООП). Каждый процесс интересен нам в конкретном случае проявлением ряда своих пара- метров. Каждый параметр характеризуется дискретным перечислимым набором значений (например, {мир, война}, {горячий, теплый, холодный}, {киты, тюлени, олени} и т.п.). Каждому значению можно сопоставить числовое множество, иногда просто нумерующее значения по порядку (при слабой математической подоплеке изучаемой области), иногда представляющее собой участок числового континуума (температура для физики, например), а иногда - числовое гиперпространство с законами много сложнее аксиом матанализа (алгебры элементарных частиц).

4.1. Выбирая "квант наблюдения" интересующего нас суперпроцесса (среды), содержащего все остальные микропроцессы, мы имеем МНОЖЕСТВО характерных несовпадающих периодов стабильности для подпроцессов рассматриваемого суперпроцесса, при переходе между которыми радикально может меняться не только модель отдельного микропроцесса, но и модель суперпроцесса, представляющего для микропроцессов среду существования. Вне пределов конкретного периода стабильности данного микропроцесса его описание может меняться самым причудливым способом, становясь прямо противоположным текущему. Практически невозможно иметь одно и то же описание для каждого подпроцесса на все интересующее нас время решения задачи. И здесь не поможет никакая иерархия классов. Требуется для каждого "объекта" иметь более чем одно описание и свободно переходить между ними в требуемые моменты исполнения модели.

4.2. Каждый микропроцесс интересует нас как набор определенных параметров. Некоторые из них являются внешними для микропроцесса (параметры среды или па- раметры других, связанных любым способом с данным микропроцессов), некоторые - внутренние (параметры микропроцесса). Связи между всеми параметрами микро- процесса (внешними и внутренними) задаются матрицами связей, описывающими правила перехода между значениями любого параметра при заданных значениях всех других связанных параметров. В простейшем (и наиболее общем случае) матрица связей имеет размерность алгебраического произведения всех значений всех собственных параметров микропроцесса и внешних связанных параметров.

ТЕЗИС 5. Многомерность параметров модели

5.0. Правила перехода между значениями параметров в матрице связей процесса ("функции/подпрограммы" в обычном программировании или "методы" в объектном) обязательно должны иметь два представления: логическое - оперирующее "словесными" обозначениями значений параметра типа {горячий, теплый, холодный} и числовое - оперирующее соответствующими числовыми значениями (для температуры это могут быть соответственно величины {3E+5C, 42.3C, -70C}). "Словесно-логическое рассуждение", понятное даже непрограммисту-специалисту в данной предметной области, должно "подкрепляться" числовыми вычислениями, идущими (")параллельно(") логическому процессированию модели. Наличие только одного (логического или числового) представления модели изучаемого явления делает модель заведомо ущербной, а споры по поводу того, какие языки - "логические" (типа Lisp) или "вычислительные" (типа C/Pascal) "лучше", являются полными аналогами глупых споров о том, что важнее для организма - сердце или желудок. Тогда как без любого из органов обычно быстро наступает смерть, а оба упомянутых типа языков способны породить порознь только заведомо неполноценные модели, либо лишенные серьезных логических оснований, либо адекватного и эффективного аппарата количественного анализа.

5.1. Многомерность значений таким образом введенных "переменных" (параметров процессов) позволяет выполнять всю постановку задачи в терминах семантики этой задачи, создавая тезаурус (словарь) предметной области, и оставляя детализацию "вычислительного" аспекта постановки либо на "потом", либо на работу профессионального математика, либо выполняя эту работу немедленно, если человек, создающий модель, владеет предметно-ориентированной математикой, принятой в данной профессиональной области. Обычно дело тут сводится просто к вызовам стандартных подпрограмм, правда логика модели может привести к тому, что будут вызываться несколько методов (скажем, решения дифуравнений), но каждый - либо на логическом участке, где его использование будет осмысленным, либо параллельно, если модель включает в себя несколько альтернативных теорий.

5.2. Аналогично логико-цифровому представлению параметров, они могут иметь параллельно и ряды других значений: графических, звуковых, интерфейсных, тексто-комментирующих и т.д. Соответственно, модель является многомерной и по другим аспектам, а поэтому ее исполнение может быть сведено к показу мультфильма, генерации звукового ряда или рассказу (совету, консультации) на естественном языке. Подчеркну, что все это не имеет ничего общего со спекуляциями ИИ!

A.S.

Прочитать архив обсуждения этой статьи в конференции relcom.comp.software-eng (текст на одной странице, 350 Кб)

AttachmentSize
Package icon sedov_dispute.html.zip122.81 KB