Об опасности драконов
в рубрике Колонка Спанч Боба, Технологии , теги: Мысли в слух

«Всякая задача становится тривиальной, если ее сформулировать в адекватном языке»
И. М. Гельфанд
«Серебряной пули нет», сказал Ф.Брукс без малого двадцать лет назад и надолго остудил пыл благородных рыцарей от программирования в борьбе с Драконом сложности. С тех пор его Величество Дракон служит оправданием тому, что пользователям вместо одних плохо работающих программ, навязываются все новые и новые, которые не намного лучше, но пожирают все больше быстродействия и памяти компьютеров («А что? Пипл хавает!» (с) Б.Титамир). В угоду Дракону, выращена специальная разновидность программистов — «code & fix» («программируй и исправляй ошибки»). «Не умением, а числом!», «Каждая кухарка может управлять программным проектом!» — написано на их знаменах. Чтобы прокормить Дракона каждый день ими создаются гигабайты исходного кода, значительная часть которого никогда не будет востребована пользователями. За прошедшие годы этот отвратительный Дракон разросся и стал «Идеей. Исторической необходимостью. Нашим государственным интересом. Могущественным фактором, оправданием наших объединенных усилий» (С. Лем, О выгодности дракона).
Я не собираюсь искать очередную «серебряную пулю», но не потому, что ее нет, а потому, что не очень верю в драконов. Драконы, как правило, рождаются в сознании людей, когда они сталкиваются с явлениями, которые не находят объяснения в их предыдущем опыте. Для информатики наличие пробелов не удивительно потому, что это очень молодая отрасль человеческого знания. Если сравнивать производство программного обеспечения с производством технических систем, которое насчитывает многие тысячелетия, то можно заключить, что оно пока пребывает в эмбриональном состоянии.
Я не очень верю в драконов, зато верю в то, что сложность это понятие субъективное. Одно из определений слова «сложный» — трудный, запутанный. Например, сложная задача, сложная (а может быть точнее запутанная?) программа. То, что для одного человека является трудным и запутанным для другого может быть легким и ясным. Движение планет в геоцентрической модели Птолемея по циклам и эпициклам с поправками к ним выглядит сложным. Движение по эллипсам Кеплера – простым. Если редактировать изображения в битовом формате, получится сложно, а если в графическом редакторе, то просто. Изображение множества Мандельброта может просто загипнотизировать своей сложностью непосвященного наблюдателя, но на адекватном языке множество Мандельброта описывается крайне просто: «множество точек C на комплексной плоскости, для которых итеративная последовательность Z0 = 0; Zn+1 = Zn^2 + C не уходит в бесконечность».

В природе нет ничего трудного и запутанного. Нечто может только казаться трудным и запутанным человеку, который это нечто пытается понять. Может быть, программные системы только кажутся сложными? Я порой ощущаю себя шарлатаном, когда пытаюсь объяснить заказчику, почему так сложно добавить к программе функциональность, о которой он просит.
Еще в 1977 году в своей лекции при получении премии Тьюринга Джон Бекус говорил, что императивные языки программирования вынуждают программиста сосредоточится на операциях с памятью компьютера, а не на проблеме, которую надо решить. Что изменилось с тех пор? Ничего. Мы по-прежнему описываем задачу, которую должна решать программа, на языке битов, команд процессора, передачи управления.
Мне представляется, что в будущем среды программирования будут в основном похожи на CAD системы с встроенным DSL. Программные системы будут создавать специалисты прикладной области, например, инженер-электронщик будет собирать программную модель электронной схемы из готовой элементной базы: моделей транзисторов, резисторов, конденсаторов, переключателей, соединителей и проч. Аналогично, будут собираться из готовых компонентов и бизнес-приложения: бухгалтерия, склад, производство и др. А что нам может помешать двигаться в этом направлении? ИМХО, это лишь дело времени.
Комментариев: 6 на “Об опасности драконов”
Прокомментировать
Вы должны быть авторизованы для комментирования.




Запиркин Денис:
Ой как все спооорно…. Просто ойойой… (качаю головой)…


