`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Такая простая бездна...

0 
 

Продолжая публикацию архивных материалов, предлагаем вашему вниманию статью из № 5 (274) «Компьютерного Обозрения» от 14 февраля. Каким должен быть идеальный текстовый редактор.

Трудно говорить о вещах простых и приземленных на фоне событий эпохального значения. Казалось бы, кому может быть интересен... простой редактор текста, когда для написания заметки в десять строк совершенно естественным и современным кажется использование многомегабайтового текстового процессора.

Но, как говорится, «в тихом омуте...». «Простой и хороший» текстовый редактор, оказывается, далеко не так прост, а если заинтересоваться и хорошенько задуматься, то «вдруг» выясняется, что за понятиями «простоты» и «качества» кроются совершенно неисследованные глубины. Последний тезис полностью подтверждается практикой — существует масса теоретических монографий, практических руководств, справочников и отчетов о НИР/НИОКР, отражающих «достижения мысли» в самых сложных областях компьютинга. Но вот отыскать теоретический или практический материал, посвященный «обычным» текстовым редакторам, исключительно непросто — потому что такого материала нет. Точнее, почти нет — за два года интенсивного Web-серфинга автору удалось отыскать... всего один отчет о НИР и одну ссылку на весьма редкую книгу.

О ЧЕМ И ПОЧЕМУ

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

Теперь наступило время ответить на естественно возникший после прочтения предыдущего абзаца вопрос «А о чем же будет статья?». Что ж, расставим точки над «i» — речь пойдет о том, что «умно» и неопределенно называется «программной архитектурой». А именно, о программной архитектуре текстовых редакторов. И даже если вы не программист, заглянуть «внутрь» целого класса крайне необходимых программ вам будет интересно. И не страшно — здесь не встретятся слова «очевидно» или «понятно», за которыми кроются вещи совсем неочевидные и непонятные (по крайней мере, автор на это надеется).

А теперь затянувшееся вступление пора завершить самым главным — мотивацией. Почему именно текстовые редакторы, а не более «серьезные» пакеты, обладающие массой «важных» потребительских функций? И наконец, почему в предыдущем предложении так много кавычек? Подробно, но немногословно, ответить даже на эти вопросы слишком трудно, однако... Возможно, что высказывание «лучше один раз увидеть...» и справедливо, но один раз «написанное пером...» все же кажется более убедительным. А если серьезно, то несмотря на все «e-модные» и мультимедийные веяния письменность не только в какой-то мере отличает нас от других животных, но и остается единственным приемлемым способом общения с порожденными нами же компьютерами. И, что главное, — в стремительно растущем и сегментирующемся мире компьютерных коммуникаций самым надежным и безопасным способом общения и обмена данными остается plain text.

КЛАССИФИКАЦИЯ

Прежде чем «провести вскрытие», логично познакомиться с «пациентом». И здесь мы сразу сталкиваемся с открывающейся бездной: фактически никакой классификации текстовых редакторов не существует. Вместо этого есть множество несовпадающих точек зрения множества людей и, соответственно, неопределенность, усиленная слишком большим количеством условностей.

«Классификационные примитивисты» ограничиваются разделением всех бесчисленных существовавших, существующих и разрабатываемых редакторов всего на две категории — «с графическим интерфейсом» и, условно говоря, «неграфические». Сторонники «механистического» подхода делят редакторы на командно-ориентированные (с четко разграниченными режимами ввода текста и управляющих команд и очень простым механизмом переключения между режимами) и интерактивные (где режим ввода команд «спрятан» за условно именуемыми «дружественными» пользовательскими интерфейсами). «Функционалисты» выделяют класс «пользовательских» редакторов (их функциональность определяется строго заданным, пусть сколь угодно большим, но ограниченным множеством возможностей, заложенным в разработку производителем) и «концептуальных оболочек», фактически представляющих собой «компьютер в компьютере», функциональность которых ограничена разве что воображением, уровнем знаний и трудоспособностью их пользователей. «Метрологи» предпочитают классификацию, основанную на «точных цифрах» — максимальном размере редактируемого текста (например, десятки мегабайт — и не надо удивляться, есть категория людей, кому такая возможность действительно нужна) и быстродействии выполнения характерных для задач редактирования операций (вставка/замена/удаление фрагментов текста). «Концептуальные модернисты» придерживаются радикальных взглядов — в их терминах любой текстовый редактор или «старье и хлам», или «крутая фича». Близкие к последним по терминологии «технологи» больше всего обеспокоены, естественно, «передовитостью» используемых в том или ином редакторе программных технологий — их интересует только то, что основано на компонентных брокерах и «единственно правильных» методологиях программирования.

В кратком экскурсе в дебри классификации «за кадром» остались самые главные участники столь увлекательного процесса, которым принадлежит право вердикта. Это мы с вами, пользователи, точно определяем, какой текстовый редактор действительно «хороший» и «удобный», и подтверждаем свой выбор приверженностью. Именно по этой причине не только не теряют популярности одновременно прекрасные и ужасные разработки, такие, как vi, Emacs и Xedit (это, пожалуй, самые одиозные «фигуры» в мире текстовых редакторов), — они развиваются, совершенствуются и давно перешагнули границы своих «родных» платформ Unix и IBM VM/CMS.

ВЗГЛЯД В ПРОПАСТЬ

Употребленный выше термин «программная архитектура» имеет множество толкований. Поэтому вместо попыток разобраться в еще одной бездне воспользуемся подсказкой классика — Никласа Вирта: «Программы = Алгоритмы + Структуры данных» и будем считать «архитектурой» структуру взаимодействия двух этих главных элементов программной конструкции.

Основа основ любого текстового редактора — определенным образом организованные фрагмент или фрагменты оперативной памяти компьютера, обеспечивающие эффективное выполнение ряда весьма специфических операций. Собственно организация указанных фрагментов памяти называется структурой данных, а операции — как раз и есть «приземленные» до понятного машине уровня алгоритмы. В современной терминологии объединение этих двух понятий принято называть Абстрактным Типом Данных (АТД) — несмотря на «страшный» термин, АТД на деле означает всего лишь некоторый фрагмент памяти определенной организации, доступный «извне» исключительно с помощью строго ограниченного перечня «овеществленных» алгоритмов. Высокоуровневая абстракция АТД на практике оказывается очень полезной — невозможность изменить состояние фрагмента памяти никаким иным способом, кроме как использованием точно известной реализации алгоритма, позволяет локализовать ошибки («неправильное» состояние данных означает неправильность исключительно «привязанных» к ним реализаций алгоритмов, что в больших проектах астрономически сокращает область поиска «виновника происшествия») и облегчает понимание архитектуры программ.

Такая простая бездна...

Итак, главнейший элемент редактора — АТД с очень простым названием «последовательность символов», ведь именно последовательностью символов и является любой редактируемый текст. Разнообразные АТД, благодаря которым можно достаточно эффективно работать с такими данными, на первый взгляд, очень хорошо изучены. Им уделено много внимания в теоретических работах (например, в классических книгах Н. Вирта, Д. Кнута, А. Ахо), существует множество их программных реализаций. Но... все это относится к АТД «последовательность символов вообще» и практически никогда не отражает специфику задач редактирования текста. А такая специфика есть — хороший текстовый редактор должен одновременно «уметь» и быстро искать в неструктурированной информации (какая же структура у «чистого текста») фрагменты текста, совпадающие с некоторым образом заданными шаблонами, и быстро выполнять операции вставки/удаления без ограничений на размеры редактируемого и добавляемого/удаляемого текста. Эти два критерия одновременно являются критериями и оценки эффективности того или иного АТД, и проектирования — они определяют те самые алгоритмы, овеществления которых обладают исключительным правом доступа к главной структуре данных любого текстового редактора. С подходящей для практических нужд степенью детализации множество низкоуровневых, необходимых для редактирования операций можно описать очень компактно:

вставить_символ_на_указанную_позицию_в_последовательность; удалить_символ_на_указанной_позиции_из_последовательности; прочитать_символ_на_указанной_позиции_в_последовательности.

Найти одно-единственное решение, наилучшее по критериям эффективности всех трех этих операций, практически невозможно. Впрочем, знание этого факта нисколько не мешает и теоретикам computer science, и практикующим программистам создавать новые эффективные АТД, подходящие для построения текстовых редакторов, что подтверждается многообразием известных АТД «последовательность символов».

Не претендующая на строгость представленная классификация четко разделяет два основных класса АТД по признаку упорядоченности — отсутствие структуры у «чистого текста» не означает отсутствие упорядоченности. И два класса («естественного» и «искусственного») порядков достаточно точно соответствуют действительности — в первом случае порядок определяется на основе самой последовательности символов (отражающей порядок их ввода), во втором для упорядочения создается дополнительная информация, отсутствующая в plain text.

Не погружаясь «в глубины» низкоуровневых описаний каждого из АТД (в рамках статьи это нецелесообразно — в конце концов, заинтересовавшиеся читатели могут отыскать подробные описания таких конструкций в книгах упомянутых выше авторов), сконцентрируемся на главном — на показателях, характеризующих пригодность этих АТД для создания текстового редактора. АТД на основе структуры данных «массив» характеризуются очень высокой скоростью чтения символа из указанной позиции, исключительной простотой реализации, малым расходом памяти, но катастрофически неэффективны при выполнении главных операций — вставки и удаления символов. АТД, основанные на структуре данных «gap», являются незначительным технологическим усовершенствованием АТД на базе массивов и характеризуются неожиданно высокой эффективностью фактически по всем показателям. АТД на основе списков также хороши по всем показателям, но слишком неэкономно расходуют оперативную память. АТД из класса упорядоченных по «синтетическим» атрибутам используются на практике очень редко, несмотря на достаточно высокие показатели быстродействия изза очень высоких запросов к памяти компьютера. Наиболее перспективны современные АТД, базирующиеся на структурах данных «таблицы кусочков» (piece tables), и «буферы фиксированного размера» (fixed size buffers) — они выгодно отличаются хорошими показателями быстродействия всех главных операций, скромными требованиями к памяти компьютера и относительно несложной реализацией. Увы, современные АТД крайне редко используются на практике — анализ исходных текстов более чем двадцати очень неплохих свободно распространяемых текстовых редакторов (как для ОС Unix, так и MS Windows), проведенный автором, показал, что в подавляющем большинстве случаев разработчики применяют gap-АТД.

КЛАВИШИ И АВТОМАТЫ

На уровне абстракции «последовательности символов» (где все оказалось так сложно) существует еще один АТД, который авторами большинства текстовых редакторов «размазывается» чуть ли не по всей реализации, что значительно снижает потребительские качества созданного программного продукта. Речь идет о достаточно примитивном, но очень важном автомате, обеспечивающем интерактивность, — «командующем» АТД последовательности символов и более высокоуровневыми подсистемами редактора. Его можно назвать «ассоциатором», и именно он отвечает за преобразование сигналов от клавиатуры и указательного устройства (мыши, светового пера и даже распознавателя голосовых команд, если такой существует) в перемещения указателя текущей позиции в последовательности символов (курсора) и инициализацию операций вставки/удаления символов.

Такая простая бездна...

Ассоциатор — самый слабоопределенный элемент архитектуры текстовых редакторов, а очень жаль. Именно от его особенностей и возможностей зависит приспособленность редактора и к интернационализации, и к расширению функциональности, и, наконец, к кросс-платформенности.

Структуры данных, на которых строится АТД ассоциатора, фактически представляют собой таблицы. Для действительно хорошей программной конструкции их должно быть как минимум три: таблица соответствий кодов (ТСК), выдаваемых устройствами ввода, внутренним кодам, принятым разработчиком за «стандарт»; таблица соответствий символов (ТСС), преобразующая внутренние коды в коды символов, и таблица соответствий операций (ТСО), в которой некоторым кодам клавиш или их комбинаций ставятся в соответствие инициализации операций самого ассоциатора или более высокоуровневого компонента — встроенной виртуальной машины (о ней — далее). Такое скрупулезное «разделение обязанностей» на самом деле не является излишеством — ТСК обеспечивает мобильность редактора за счет минимальной зависимости от операционной системы, ТСС отвечает за гибкость интернационализации, ТСО позволяет расширять функциональность чуть ли не до бесконечности. Перечень операций АТД ассоциатора предельно краток:

загрузить_таблицу_ТСК;
загрузить_таблицу_ТСС;
загрузить_таблицу_ТСО.

Но, как говорится, «все гениальное — просто». Динамическая (в ходе редактирования) смена контекста ТСО позволяет изменять функциональность редактора буквально от буквы к букве, а замена ТСС эквивалентна переключению на редактирование в другом языке.

Увы, в большинстве текстовых редакторов АТД ассоциатора в явном виде не присутствует. Но о его существовании свидетельствуют многочисленные возможности, отличающие действительно хорошую конструкцию от просто поделки. Так, и условно попадающий в категорию текстовых редакторов MS Word, и канонический Emacs обладают способностью ассоциировать с клавишей «пробел» различные действия. Правда, в MS Word эта возможность ограничена жестко «вшитыми» действиями, а в Emacs за полноценное использование расширяемости приходится платить необходимостью тщательного изучения слишком сложного для таких простых действий подмножества языка Lisp. А клавиша «пробел» на самом деле является одной из «главных клавиш» — ассоциированные с ней функции позволяют элементарно реализовать и проверку орфографии, и синтаксически-управляемое редактирование, превращающее текстовый редактор в мощный инструмент.

ИСПОЛНИТЕЛЬ

Такая простая бездна...

На более высоком уровне абстракции находится АТД виртуальной машины. Эта подсистема фактически «отвечает за все» и присутствует в том или ином виде в любой серьезной разработке. В MS Word глубоко спрятана виртуальная машина, выполняющая скрипты VBA, а Emacs вообще представляет собой виртуальную машину Lisp. Увы, модели «исключительной роли» (Emacs) и «дополнений» (MS Word) в рамках ограниченной языковой среды не кажутся оптимальными — ведь у пользователей есть свои предпочтения, опыт и знания, и всегда не хватает времени на изучение «еще одного встроенного языка». Именно по этой причине АТД виртуальной машины должен быть тем, чем он должен быть — только виртуальной машиной, в системе команд обязаны присутствовать инициализации (вызовы) операций практически всех АТД редактора. На эту роль на сегодняшний день может претендовать виртуальная машина Java — ведь для нее существует масса трансляторов с самых разных языков программирования. Множество операций АТД виртуальной машины состоит... из одного-единственного описания:

ВИЗУАЛИЗАТОР

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

Такая простая бездна...

АТД визуализатора играет роль фактически проекторапреобразователя, трансформирующего фрагмент последовательности символов в изображение, пригодное к отображению на экране. В основе этого АТД лежит тип данных «таблица», в ячейках которой размещаются графические изображения символов. Еще одна таблица может использоваться в действительно хороших программах для изменения кодов символов из одной кодировки в другую, что обусловлено не столько спецификой, скажем, компьютеризации русского языка (для него существует сразу несколько кодировок), сколько несоответствием между возможностями универсальной кодировки Unicode и качеством/наличием Unicode-шрифтов. Увы, ни в одном текстовом редакторе реализации подобной возможности нет, а жаль — такой «маленький» архитектурный недостаток существенно сказывается на популярности и распространенности Unicode.

PR-МЕНЕДЖЕР

В организационных структурах для общения с «внешним миром» предусмотрена специальная должность — Public Relation менеджер. Хорошая программная структура не способна существовать без «внешнего мира», более того, ее «общительность» — первый признак высокого класса проектирования и гарант возможности расширения функциональности без потери надежности. Например, хороший текстовый редактор не должен содержать встроенный корректор орфографии — зачем усложнять и без того непростую конструкцию. Но для того чтобы быть «хорошим», он обязан иметь возможность ассоциировать с клавишей «пробел» простейший скрипт, написанный на любом, удобном для пользователя языке, считывающий введенное перед нажатием пробела слово и отправляющий его PRменеджеру с указанием «передать программе проверки правописания и вернуть результат». Где выполняется адресат этого послания, под управлением какой ОС и на какой машине — это уже забота PR-менеджера. В некоторых реализациях текстовых редакторов, считающихся экзотичными, разработчики сочли подобную «должность» настолько важной, что ввели еще одну абстракцию — «секретаря», содержащую собственную виртуальную машину для пред- и постобработки фрагментов текста, участвующих в процессе «общения».

Такая простая бездна...

К сожалению, в большинстве реальных редакторов АТД PR-менеджера вообще не используется, или же не выделен в нечто осязаемое. Его отсутствие обычно компенсируется поддержкой ОС, что, мягко говоря, представляет собой неэквивалентную замену и ограничивает мобильность. А модная в последнее время тенденция «строить все» на основе технологии объектных брокеров (даже то, для чего эта технология совершенно не нужна) приводит к тому, что... текстовые редакторы становятся все хуже и хуже и отличаются друг от друга исключительно размещением элементов пользовательского интерфейса.

ГДЕ ВЫ ТЕПЕРЬ?..

Идеализированная картина, представленная в статье, увы, не имеет реального воплощения. Это, скорее, попытка осмысления опыта, приобретенного в ходе изучения возможностей и особенностей реализаций различных текстовых редакторов и ряда документов из области «чистого компьютинга». К сожалению, с опытом пришла и скорбь — так, качество исполнения большинства «модерных» разработок не выдерживает никакой критики, функциональность современных текстовых редакторов постепенно сокращается до минимального набора возможностей Notepad, полноценная интернационализация остается проблемой No 1, разработчики концентрируются больше на ресурсоемких визуальных эффектах, чем на концепциях и возможностях. И наконец, самое неприятное — многим почему-то кажется, что текстовый редактор не нужен, потому что есть текстовые процессоры.

Защита промышленных сетей: основные риски и сценарии атак

0 
 

Напечатать Отправить другу

Читайте также

Все накушались МЕТА-клавиЩ Емакса?
Так вот, вот вам MS Code и не телеграфируйте нормальным людям мозги.

ИБМ знали толк в клавиатурах и сочетаниях клавиЩ!

 
 

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT