Обсуждение

То что вы описываете как систему для разработки текстов - интересно. А вообще-то похоже на workflow systems, или enterprise decision planning или ERP, машины конечных состояний и т.д. Распространены такие системы, помимо банковских, нефтяных и т.д. промышленностей, в биоинформатике - это и понятно, геном - это текст на алфавите из четырех букв. Надо подумать как принципы, используемые там, распространить на чисто текстовые системы.

Твоё вступление навело меня на подозрение - ты не читал Британнику.

Мне тоже вспомнился электронный вариант Британники

Вынес сугубо утилитарную вещь: хорошо бы на сайтах писать что-то типа: "вы уже прочитали 5% текста".

Вы мой текст получили? А то у меня вчера перебой коннективности был.

От инструментария и от форматов. :) А проблема концептуальная. Сравните, как пишут большую программу: ее разбивают на модули, между модулями специфицируют интерфейсы. Межмодульное взаимодействие мимо интерфейсов не допускается. На практике, конечно, бывает цветущая сложность, но она обычно достигается изменением интерфейсов, а не взаимодействием помимо них. Детализация интерфейса и спецификаций модуля - гораздо глубже и точнее ваших аутлайнов, и отклонения обнаруживаются гораздо раньше и караются гораздо жестче - не как у вас, "к аутлайну надо относиться творчески". Резюме: пока не будет придуман аналог unit test для human readable текстов, все эти вики и онтологии - благие рассуждения, и толпой ничего умнее справочника не напишешь. В том смысле, что книги - не напишешь, только сборник обзоров или в лучшем случае энциклопедию, которая энциклопедия, даже Британника - тот же справочник по внутренней своей сути.

Получил, сейчас подробнее ответил письмом.

Ну, таким интерфейсом является онтология. Но онтология является интерфейсом к содержанию текста, а не к его форме (последовательности изложения). В программировании последовательность изложения не так важна (там есть линкер, таскбилдер или что-то подобное) -- для объектных текстов. Программирование как раз поэтому внутренне настроено на покладание большого текста маленькими кусочками, которые потом слипаются в один большой текст программы со всеми надлежащими динамическими оверлеями не вручную, а автомагически -- линкером/таскбилдером. Поэтому программисты так спокойно относятся ко всяким там викоидам и перегипертекстам -- они стыкуют текст как программу, по онтологии, а не по чтению текста. Они не просто компилируют гипертекст в свою голову, а еще и линкуют его в целостную структуру. У них в голове есть подходящие "аппараты" для линкования этой структуры, натренированное на это мышление. А "просто читатель" такого натренированного мышления не имеет -- он только компилирует, и еще сильно связан по времени. Но какую-то мысль на тему ваших "интерфейсов к форме" подумать можно. А unit test -- это "задачки к главе учебника". Это мы понимаем. Есть три (обычно неявных) части текста: Учебник, Задачник и Методпособие-по-инсталляции-целого. Обсуждается сейчас третья часть: насколько его можно отделить от собственно содержания. Ежели Методпособием служит учитель -- нет проблем, он будет задавать последовательность чтения гипертекста. Ежели методпособием служит сам текст, то -- приехали, никакие задачки-тесты не помогут ;)

>А unit test -- это "задачки к главе учебника". Это мы понимаем. Не понимаете, значит. Unit test - это проверка, что глава означает имено то, что она должна означать в соответствии с концепцией книги (реализует именно те интерфейсы и ту семантику, которая предполагалась). Т.е. это проверка результатов деятельности автора, а не читателя.

