Дилетантизм, господа хорошие!

Как только начал читать статью сразу наткнулся на странное утверждение. Авторам кажется, что быстродействие машин на пределе. Пришла пора оптимизации! Далее, буду цитировать: "Конечно, быстродействие машин возрастает, и слава Богу. Не надо только забывать, что оно уже близко к своему теоретическому пределу." На чем строится это утверждение? Закон Мура пока вроде бы еще не был нарушен, а быстродействие компьютеров продолжает увеличиваться. Что мешает собирать 32-х процессорные машины? Я бы сказал, что, наоборот, производительность современных процессоров излишне высока. Пользователь, который большую часть времени работает с офисными документами на процессоре Celeron 500 Мгц, использует максимум 30 % производительности машины! С этим отчасти связано и падение спроса на компьютеры. Даже Windows уже не способна настолько загрузить процессор, что это стало бы раздражать в работе.

Цитата: "Pentium уже давно представляет собой двухпроцессорный чип + FPU, гибрид RISC и CISC, а его система команд ничего, кроме священного трепета, не вызывает. Все, что касается hardware, действительно приносит все новые плоды, но с каждым годом все с большим скрипом." Вот мое мнение насчет системы команд x86. Она наверняка не оптимальна с машинной точки зрения. Но это "человечная" система команд. В ней скрыта некая красота, которая позволяет ее изучать и использовать человеку, программирующему на ассемблере. Разумеется, сейчас уже ничто не мешает создать процессоры с тысячей регистров и хитроумной системой обработки команд, фактически новые 64-разрядные процессоры Intel таковые и есть. Скоро-скоро появятся новые оптимизирующие компиляторы, которые будут для подобных "супер"-процессоров вырабатывать специальный машинный код, использующий преимущества механизма предикатов и параллельных вычислений. Но человеку на таком процессоре программировать уже не захочется. Можно сказать, что это естественный процесс развития технологий. Лично мне он не нравится. Ничего не могу с собой поделать.

Цитирую: "технология программирования все безнадежнее отстает от требований, которые к ней предъявляются. Если темпы компьютеризации останутся прежними, а программы так и будут писаться “на коленках” – рано или поздно все современное здание информационных технологий просто рассыплется в прах." Информационные технологии интенсивно развиваются. Неужели авторы статьи этого не замечают? Взять хотя бы эволюцию того же языка C в современный C++. Или появление платформы Ява. Можно еще перечислить: развитие интернет-технологий, средств проектирования приложений типа Rose Rational, развитие реляционных БД, развитие технологий "баз знаний" (OLAP) и пр. Благодаря прогрессу в этой области сложность современных информационных приложений выросла во много раз. Я не могу согласиться с утверждением авторов, что программы пишутся "на коленках". У программиста под рукой сейчас огромное число технологий и инструментов, выбор даже (на мой взгляд) слишком широк. Проблема в самом человеке. Как известно, "человеческий мозг со времен Аристотеля почти не изменился" ;) Современные технологии, как правило, очень сложны, вот в чем их недостаток! Они отражают сложности нашего мира, но требуют много времени на освоение. К тому же, как правило, приходится комбинировать несколько технологий между собой, а этому никто вообще не учит. А что касается надежности современных приложений, то, вообще-то, они гораздо надежнее приложений прошлых лет. Даже пресловутая проблема 2000 года и та оказалась фикцией. Люди учатся на своих ошибках, это естественно. Не вижу здесь повода для столь мрачного пессимизма, Утверждение, что "все рассыпается в прах" совершенно необъективно и ничем не подкрепляется.