При всем моем колоссальном уважении к тебе, Сереж, я, конечно, очень-очень (что? а, да) поспорю по каждому абзацу или даже глубже… Как-нибудь, как будет настроение и время.
А сейчас у меня такое настроение, что я просто ворчун (как Костя Кондратюк в соседнем блог-посте про Asshole Driven Development), так что я чуть поворчу, если никто не против.
Чуть-чуть это:
1) я не понял, что реально Евклид говорил про информатику? (”Развитие информатики представляется рекой, которая рождается далеко в прошлом (Евклид, III век до н.э”)
2) сорри, но у Броуна не было никаких “Броуновских молекул, которые..”, - у него были “броуновские” частицы..
Сорри, голова болит, наверное, поэтому ворчу…
И еще. Я бы предложил скорее не дракона, а змею. На более высоком уровне. Ту самую, которая кусает сама себя. Вот к примеру: “Аналогично, будут собираться из готовых компонентов и бизнес-приложения: бухгалтерия, склад, производство и др. “, - любой человек из ERP подтвердит (с большой вероятностью, мне кажется), что ничего в реальной жизни (в реальном бизнесе) из этих компонент при детальном рассмотрении не собирается. Если собирается, то это не программирование. А если (по жизни) не собирается… …вот тут змея и кусает себя за хвост, потому что if (is_customization OR is_business_specific) then dragon=softwaredevelopment+softwarepeople
ну как-то так..
Сорри, если что
И еще вот про это “В природе нет ничего трудного и запутанного. Нечто может только казаться трудным и запутанным человеку, который это нечто пытается понять”, - думаю, что пока бизнес(клиент) это люди, все будет трудным и запутанным.
Цап! (ну это опять змея.. себя)..
28 января, 2010 в 23:08
Архипенков Сергей:
Денис, привет!
То, что все спорно, это здорово! Глупость или банальность споров не вызывают
Про Евклида
Я имел в виду алгоритм Евклида — алгоритм для нахождения наибольшего общего делителя двух целых чисел или наибольшей общей меры двух однородных величин (http://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_%D0%95%D0%B2%D0%BA%D0%BB%D0%B8%D0%B4%D0%B0).
Про Броуна и его частицы, ты совершенно прав, учту.
Про ERP.
Ты говоришь о современном состоянии. А я о “светлом будущем”. Если мне не изменяет память, в БД SAP R/3 более 50 тыс. таблиц, а в самом толстом русском словаре всего 110 тыс. слов?! Это ли не пример сложности и запутанности. Был бы адекватный язык DSL для описания бизнеса, то количество сущностей было бы равно количеству бизнес-понятий. Вот!
ИМХО, засада в том, что никто не знает как такие DSL надо строить
Над формальным представлением требований/знаний работают уже лет 30, однако, результат = 0. В эту же проблему уперся и искусственный интеллект.
29 января, 2010 в 10:33
yurash:
“Всякая задача становится тривиальной, если ее сформулировать в адекватном языке” - по сути это значит, что задача разбивается на две: разработка этого самого адекватного языка и собственно решение задачи, ставшей тривиальной после перевод на этот язык. Разработка адекватного языка - практически всегда задача весьма сложная, требующая обобщения и реструктуризации всех знаний, накопленных в данной области, но зато результат - “повторно используемый”.
Индустрия разработки ПО, собственно, так и развивается - разрабатываются новые языки, фреймворки, компоненты, при помощи которых старые задачи решаются легче. Другое дело - что сложность задач успевает вырасти за это время, и опять нужен более высокоуровневый и более адекватный язык. А на существующих языках многие новые задачи опять не будут тривиальны.
Тут скорее проблема не в софтверной индустрии, а в целом в скорости изменения общества. И в том, что ИТ в принципе согласна меняться с такой скоростью. Всем хочется “чего-то новенького”, и делать качественно, “на века” - обычно не выгодно (хотя некоторые пытаются думать об этом: http://www.good.is/post/built-to-last ), вот и делаем всё в спешке, а “простота” за нами не успевает
1 февраля, 2010 в 16:35
Сатаров Владимир:
Извините что вмешиваюсь коллеги и прошу простить за мой французский.
0. Таки да, автор прав. За DSL будущее. Точнее, за некоторыми идеями, которые в них есть.
1. Помимо дракона/змеи есть еще Сцилла и Харибда. Все программисты проходят в своем профессиональном развитии этап шаблонизации. Это когда очень хочется написать такой шаблон, чтобы потом трах-бах - и готов код. В жизни “трах-бах” - это звук соприкосновения йуного лба и железобетонной стены. Только после этого приходит понимание, что если делать код специфичным - потеряешь гибкость; сделаешь обратный шаг - потеряешь специфичность. Когда создается очередной DSL его авторы в том числе решают вопрос, кому из монстров его скормить. Целый зоопарк получается, однако.
2. Завидую Бэкусу. Имея океан ОЗУ, море языков и озеро технологий, мы до сих пор решаем вопрос “как бы втиснуть задачу во все ограничения этой прорвы?”
3. “оно пока пребывает в эмбриональном состоянии”, что просто эпически удивительно! У меня порой такое ощущение, что классиков просто не было в природе, а все учебники врут. Чего стоит одна формальная верификация произвольной программы. Фактически она как бог: некоторые верят, что она есть, другие верят, что ее нет; но никто не может привести фактов.
2 февраля, 2010 в 16:27
Баранцев Алексей:
Вслед последнему комментарию про формальную верификацию — перевод свеженькой статьи Парнаса о текущем состоянии формальных методов: http://citforum.ru/SE/quality/fm_rethinking/
3 февраля, 2010 в 12:28
Сатаров Владимир:
Опс, это я правильно зашел
Огромное спасибо за ссылку!
4 февраля, 2010 в 16:51