Дык это вы не понимаете: ваше "означает в соответствии с концепцией" -- это про компоненту Учебника (а не Задачника и не Методпособия). Это -- в конечном итоге -- контроль онтологии (содержания), как его кладут туда писатели (ежели их коллектив). А я сейчас говорю про последовательность загрузки содержания в бедную голову ученика, даже если это содержание писал один писатель. Эта последовательность загрузки нетривиальна, наука, которая ей занимается называется дидактика, в книжном мире управляется выстраиванием глав в последовательное изложение, а в гипертекстовом мире в этом месте формы одна большая сплошная дыра. Юнит-тесты вообще про другое, они про правильность юнитов и правильность их содержательной подстыковки. А меня не волнует в данном обсуждении, правильно или неправильно написан каждый отдельный кусочек, и правильно ли они подлинкованы по содержанию. Предполагается, что все правильно, не дураки же пишут! А если неправильно -- то это отдельная и другая история, тут нужно говорить о том, что такое "правильность содержания" и опять-таки упираться в онтологические разборки про стыковки текстов "про Фому" и "про Ерему", про "в огороде бузина" и "в киеве дядька". Меня волнует правильность в последовательности их предъявления, кто ее определяет, и как ее проверить. Насколько я понимаю, переструктурированность программ никто не проверяет -- а речь тут идет именно об этом (хотя переструктурированность в том числе затрагивает и онтологию: она вводит онтологические сущности без надобности). В современных средах любая подпрограмма доступна там, где она доступна. А вот в старых программных системах можно было раскладывать либо все подпрограммы в один файл, либо по три строчки каждой подпрограммы в один файл -- разбирался со связыванием объектного кода потом линкер, а связывание времени исполнения задавалось упоминанием имен в цепочке вызовов. В гипертекстах ничего этого нет, ибо "цепочка вызовов" должна быть не в голове ученика (тогда текст -- это справочник), а в голове преподавателя (или зафиксирована формой связи фрагментов текста -- параграфов в главу, а глав в книжку). "Бойся чертей аналогий". Мартин Лютер.

>Дык это вы не понимаете: ваше "означает в соответствии с концепцией" -- это про компоненту Учебника (а не Задачника и не Методпособия). Это -- в конечном итоге -- контроль онтологии (содержания), как его кладут туда писатели (ежели их коллектив). А я сейчас говорю про последовательность загрузки содержания в бедную голову ученика, даже если это содержание писал один писатель. Дык на самом деле непонимание взаимно. :) Возможно по моей вине, потому что я не довел аналогию до конца. Имеется в виду вот что: модульная программа, как и гипертекстоовая книга - она ведь нетривиальным образом разворачивается в последовательное исполнение ("чтение") программы процессором ("учеником"). При этом развертывании постоянно происходят переходы из модуля в модуль; как раз для того, чтобы при таких переходах не возникало проблем, и чтобы последовательность этих переходов легко можно было перестраивать (вплоть до развертывания одного и того же гипертекста в несколько разных книг) - для этого и придуманы интерфейсы. >Насколько я понимаю, переструктурированность программ никто не проверяет Смотря что вы понимаете под переструктурированностью. На самом деле, с программой есть одно отличие от гипертекста: когда мы попадаем в модуль, код модуля сам определяет последовательность дальнейшего развертывания; собственно именно это развертывание и есть семантика программного модуля. А в гипертексте содержание (семантика) и последовательность развертывания разделены, что - насколько я понимаю - и порождает половину проблемы, которую вы пытаетесь решить. Т.е., возможно, еще один источник непонимания - что я продолжал аналогию с кодом до конца и считал последовательность развертывания модуля (или, точнее, пространство возможных - применительно к тексту, осмысленных - последовательностей развертывания) частью его семантики, а вы - нет.

Я предлагаю выкинуть всю аналогию с программой -- ибо 1) написанную программу никто из людей не читает иначе как в справочных целях (т.е. гипертекстовое ее представление, когда ткнув в имя процедуры попадаешь на ее определение, является вполне осмысленным). Другое дело, как в программе показать ее архитектуру при чтении?! Даже справочном чтении? ;) 2) Исполнение программы процессором или сборку ее в исполняемый модуль из кусочков линкером вообще нельзя даже отдаленно рассматривать как процесс, аналогичный чтению текста учеником. 3) Текст книги читается один раз сверху вниз, а программа исполняется (и читается, замечу, тоже) -- кувырком в случайных местах. Ровно как гипертекст. То есть совершенно не наш случай. 4) Мы так долго будем доказывать, что программы -- это про другое, и как мы друг друга тут плохо понимаем, что не хватит времени обсудить возможные решения предложенной проблемы. Одно из решений я уже предложил: использовать не среды, привычные для писателей программ и способы работы, привычные для них, а использовать средства и способы работы, привычные для писателей книг.

> написанную программу никто из людей не читает иначе как в справочных целях Разработчики при отладке еще как читают. :) >Другое дело, как в программе показать ее архитектуру при чтении?! На то есть UML. Не идеальное решение, но в принципе проблема решаемая. >Текст книги читается один раз сверху вниз, а программа исполняется (и читается, замечу, тоже) -- кувырком в случайных местах. "читается сверху вниз" - в вашей же собственной терминологии означает, что задана определенная последовательность развертывания. Программа исполняется не кувырком в случайных местах, а развертывается в соответствии с семантикой. Разница только в том, что у книги последовательность развертывания одна, а у программы таких последовательностей бывает много, но в обоих случаях задание этой последовательности - часть (одна из важнейших частей) процесса разработки. >использовать не среды, привычные для писателей программ и способы работы, привычные для них, а использовать средства и способы работы, привычные для писателей книг. Так вот я и объясняю, чем это плохо: написать толпой большую программу - нетривиально и часто получается криво, но это возможно. Написать толпой большую книгу (именно книгу, т.е. связное изложение, а не справочник или сборник) - невозможно, именно в силу ограничений, налагаемых способом работы. Т.е. программистские методы работы по крайней мере в одном отношении интересны. Программистский же инструментарий - в том виде, в каком он есть сейчас - не годится, да, но так легко его отбрасывать не следует; надо хотя бы посмотреть, чего в нем не хватает, и подумать, коим образом можно обеспечить недостающее.

Это понятно, что имеющихся средств и технологии писательства не хватает для многих целей, иначе не заводил бы разговора вообще. Но программистский инструментарий я бы не брал как прототип и аналогию. Там своих тараканов и непоняток хватает. И, конечно, тексты программ и тексты книг -- это просто тексты. И я брал бы в рассмотрение системы работы с текстами, выкидывая вопросы их возможной автоматической интерпретации из рассмотрения. И вы все время путаете форму и содержание, хотя они и существенно связаны. Для описания содержания могут применяться спецификации-1 (тот же UML, онтологические языки). Для описания формы должны применяться спецификации-2 (разбивка строк текста по файлам -- чем описывается? Способ сборки этих файлов в единый текст -- чем описывается?). Ясно, что любая подобная задача решается введением метаданных, специфицирующих желаемые свойства -- в данном случае, описывающих маршрут сборки текста. Все, что я хочу -- чтобы эти метаданные я не вводил отдельно в окошечки специальной формочки. Я хочу, чтобы система выдирала их из моих действий с текстом сама, как Ворд выдирает из моих действий со стилями некоторых строк, которые я крашу под стили заголовков, понимание аутлайна. Нужна онтология писательства-читательства с точки зрения процесса, разворачивающегося во времени на пространстве экрана, а потом честная программная реализация этой "онтологии системы гиперкниготекста".