Цитирую: "Мы обязаны переходить от самоделок к конвейеру, от ручного кодирования – к сборке программ из готовых элементов. Все движется в этом направлении!" Неужели авторам кажется, что они открыли Америку этим утверждением? От слов "сборка программ из компонент" у меня начинается мелкая дрожь. Любое программирование есть "сборка компонент"! Любое. Начиная от функции, которая сама по себе уже какая-то компонента с описанием параметров, способа вызова и возможностью повторного использования. И заканчивая классом в современном ООП с инкапсуляцией и пр. В Дельфи можно создать компонент, положить его на панель и одним щелчком добавлять в проект и использовать. DLL в Windows - это тоже компонент! Без труда можно получить точки входа и вызова библиотечных функций. Технология COM использует соглашения об интерфейсах компонент, а их реализация произвольна. Можно сказать, что стандартная библиотека языка C - это тоже компоненты. Компоненты ActiveX можно внедрить в любое офисное приложение. Компоненты повсюду, вопрос в том, как их интегрировать? Как добиться управляемости проекта, когда он собирается их тысячи подобных компонент? Какими методами необходимо пользоваться, чтобы найти ошибку и разобраться в неверном поведении проекта, который использует сложное взаимодействие компонент, основанное на событийной модели? Можно ли вообще добиться правильной работы программы, которая использует компоненту "черный ящик"? Мое мнение, кстати, - нельзя. Зная алгоритмы внутренней работы класса или имея его исходники, всегда проще понять как его использовать и предсказать его поведение. Все это тысячелетие и немного от прошлого ;) программисты создают и пользуются компонентами. Замечу в скобках, что все эти компоненты - самодельные. Других просто не бывает.

Далее авторы описывают революционную систему Флора. Здесь для понимания сути попробуем перевести авторские термины на русский язык :) То что, авторы называет "контактами" объекта принято называть их интерфейсами. Это соглашения о способах работы с объектами. "Рефлексы" объекта - это обработчики событий. В общем, если отбросить мудреность, система Флора - это многопользовательская иерархическая база объектов с данными, позволяющая хранить еще и код (те же обработчики событий). Здесь сразу необходимо отметить некоторые моменты. Во-первых, хранение данных в многопользовательском режиме доступа накладывает определенные обязательства. Это транзакционная модель изменения данных, протоколирование изменений, средства восстановления поврежденных баз данных и пр. Не думаю, что в части транзакционной модели Флора может тягаться с современными БД. Не уверен, что вообще во Флоре есть понятие транзакция, в статье почему-то об этом - ни слова, а ставить саму Флору пока не хочется. Во-вторых, все возможности Флоры имеются в современных реляционных базах данных. Тот же Oracle умеет хранить и объекты, и методы объектов (написанные на языке Ява). Наконец, иерархическая организация данных - довольно тонка штука. Она, как правило, хорошо отражает предметную область, но работать с ней обычно непросто, слишком гибкая. Реляционная база данных предлагает, даже навязывает, программисту некую стандартизацию данных. Это связывает нас по рукам, но упрощает программирование. При правильном проектировании БД и хорошем анализе все обычно заканчивается удачно. Иерархия - очень "скользкая" штука, утверждаю это на собственном опыте. Можно сказать, что иерархическая структура данных (в отличие от реляционной) не решает проблем стандартизации, она откладывает их "на потом", затрудняя создание и сопровождение кода. Кому-то это может нравиться, лично мне - нет. Ситуацию усложняет и то обстоятельство, что во Флоре объекты не имеют типов, то есть совершенно не стандартизированы (за исключением их интерфейсов). Факты - упрямая штука. Широкое распространение в информационной индустрии получили именно реляционные базы данных, что не в последнюю очередь связано со стандартизацией форматов данных и языка работы с ними (SQL). Не так уж много слышно про системы использующие другие системы БД (сетевые, множественные, иерархические).

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

