Следствие 1. Очевидно, что основным направлением развития проективных систем будет создание все более мощных инструментариев, то есть наборов, позволяющих сравнительно быстро и эффективно строить решения задач в различных прикладных областях. Для программистов, например, это высокоуровневые библиотеки функций, специализированные модули языков программирования высокого уровня и сами эти языки. Разнообразие инструментов не нарушает принцип У: вряд ли программисту придется использовать их все сразу. Скорее всего, он, сообразуясь с профилем решаемых задач и стилем работы, подберет небольшой, но мощный подходящий инструментарий. Для разработки больших проектов, которые должны "уметь все", программист выберет высокоуровневую среду, где ему придется иметь дело с более сложными, но умопостижимыми объектами, при необходимости спускаясь на более низкий уровень. (Обычно в названии таких сред встречается слово toolkit - "инструментарий". Показательно, не правда ли?)
Следствие 2. Велосипедный парк. Некоторое количество (подчас изрядное) готовых решений придется собрать, что называется, своими руками, чтобы потом этими решениями пользоваться. И спустя какое-то время вы убедитесь, что занимались изобретением велосипеда - существуют инструменты более полные и, возможно, более удобные, чем ваш. Тут следует помнить четыре вещи. Во-первых, опыт и знание в проективной системе важнее конкретной поделки, так что ваши усилия не пропадут даром. Во-вторых, если не предвидится задач, которые ваша библиотека не решает, а чужая - решает, лучше оставить все как есть . В-третьих, когда чужая разработка объективно лучше, а задачи все прибывают, следует перейти на нее, если к тому нет формальных препятствий (лицензия, полная несовместимость и пр.). Лучше совместно совершенствовать мотоцикл, чем порознь пыхтеть над велосипедами. И в-четвертых, когда в следующий раз приметесь изобретать велосипед, оглядитесь вокруг в поисках готовых мотоциклов, то есть поищите подходящий для ваших задач инструментарий (например, на www.sourceforge.net или www.freshmeat.org).
Достоинства проективной системы - прямые следствия принципов ее организации. Многие из них уже упомянуты нами: свобода ориентации и возможность совершенствоваться - раз. Возможность, придумав и реализовав решение, оставить машину работать, а самому заняться новыми делами - два. Реакция проективной системы даже на самую нештатную ситуацию прогнозируема, потому что для прогноза нужно вдумчиво проанализировать проект, а он умопостижим (хотя предсказать, что в точности случится, нельзя). Сами нештатные ситуации воспроизводимы, так как состояние системы целиком описывается ее проектом плюс входным потоком данных, значит, легко обнаруживать узкие места и несообразности и устранять их. Проективные системы можно использовать для решения практически любых задач, дело только за временем, которое потребуется на осуществление решения.
Недостатки проективной системы тоже суть прямые следствия принципов ее реализации. Во-первых, много времени может потребоваться на ее освоение, причем чем больше человек делает в системе, тем выше должна быть его квалификация; а за обучение, как и за квалификацию, надо платить. И вот за свои деньги мы получаем человека, который много всего знает и много о себе думает, отказывается выполнять приказы, спорит, отсутствует на рабочем месте и т. п. - словом, ведет себя как творческая личность, а не как исполнительный сотрудник. Что поделать! Принцип О предполагает, что каждый делает свое дело с полной ответственностью и принимает решения сам. А если ответственности нет, творческий коллектив немедленно превращается в богему. Это во-вторых.
В-третьих, даже самые стандартные задачи проективная система выполняет всякий раз по-новому, потому что в ней заданы только параметры операций, а не сами операции (так, например, нельзя в точности предсказать, когда именно будет отослано из локальной очереди письмо, но это будет сделано обязательно). В-четвертых, количество циклов тестирование-отладка, которые придется пройти системе, прежде чем продукт ее будет признан качественным, зависит от опыта пользователя и строгости требований к продукту. В неудачных случаях задача так и остается нерешенной, гарантии решения нет никакой - кроме персональной гарантии самого пользователя и принципиальной разрешимости задачи.
У принципа информационной открытости компьютерных человеко-машинных систем есть еще одно немаловажное следствие. Основной инструмент такой системы - программа или библиотека. Самый надежный источник информации о нем - исходный текст на языке программирования. Более того, только если программа доступна пользователю в виде исходного текста, он может находить в ней ошибки, исправлять и развивать ее. Такую программу разрабатывает и отлаживает весь мир, точнее, все сообщество квалифицированных пользователей. Только доступ к исходному тексту программы гарантирует отсутствие в ней "вредоносных" частей (см. УК РФ, статья 273 и комментарии к ней).
Если исходные тексты программного продукта недоступны, это бьет сразу по всем принципам организации проективной системы. Во-первых, это нарушение принципа И. Во-вторых, это сильно ограничивает О, так как затрудняет (а чаще всего - запрещает!) изменение продукта. Даже обладая достаточными знаниями и будучи совершенно уверенным в своей правоте, человек не сможет решить задачу, связанную с доработкой инструмента. Для этого придется выдумывать дополнительное информационно открытое пространство внутри инструмента (например, дополнительно встроенный язык программирования). Мало того, что умножение сущностей противоречит У, само это синтетическое пространство будет основано на легенде об инструменте (см. лекцию 3), а не на действительной его структуре. При этом даже самое незначительное изменение свойств продукта может вылиться в дублирование этих свойств на "внутреннем языке", а тогда о З и говорить не приходится.
Процедура как суррогат поступка
Процедурной мы будем называть человеко-машинную систему, доступную человеку в виде набора функций (процедур) внутри прикладной области, описываемых в терминах прикладной области и приводящих к наглядному или гарантированному изменению свойств объекта. Например, человеко-телевизор - полностью процедурная система: все задачи, которые ставит перед ней человек, описываются в терминах "программа", "громкость", "контраст" и т. п. Телевизор же (вернее, инструкция к нему) общается с пользователем на том же языке (кажется, в нем есть только один новый термин - "кнопка", все остальные, включая названия кнопок, повторяют известное пользователю).
Система в самом общем виде работает так: человек описывает, какой продукт он хочет получить, а машина рассказывает, какие действия надо для этого предпринять. Естественно, возможны варианты: часто человек не в состоянии вспомнить все свойства продукта, и машине приходится потихоньку выспрашивать их; так, например, устроен, "мастер подключения к Internet" в Windows 98 и прочие подобные ему "мастера" (wizards). Почти всегда стадия "какие действия предпринимать" этими мастерами и ограничивается: после того, как свойства продукта описаны, задачу уже можно решить, не посвящая пользователя в тонкости решения. Наконец (отличительная особенность процедурных систем!), под типовую пользовательскую задачу, скорее всего, найдется готовый вариант решения, так что пользователю останется только нажать кнопку, скажем, "форматировать текст" и наслаждаться результатом.
Существует некое предписание, или свод правил, согласно которому человек тянет за те или иные рычаги системы и получает на выходе определенные свойства продукта. Очень часто в роли предписания выступает инструкция по эксплуатации, или так называемый troubleshoot: вещи выходят недостиранными - кладите больше порошка, при работе слышен скрежет, а на вещах заметен известковый осадок - используйте средство против накипи, не гудит и не крутится - проверьте предохранитель, не поможет - включите вилку в другую розетку, если и это не поможет - звоните в службу ремонта. Предписания, составленные по принципу "совокупность признаков - действие", назовем табличными, потому что они обычно оформляются в виде двух колонок. Табличные предписания удобны, но практически всегда недостаточны. Если существует полностью задаваемая табличным предписанием человеко-машинная система, рано или поздно она становится автоматической, потому что выполнять процедуры из таблицы вполне под силу автомату, человек для этого не нужен. Системы кондиционирования, поддерживающие постоянную температуру и влажность в помещении, не нуждаются в человеке, который, глядя на градусник, дергал бы за ручку "холодно-жарко".
Поэтому в действительных системах предписание, скорее всего, будет неформальным. Неформальное предписание - это понятный пользователю текст, на основании которого он в некоторых ситуациях почувствует необходимость выполнить в системе определенные действия. Четкость, однозначность и полнота такого предписания, равно как и средства, вызывающие у пользователя желание действовать, остаются целиком на совести его составителей. Чаще всего в таких предписаниях ситуация описывается лишь приблизительно, сами рекомендации имеют вид доброго совета, а эффект применения слегка преувеличен. К примеру: "Если вам кажется, что с вашим диском что-то не в порядке, запустите программу проверки диска, которая быстро и эффективно устраняет все проблемы с диском". По сути дела, любое предписание, обещающее изменить не конкретное свойство объекта, а группу его свойств или объект в целом, неформально, так предполагает некий компромисс, допущение того, что действительный объект совпадает с заданным в предписании и что пользователю нужны именно те свойства, которые в результате у объекта появятся. К классу неформальных предписаний следует отнести и "интуитивно понятный интерфейс", раз уж создатели его уверяют, будто им можно пользоваться, не понимая до конца, что именно происходит.