>И вы все время путаете форму и содержание, хотя они и существенно связаны. :) 1. Они существенно связаны, вы сами признаете 2. Мы говорим не столько о содержании, сколько о способе подачи содержания (книга vs. справочник), т.е. речь идет в первую очередь о форме или, еще точнее, о специфических аспектах формы. Опять же, программерская аналогия опасна тем, что у программы интерфейс - это неотъемлемая часть содержания, а на текст он накладывается искусственно, так что получается гипертекст и взгляд на связи модуля как на форму. Но как раз я-то о том и веду речь, что этот-то взгляд и плох, что на самом деле это (гипертекст) скорее часть содержания, чем форма. >спецификации-2 (разбивка строк текста по файлам -- чем описывается? Способ сборки этих файлов в единый текст -- чем описывается?). UML же. :) Только другими диаграммами. Ну и плюс раундтрип енжин, который должен обеспечивать синхронизацию UML с живым кодом - что нигде по человечески не сделано и откуда и проистекает большая часть проблем при программировании через UML. >Ясно, что любая подобная задача решается введением метаданных, специфицирующих желаемые свойства -- в данном случае, описывающих маршрут сборки текста. Все, что я хочу -- чтобы эти метаданные я не вводил отдельно в окошечки специальной формочки. Дык вот откуда и заголовок, почему я это и называю технократический подход: еще не поняв до конца, какие это должны быть метаданные и откуда они могут и должны браться, вы уже решаете, как вы их хотите (или не хотите) вводить. :) А вики - насколько я понимаю, вовсе не программистский инструментарий. :)

> Дык вот откуда и заголовок, почему я это и называю технократический подход: еще не поняв до конца, какие это должны быть метаданные и откуда они могут и должны браться, вы уже решаете, как вы их хотите (или не хотите) вводить. :) Вот, добрались. Да, я хочу решить сначала, как я хочу писать-читать, а уж затем этот процесс можно будет отмоделировать, чтобы понять, какие метаданные для содержания должны храниться и что нужно добавить к моему описанию читания-писания, чтобы не слишком искажая его принципы получить его технологическую поддержку. Да, сначала бизнес-процесс (глаголы, описание в сенсорно обусловленных терминах) -- потом проектирование структур данных к нему. Меня тут интересует сенсорная обусловленность, эксплуатация человеческого восприятия и учет особенностей психологии. Поэтому все сравнения с программами (особенно, когда слово "интерфейс" в программе означает и интерфейс писания кода программы, и интерфейс пользовательский собственно выполняющейся программы, и интерфейс читателя кода программы-дебаггера, и интерфейс "железного читателя"-процессора компьютера или виртуальной машины во много слоев таких интерфейсов) считаю неуместными. Я собираюсь поддерживать особенности человеческого восприятия -- инварианты по Джеймсу Гибсону. Я собираюсь заниматься сенсорной обусловленностью подобного интерфейса. Это движение в строну пси-интерфейсов проекта OpenMeta. А какие там метаданные вы мне расскажете сами после того, как я пойму, как человеку будет удобно -- но не наоборот, вы не будете предсказывать мне, как человеку будет удобно с такими или сякими метаданными.

>Да, я хочу решить сначала, как я хочу писать-читать, а уж затем этот процесс можно будет отмоделировать, чтобы понять, какие метаданные для содержания должны храниться и что нужно добавить к моему описанию читания-писания, чтобы не слишком искажая его принципы получить его технологическую поддержку. Да, сначала бизнес-процесс (глаголы, описание в сенсорно обусловленных терминах) -- потом проектирование структур данных к нему. Беру слова насчет технократического подхода назад. :) Проблема не в технократии, а в том, что вы смотрите только на одну часть бизнес-процесса: на бизнес-процесс со стороны автора. Это важная часть бизнес-процесса, но процесс-то на авторе не замыкается, автор ведь пишет хоть книжку, хоть гипертекст ради того, чтобы это потом читали. Поэтому, вполне возможно, нужды одного только автора процесс не покрывают и, возможно, ради читателя автору придется пойти на какие-то операции, которые сами по себе казались бы ему неудобными. :)