Цитата: "Нет во Флоре отладки! Как только ты что-то изменил – видишь это немедленно" Ну что право за ерунда? Мы же все здесь серьезные (чисто конкретно!) люди. Что "видишь немедленно"? Если речь идет об изменениях полей объектов, то бишь изменении данных, то я просто теряюсь. Непонятно, что тут вообще обсуждать. А если речь идет об изменении кода - чур меня! Не хочу я, чтобы как в Визуальном Бейсике при переходе на следующую строчку система меня пригоняла обратно на предыдущую, тыкала носом и говорила "ошибочка, тут у тебя"! Да знаю я, что она там! Я хочу, чтобы она там была! Чтобы потом я заметил, вернулся и дополнил, но потом, а не сейчас! Никто не создает программы от первого до последнего слова, процесс программирования нелинейный ("сказал он, оглядывая стенки сумасшедшего дома"). Нельзя наблюдать разработку сложного алгоритма! Не вырастает из яйца птенец здесь! Сначала долго и кропотливо пишется код. Затем он десять раз проверяется по частям. Затем начинаются попытки его свести вместе. В нужные моменты времени программист запускает программу и видит результат. Если все это называется не отладкой, Билл Гейтс - полуостров в Средиземном море.

Далее, межплатформенность Флоры - это здОрово, без дураков. Интерпретация кода, единая среда исполнения. ЗдОрово. Но Ява-то чем хуже? Или тот же SQL? Современные средства программирования дают программисту громадный набор инструментов и, вообще говоря, эффективней всего тот, к которому программист привык. Я абсолютно убежден в этом. Нету здесь "серебряной пули", которая решит все ваши проблемы! Есть набор готовых библиотек, компонент, объектов, которыми надо учиться пользоваться. Хорошо владеющий инструментарием программист напишет на нем все что угодно. Читайте книги. Там сказано, что "функционал сам по себе еще не является преимуществом. Преимущество имеют простота в сочетании с функционалом." Не уверен в точности цитаты Брукса, но уверен в ее правоте! Я бы добавил в нее еще и насчет необходимости масштабируемости системы.

Теперь процитирую вывод в конце статьи: "Так вот: программисты – следующие в очереди по той же причине: человечество не может себе позволить превратиться в общество программистов. И технология “почти без программирования” – это шаг в правильном направлении: к технологии “без программирования”, а затем и “без программиста”. Думается, что в этом плане у системы Флора – большое будущее." Господа авторы! Ну неужели так трудно не скатываться до банальностей и подобного бреда? Общество не может позволить себе обойтись без профессионалов. В любой области. Профессионалов. Хороший инструмент - это здорово, конечно. Но многое, очень многое зависит от возможностей человека. Когда у автора этой статьи заболит зуб, следуя его выводу, ему достаточно собрать из готовых компонент хорошее зубоврачебное кресло, поставить необходимый инструмент и попросить своего ближайшего друга (соседа по этажу, партнера по теннису, коллегу по работе, нужное подчеркнуть) поставить пломбу. Желаю также воспользоваться этим методом всем сотрудникам Терры, когда нужно будет сделать ремонт или, скажем, провести паровое отопление. К чему профессионализм? Берите готовые компоненты и сами с богом вперед в светлое будущее! Вместе с кухаркой, которая будет всем этим делом управлять.

Цитировать больше нечего. Дилетантизм, господа хорошие! Столько воды и безосновательных утверждений! Ведь Флора, похоже, содержит интересные идеи. Например, во многих крупных приложениях на языке Ява сейчас используется некий промежуточный слой, который отображает эти объекты в записи реляционной базы данных. То есть, создавая подобный объект, мы, тем самым, "даруем ему жизнь вечную" до того момента, как его специально удалят. Флора базируется на подобной идее и это неплохо. Судя по концепции хранения данных в виде объектов в БД, во Флоре должен существовать механизм очистки мусора. Интересно было бы узнать о возможностях языка программирования и пр. Обо всем этом авторы умалчивают, вместо этого подвергая несколько странной критике язык C++. Хотя в любом случае за статью спасибо. Было очень приятно узнать, что у нас в стране кто-то занимается подобными разработками на подобном уровне.

Григорий Григоренко,
программист компании Атон