Компактное программирование |
С сайта membrana.ru :
Из дискусии на компютерном форуме, затеянной анонимным автором.18 октября 2005 г.
"Всё нет так ребята, всё не так!". Когда начинаешь анализировать, что же не так, то получается, что, для того, чтобы сделать "как надо" систему исполнения, надо изменить систему программирования, а для этого систему проектирования, а для этого и всего предыдущего - также и ОС. В общем, вроде менять надо всё. То есть, как мне кажется, наступает кризис основ, парадигмы программирования.
Часть 2. Кризис.
Как я уже говорил, последние десятилетия в программировании наблюдается полнейший застой. Это свидетельствует о приближении кризиса.
Это кризис системный, кризис парадигмы.
Потому, что это кризис основ, нет каких-либо конкретных, очевидных его проявлений. А те, на которые при желании можно обратить внимание, успешно драпируются указанными в предыдущей части псевдоноваторской деятельностью, и главным образом, успехами микроэлектроники. Поэтому мало кто наступающий кризис замечает, или, по крайней мере, говорит о нём. Но некоторые, пусть косвенные, проявления есть. Например:
- производительность и ресурсы компьютера выросли в тысячи раз, а реальная производительность программ - максимум на порядок. Если зарплата раньше считалась полчаса-час, то сейчас - 5-10 мин, а не секунды, как вроде должно быть. Конечно в новой ОС и программе графический интерфейс, больше возможностей, все это - накладные расходы. Ну, это снизит реальную производительность на порядок. А где еще один порядок? Съела система.
- работа программиста за 50 лет практически не изменилась, оставаясь преимущественно ручным трудом. Проблема эта осознавалась давно, было много разных попыток её решить, но ни инструментальные средства (CASE), ни методологии и языки (структурное программирование, ООП, компонентное программирование и т.п.) проблему не решили, в лучшем случае лишь ослабили её. Аналогичная ситуация с проблемой, связанной с данной: проблемой переносимости и повторного использования кода. Поэтому до сих пор программист может надеяться в основном на мощь и объем своего мозга, как ремесленник домашинной эпохи - на свои руки.
- даже член группы разработчиков достаточно большого проекта не знает его детально целиком. Тем более посторонний, скажем, эксплуатирующий программист. А если программ несколько? Да еще ОС, СУБД и пр.? Ни один системный администратор не знает до конца, что делается в подопечных компьютерах. И не имеет практической возможности узнать. Тем более изменить все, что посчитает нужным, и как посчитает нужным. Что говорить о простом пользователе? Как он всему этому может доверять?
Небольшое автобиографическое отступление.
Когда-то давно, пришел я в одну контору по поводу работы. Тамошний шеф спрашивает меня, знаю ли я их программу. Отвечаю, что относительно. Шеф кривится, как мол так, программист должен знать всё! Ну, я ему начал про структуру ПО на компьютере, его взаимосвязи и что вряд ли он найдет человека, знающего всё. Смотрю, шеф то ли не понимает, то ли не верит, а скорее всего всё вместе.
Ладно, говорит, нам тут надо кое-что в этой программе поменять, сможешь? Надо посмотреть, отвечаю, но, скорее всего, вряд ли, если она для этого не приспособлена. Он опять: как так - есть программист, есть программа, почему первый не может починить вторую? Я опять про технологию программирования, про исходные и исполняемые коды и т.д.
В общем, не договорились мы тогда (не больно-то и хотелось). Теперь все стали умнее - мы так глупо не отвечаем, они таких глупых вопросов не задают.
Но много позже я подумал: а почему собственно? Почему я не могу сделать всего этого, что хочет от меня пользователь? Может это как раз тот случай, когда устами младенца (то бишь пользователя) глаголет истина?
Можно найти еще массу других примеров. Все они по отдельности вроде бы не принципиальные, решаемые. Но когда их становится так много, и на каждом этапе жизненного цикла ПО, это значит, что везде используются не самые эффективные технологии, методики, алгоритмы, и невольно начинаешь задумываться - не ладно что-то в датском королевстве.
В чем состоит это кризис, каковы его причины?
Сложно достаточно четко и полно ответить на этот вопрос. Но очертить контуры попытаюсь.
Если проанализировать различные признаки этого кризиса, то можно сделать следующие выводы:
- с одной стороны, стремительное усложнение оборудования, объектов информатизации, увеличивающееся их количество ("широко простирает руки свои хим.., пардон, ИТ в дела человеческие"), увеличивает сложность создаваемых и эксплуатируемых ИС чуть ли не в геометрической прогрессии.
Она уже подошла к пределу возможностей мозга среднестатистического разработчика.
- с другой стороны, унаследованные из прошлого века ОС, инструментарий и технологии разработки и эксплуатации программ требуют от программиста тех же трудозатрат, что и в прошлом веке. И пусть вас не вводят в заблуждение различные высокоуровневые языки и системы автоматизации программирования.
Во-первых, их точно также писали программисты. Только другие. Так что их труд, пусть частично, следует учитывать в общих трудозатратах.
Во-вторых, весь этот инструментарий сделан по принципу штампа, с той или иной степенью настройки. Автоматизация - это унификация. Чем более универсален инструмент, тем он менее производителен, и наоборот. Но чем более специализирован инструмент, тем меньше вероятность, что он вам подойдет стопроцентно. Поиск обхода ограничений этих "высокоуровневых" систем, чтобы заставить их делать то, что надо, а не то, что заложили в них авторы, отнимает у программиста не меньше времени, чем производительная деятельность.
В-третьих, чтобы воспользоваться чужим продуктом, его надо изучить. На это то же уходит немало времени. Иногда проще написать что-то самому заново, чем использовать чужую разработку.
Таким образом, трудозатраты на единицу, скажем так, "размера" программы, хоть и уменьшились, но не сильно, и это уменьшение практически полностью поглотилось возросшей сложностью программируемого продукта. Так что суммарные трудозатраты на единицу программной продукции только увеличились.
- это приводит ко всё возрастающей потребности в программистах. Где-то я читал, что это одна из самых быстрорастущих по численности профессий. Но еще Брукс указывал, что при увеличении числа разработчиков сверх определенного предела управляемость проектом, и, следовательно, качество продукта падает ("мифический человеко-месяц"). Хотя это говорилось о группе разработчиков, но, похоже, это действительно и для всего программистского сообщества. Лет 15 назад Дж. Мартин, если не ошибаюсь, в одной из своих статей уже касался этого вопроса. Тогда он сравнивал ситуацию с разработкой ПО с ситуацией роста телефонизации в начале 20 века. Тогда пресса писала: еще немного, и половина населения сядет за коммутаторы. Но этого не случилось - изобрели АТС. Вот и в сфере разработки ПО что-нибудь изобретут, и не надо будет всем становится программистами - на такой оптимистической ноте он заканчивал статью. Однако "воз и ныне там".
- следующая, то ли причина, то ли следствие предыдущих причин. Программирование стало индустрией. Индустрия поглотила весь программистский контингент, несмотря на весь его рост, и требует ещё. Заниматься исследовательской работой, перспективой, похоже, стало некому. Даже в научной и университетской среде. То ли перестали вкладывать деньги в это дело, то ли заработки на коммерческих разработках не идут ни в какое сравнение, то ли не престижно стало этим заниматься, то ли все, как правоверные пользователи, решили, что и так все что надо, великий и всемогущий Microsoft сделает и ниспошлет. Причем не только у нас - с нами то всё ясно - но, похоже, везде.
В результате, как я уже отмечал, за последние несколько десятилетий - практически ничего принципиально нового.
Каковы пути выхода из кризиса?
Ответ вроде напрашивается сам собой - тот же, что и в промышленности в 18-19 вв.: индустриализация, переход от ручных к машинным формам труда, чтобы освободить человека от тяжелого, однообразного, непроизводительного тогда физического, сейчас умственного труда.
Но это легко сказать, а как сделать?
Вот поиском конкретных форм и методов этой индустриализации и пора начать заниматься. Причём, наиболее перспективной областью поисков, на мой взгляд, является ИИ. Только надо понимать его не как моделирование естественного, а как обеспечение ему (ЕИ) максимальной поддержки своими собственными (ИИ) средствами. Человек стал быстро перемещаться не потому, что сделал механические ноги, а потому, что сделал паровоз.
Вот например задача, решение которой позволит, на мой взгляд, продвинуться далеко вперед..
Любая программа, в т.ч. ОС - конечный автомат. Любое оборудование то же. Казалось бы, нет ни каких объективных причин, по которым первый автомат не может построить себе модель второго, и по ней управлять им. Это ведь не ЕИ, это такой же (и даже проще) автомат. Однако десятки лет, до сих пор, сотни программистов руками пишут драйверы для каждого сочетания платформа-система-устройство.
А в идеале могло быть так. Производитель оборудования сохраняет в устройстве его описание. Система при выполнении процедуры, аналогичной PnP, встретив новое устройство, не запрашивает установку драйвера, а считывает это описание и строит модель устройства, по которому определяет чем оно может быть полезно, как с его помощью выполнить требуемые функции, и что для этого нужно сделать (как управлять им). После этого система готова работать с этим устройством. Более того, если новое устройство аппаратно выполняет некоторые функции, которые ранее выполнялись программно, то система может соответственно скорректировать реализации программ с тем, чтобы они смогли воспользоваться возможностью выполнить эти функции аппаратно. Конечно, если устройство предлагает совершенно новые, доселе неиспользуемые возможности, то тут уж без человеческого интеллекта не обойтись. Хотя кто знает.
Понятия "платформа", "драйвер" должны перестать существовать.
Так вот, господа ИИ-шники.
Если вы найдете решение этой проблемы, благодарное человечество установит вам при жизни бюст на родине, и навсегда сохранит в своих сердцах память о вас.
Кстати, как вам такой подход к решению?:
Создаётся язык. Он основывается на относительно небольшом количестве элементарных, базовых, наиболее абстрактных объектов и функций. На их основе с помощью методов, аналогичных ООП, но, видимо, более мощных и гибких, строится описание более конкретных объектов, вплоть до оборудования и программ.
Таким образом, описание программы и оборудования можно развернуть до одного и того же базового уровня.
Далее, некоторым образом, в описании программы определяются фрагменты (функции) имеющие соответствие в описании устройства, то есть определяются функции программы, которые могут быть выполнены этим оборудованием.
После чего по описанию оборудования определяются необходимые управляющие воздействия для выполнения этой функции, и они подставляются в реализацию программной функции.
Это в принципе реализуемо, нет ли здесь каких-нибудь подводных камней?
Это хоть и многообещающая, но лишь одна из проблем.
Пора начинать анализ существующего положения, находить и решать проблемы.
Пора начинать создавать новую парадигму программирования.
Дополнения:
Прочитал про Mozart-Oz. По диагонали, конечно, пунктирно.
Первое впечатление: попытка сделать новый язык-оболочку, "на всё, про всё". Как про него где-то написали: "новый PL/1". Там, конечно, есть интересные детали, но всё базируется на существующей технологии.
Так что погоды он не сделает.
Попутно "открыл для себя" другие интересные вещи.
Более интересна и перспективна акцентно-объектная технология (AOP), если она сумеет развиться дальше. На сегодня, это очередная попытка обойти "родимое пятно" ООП - несоответствие между его, фактически, иерархической структурой, и сетевой, в общем случае, структурой моделируемых с его помощью объектов. Но направление мысли верное.
А реализация - ну то же управление по событиям. Прогресс в том, что точки возникновения событий расставляет не программист создающий данный класс, а использующий его, в некоторых общевычислимых для всех классов точках.
Так же в правильном направлении движется Literate Programming, уж не знаю как это правильнее по-русски. Вещь довольно старая, я о нём уже раньше слыхал, но не придал значения. Теперь переосмыслил. Только копать здесь надо поглубже.
Хотя, по возрасту, мне простительно брюзжание, меньше всего хотел, что бы мои слова воспринимались как брюзжание. Если так получилось - увы.
Конечно, всё было написано несколько спонтанно, но, наверно, естественно для большинства людей:
1 - я вижу глобальную проблему;
2 - это я её один вижу, или кто-то ещё?
Если один - надо принять что-нибудь успокоительное: может быть, полегчает;
3 - если не один, то хотелось бы узнать от других, как они эту проблему видят, и что по этому поводу думают;
4 - если ничего не думают, то попытаться подвигнуть их на это (один ум - хорошо, а много - лучше). Я считаю, что думать и решать концептуальные проблемы, пусть даже умозрительно, - это то же дело.
Вот и всё.
Вот, например, такая мысль:
Весь жизненный цикл программной системы (включая эксплуатацию) - это процесс создания и последовательной декомпозиции моделей объекта. При этом получается многоуровневая иерархия моделей, где каждый уровень является декомпозицией предидущего. И это при любой технологии, методике. Разница в том, какие уровни, где и в каком виде формируются. Может, только в голове у проектировщика/программиста; может, в виде документа; а может, в каком-либо "электронном" виде.
Каждый шаг декомпозиции уменьшает уровень абстракции модели и увеличивает степень её адаптации к конкретным условиям. Опять же, шаг этот может выполняться или человеком, или машиной, или вместе.
Мне кажется, что, если не корнем, то существенной его частью, всех проблем существующей парадигмы программирования является то, что та модель, которую олицетворяет программа, является лишь частью, причем может быть малою, собственно модели объекта.
"За кадром" остаются все "внемашиные" части этой модели, как по горизонтали - процедуры управления, пользователи, оборудование, внешние условия, так и по вертикали - верхние, более абстрактные, уровни декомпозиции модели.
То есть это, возможно, где-то и есть - в документации, стандартах, ТЗ и т.д. Но нет в программной модели. А должно быть. То есть, программа должна быть полным описанием модели объекта, со всеми уровнями декомпозиции. А сейчас программа - это фрагмент нижнего слоя иерархии моделей.
На каком и на скольких языках будет описан каждый уровень, не важно.
Важно, чтобы система имела доступ к этому описанию для анализа и использования, в т.ч. для трансляции в описание следующего уровня декомпозиции, если возможно, то автоматическое, если нет - то с помощью человека.
Таким образом, программа будет содержать все уровни иерархии моделей.
Каждый уровень будет получаться путем человеко-машинной или машинной компиляции. И, соответственно, таких компиляций-декомпозиций-адаптаций будет не одна-две, а много. В этих условиях компиляция становится одной из основных функций ОС (привязку к разным языкам здесь не рассматриваю, это хоть и сложный, но технический вопрос).
При любом изменении условий функционирования или требований к программе (что в принципе одно и тоже), производится изменение модели некоторого уровня и перекомпиляция, начиная с этого уровня до нижних.
Данный подход позволит существенно увеличить степень автоматизации процесса разработки, многократно увеличит возможность повторного использования программ (ключевая задача всех технологий), увеличит степень адаптивности программ (которая сейчас, по большому счету, практически на нуле).
Из комментариев:
Был у нас проц Z80. Складывал он себе тихо и спокойно 8-битовые данные. Появился 8088. Начал складывать 16-битные. Казалось, бы скорость должна возрасти в 2 раза. Ан нет - слово-то теперь в 2 раза больше, значит, таскать надо не 2 а 4 байта. Можно шину расширить, это да - пример все же, аналогия. Но возьмем БД. Если у нас в индексе до 256 ключей, то искать их легче прямым перебором. А если 4 миллиарда? Накладные расходы на поддержание такого индекса сведут на нет возросшую эффективность. Если раньше 8-битная БД из 256 строк условно срабатывала за секунду, то при увеличенной разрядности до 32 бит будет уже час жужжать.
Были раньше строки ASCII-7 потом наступил интернет, и теперь приходится таскать 16 битный юникод...
Допустим мы решили сделать 64 битную ОС. Ну типа сделали мы поддержку виртуальной памяти, индексы страниц ассоциативные, все 64 битное - пучком. Страшно подумать, сколько RAM придется отвести для всей этой требухи, чтоб эти терабайты поддерживать. Взять тот же 32-битный процессор - он всю свою БД в эту память вместит. И не исключено, что ответ еще раньше своего 64 битного брата-числогрыза выдаст.
Тут как с прогрессом. Чтоб построить новый самолет, надо построить новую фабрику. Чтоб построить новую фабрику надо сделать станки ... Может кто смотрел, как делали новый аэробус? А всего-то - несколько новых мест в самолете поимели.
Вот народ уже сколько времени в Microsoft страдает, чтоб отказаться от файловой системы и сделать в место файловой системы базу данных. В 95 они пытались сделать Cairo с объектно-ориентированной БД вместо файловой системы - не вышло. Теперь вот лонгхорн отложили, в котором вместо файловой БД их MS-SQL должен был жужжать ...
* * *
Если хотите что-то совсем новое и Пентиум Вам надоел, пожалуйста, два направления на горизонте - квантовые компьютеры, генетические компьютеры.
Всё это тоже на подходе.
Как устроить элементы квантового компьютера, уже придумали, вот только что с ними делать, пока не очень.
А с ДНК всё понятно: современной аппаратурой можно построить довольно длинную программу, но вот программировать как следует пока ещё не очень научились.
Но тупика никакого в этой области не намечается, как раз наоборот.
* * *
Проблема ЭВМ 5-го поколения включала 2 части: техническую и программную.
С технической и тогда принципиальных проблем не было, мощности постепенно росли и уже давно достигнуты.
А вот программная включала новый подход к ОС и его окружению.
Это как раз уже тогда было ключевым направлением Микрософт.
Но тогда (начало 80-х годов) она была еще крайне слаба и роли существенной не играла.
Проекты все были государственные: Япония, США, СССР, Англия, ЕЭС.
Провал произошел именно из-за нерешения задач программного обеспечения.
Поэтому пока квантовые компьютеры, генетические компьютеры - это всё фантазии. Даже чисто техническая реализация ничего не решает без новых реализаций в ядре программного обеспечения.
Например, Интел и ИБМ могли бы взяться, но они явно боятся конкуренции с Микрософт и боятся провала: много денег потерять.
Поскольку многое было попробовано в этом проекте, то он уже давно превратился в проблему денег.