А вы читали мой исходный текст?! Я там настаивал как раз на том, что удобное автору написание ошметков с автоматическим склеиванием этих ошметков текста в гипертекст является головной болью для читателя. Тогда вы в чем меня обвиняете? Что я хочу облегчить писателям написание такого текста, который будет удобно читать? Так спорить неинтересно -- да и не о чем. Я не хочу изобретать что-нибудь с нуля, брать какой-нибудь далекий прототип. Я уже предложил некоторую онтологию, в терминах которой я буду решать проблему (и наметки к решению я даю в своих текстах). Либо вы соглашаетесь с моей постановкой задачи и онтологией, либо проблематизируете их -- но конструктивно, предлагая что-нибудь взамен. А так получается, что вы придираетесь к отдельным фразам, выдергивая их из контекста, меняете по ходу дела онтологию обсуждения, вводите какие-то новые концепты, не раскрывая, как они помогут в данной постановке задачи. Прочтите внимательно, обращая внимание на употребляемые мной термины, и задайтесь вопросом -- какая структура (модель) у меня в голове, ежели я все это написал, и считаю непротиворечивым. Эта модель у меня, безусловно, есть. Может, так станет проще понимать, почему я обращаю такое внимание на писательские процедуры -- ибо уже немного разобрался с читательскими процедурами (и даже учитываю navigational modes и разные veiw -- это же лежит на поверхности и не требует отдельного рассмотрения для тех, кто в теме), и почему я так против программерских аналогий с их дьявольским числом двусмысленностей и неопределенностей с самого начала. И не забывайте еще, что главным читателем является сам писатель (особенно, ежели писателей -- коллектив, _к которому не все писатели присоединяются с самого начала_).

unit test - это совсем не задачи к главе. Это задачи к автору главы, положительный ответ на которые означает, что она написана правильно.

Отступление: Вот, блин, Толя, если бы ты то же самое мог сказать втрое меньшим количеством слов, было бы чУдно. :) Потому как темы, вообще говоря, интересные, но продираться сквозь твои посты - это надо иметь много сил. :( По теме: лично я не уверен, что есть такая уж прямая связь между системным представлением и линейностью подачи информации. Лемма: человек, систематически представляющий себе область знания напишет про неё такой гипертекст, который позволит читателю систематически же её понять. Теперь представим, что лемма опровергнута и доказано, что только линейная подача есть способ достичь целостности в подаче материала. Допускаю. Но, с другой стороны, понятно же, что без декомпозиции и модульности всё равно нельзя - иначе большие материалы не делаются. Ну - знамо дело, это со школы: план сочинения, потом сочинение. Аутлайн. То есть: Дерево взамен графу. То есть - линеаризуем граф, изничтожая в нём кросслинки, оставляя только правило обхода лабиринта по левой руке. Знаешь, что в этой штуке проблемно? То, что, в отличие от гипера, она плохо ложится на структуру реальности. Реальность не одномерна ни в каких рамках. Чем ни ограничивай, всё равно внутри границ получится многомерное нечто. Описывать это одномерным текстом - это всегда делать проекцию, уплощать. То есть, я хочу сказать, ладно удобство писателя - гипер ценен не только мехом, но и бОльшим соответствием структуре этого мира. Хотя и не полным. По сути гипер - это просто бардак, отсутствие структуры - тем и плох. Не тем, что нелинеен, а тем, что дерево - это структура, это отношения, имеющие смысл. (Часть входит в целое и описывает его детали) Давай попробуем представить себе многомерное дерево. Пересекающиеся перпендикулярные плоскости, в каждой из которых - дерево. Некоторые листья разных деревьев или имеют связи, или, в другой модели, просто совпадают. Связи в рамках одного дерева запрещены. Плюсы: в рамках каждой плоскости есть структура, есть линеаризация. в целом есть многоплановость. Да - это гипер, но, вероятно, его можно читать как последовательность книг. С известной долей проблем (что после чего, циклы отсылок) - но это проблемы не представления, это проблемы РЕАЛЬНОСТИ. О, ещё лемма: наш мир по определению линейно непознаваем. (я уж молчу о том, что он вообще непознаваем, давайте пока об этом забудем.:)