Интервью:Михаил Горбунов-Посадов

Мы имеем честь поговорить с доктором физико-математических наук Михаилом Михайловичем Горбуновым-Посадовым. Он работает заведующим отделом в Институте прикладной математики им.М.В.Келдыша РАН. Является лауреатом Премии Совета Министров СССР (1986). В рамках интервью он согласился ответить на наши вопросы.

Первая часть

• Добрый день, Михаил Михайлович. С некоторыми Вашими работами я, и наверняка ряд специалистов в области информационных технологий, знакомы давно. Но для меня стало удивительно, что Вы большое внимание уделяете работе в интернете. Вот в одной из последних ваших статей вы пишите о «Живой публикации». Нельзя сказать, что вы пишите о чем-то новом или необычном. Так, например, я в свое время открывал викию «Виртуальная лаборатория», где предлагал специалистам открывать «виртуальные кабинеты» и публиковать свои идеи, заметки, статьи как раз в том стиле, как вы рассказываете о «живой публикации». Потом надеялся, что это поможет познакомить людей и они смогут обмениваться идеями, открывать свои научные проекты и работать вместе практически не видя друг друга в реальности. Поэтому мой первый вопрос о том, может ли то, что Вы назвали «Живой публикацией» способствовать не просто обмену информацией, мнениями, идеями через интернет, а чему то большему, что можно было бы назвать работой над каким-либо коллективным научным проектом. Как Вы вообще считаете, насколько перспективна в русскоязычном интернете такая возможность, могут ли люди работать над каким-то научным проектом, не видя друг друга, без физического контакта? Какие есть опасности на этом пути? --SSJ 22:52, 7 февраля 2012 (UTC)

Сергей Сергеевич, спасибо за приглашение к обсуждению!

Относительно знакомства с моими работами специалистов, боюсь, Вы заблуждаетесь: скорее, меня следует отнести к многочисленной категории "широко известных в узком кругу".

В упомянутой Вами статье я ни в коем случае не претендую на открытие чего-то нового. Центральным там является довольно-таки банальное наблюдение: современный автор, опубликовав в журнале свою статью и обнаружив в ней какую-либо неточность, не имеет возможности эту неточность исправить, хотя технологически такое исправление размещенного на сайте журнала текста ни для кого не составляет труда. Мешают поставить дело так, как было бы удобно и автору, и читателю, бумажные традиции, постулирующие незыблемость опубликованного текста. Если же дать автору средства для таких исправлений, то неизбежно напрашивается следующий шаг: пусть автор, на радость читателям, вообще займется постоянным поддержанием своей статьи в актуальном, т.е. отражающем меняющееся положение вещей состоянии.

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

Удивил Ваш вопрос о том, может ли работать в интернете над общим проектом коллектив людей, не видящих друг друга? Однозначный и вполне убедительный ответ нам дает та же Википедия, успех которой никто, вроде, не подвергает сомнению. Хотя в существующей ее реализации мне видится некоторая излишняя увлеченность сиюминутной интернет-традицией. Скажем, почему подавляющее большинство участников проекта не подписываются непосредственно своими фамилиями? Я повсюду подписываюсь как "Горбунов-Посадов", но при этом чувствую себя белой вороной. Характерный пример: когда Вы увидели какую-то мою правку в Википедии, первая Ваша мысль, насколько я понял, была: "Что это за самозванец так неожиданно нахально подписался?".

Потеря авторства статей весьма огорчительна для читателя. Я неплохо знаком со многими специалистами в интересующей меня области, и если бы под статьями Википедии стоили их подписи, мне бы жилось много комфортнее. А сейчас, заглядывая в Википедию, увы, нередко чувствуешь себя как в печальной детской присказке "Кто писал — не знаю, а я, дурак, читаю".

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

„давайте откажемся от профессиональных журналов“ - нет, что вы, я такое не предлагал. Да и не зачем, "жизнь в виртуальных кабинетах", на мой взгляд совершенно не мешает публикациям в профессиональных журналах.

Что касается работы в интернете над общим проектом коллективом. Я беседовал с некоторыми оппонентами из той же Википедии. Некоторая группа (можно сказать, подавляющая часть админ корпуса Википедии) считает, что одно дело написать энциклопедию, заметим, не специалистами, а дилетантами, но с опорой на вторичные источники. И совсем другое дело, что придут люди, называющие себя специалистами, а по факту это не известно. Есть ли у них образование или нет. И будут заниматься исследованиями. Тогда отличить что это за исследование якобы практически нельзя. Ну, и потом они допускают, что это в сфере информационных технологий такое допустимо, а вот для скажем физиков, химиков, биологов - не представляют как организовать коллективный удаленный проект. Может быть у Вас есть ответ на такие аргументы? --SSJ 14:43, 8 февраля 2012 (UTC)

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

Если же говорить об упомянутой Вами технологической базе Википедии, то победителей, конечно, не судят. В то же время очень хотелось бы, чтобы у интернет-читателя когда-то появилась возможность выбора: обратиться за разъяснением заинтересовавшего вопроса к Википедии или, скажем, к живой Большой российской энциклопедии, созданной и постоянно поддерживаемой в актуальном (т.е. отражающем самые последние достижения) состоянии специалистами Российской академии наук и ведущих отечественных вузов. Т.е. не к вторичным, а именно к первичным источникам, к статьям, написанным и изо дня в день актуализируемым непосредственно ведущими специалистами страны. Формирование и непрерывное плодотворное функционирование вот такого многотысячного виртуального коллектива — проект, как мне видится, вполне реалистичный и многообещающий. Горбунов-Посадов

• Второй мой вопрос вот в чем. И хотя как я выше говорил, что идея о «Живой публикации» не нова. Вы все-таки её сформулировали наиболее ясно в публикации и так сказать на академическом уровне. В другой вашей статье вы пишите, что традиционная публикация исследований в рецензируемых журналах не всегда благо, что это скорее дань прошлому. Вы пишите „"бумага" объективно препятствует ознакомлению с полученным научным результатом массового читателя“. Вот как пример, здесь у нас в Викиверситете, я организовал свой проект RNAInSpace, имея только лишь желание разобраться с проблематикой сворачивания РНК. Заодно желая показать людям, что можно с самого нуля начать проект и если не завершить научное исследование, то добиться ряда интересных результатов. Что мне потом и удалось, опубликовав статьи . Так вот с одной стороны, согласны ли вы, что это можно сказать наиболее полная, интерактивная «живая публикация», и что хорошо бы что так вели свои работы ученные, а не только постфактум доносили бы свои результаты в интернете? И с другой стороны, бытует мнение, что только разные малообразованные люди, фрики, неспециалисты с "безумными" идеями заполонили интернет. А серьезному ученому как то не с руки в таком on-line формате делать свои заметки, публиковать результаты, как бы даже слышны мнения, что это "несолидно". Что вы думаете на этот счет? Разделяют ли ваше мнение ученые, с которыми вы знакомы? Как вообще академическая среда реагирует на нужность "живых публикаций", желательность "открытости научных проектов", ведения "открытых записей по исследованиям" и т.п. интернет-активности ? --SSJ 22:52, 7 февраля 2012 (UTC)

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

В программировании эта же проблема встает в другом ракурсе. Нужно ли составлять справку о проекте по мере его реализации или же следует дождаться появления хотя бы первой дееспособной версии и лишь затем, когда основные архитектурные решения уже четко очерчены, браться за документацию?

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

Ни от кого из своих коллег ни разу не слышал слов осуждения за мои живые публикации. Другое дело, что тут регулярно возникают коллизии в отношениях с редакциями журналов. Время от времени получаю возмущенные письма. Либо "Почему Вы предлагаете нашему уважаемому изданию свою статью, в то время как ее полный текст уже давно размещен в свободном доступе на сайте Вашего института?!" Либо "Почему Вы без нашего разрешения разместили на сайте института текст, практически совпадающий с текстом ранее опубликованной в нашем издании Вашей статьи?!" Пока всякий раз удается убедить редакции, что никакого криминала в моих действиях нет, что и тот, и другой вариант размещения текста не противоречат никаким юридическим и/или профессиональным нормам.

Действительно, статус простого размещения первой версии статьи на сайте родной организации существенно ниже, чем статус, например, препринта. А ведь препринты никогда и никем не рассматривались как препятствие к публикации буквально той же работы в журнале. Более того, подавляющее большинство физических журналов на Западе не принимает статью даже к рассмотрению, если она не размещена предварительно в свободном доступе на arxiv.org. Массачусетский технологический институт уже несколько лет как не позволяет своим сотрудникам направлять статью в журнал, если ее полный текст не размещен предварительно на сайте МТИ. На днях нам пришлось срочно размещать на сайте Института препринт одного из сотрудников, поскольку его без этого не допускали к участию с таким докладом на крупную международную конференцию. Могу привести еще десятки подобных примеров.

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

А к ученым, открывшим и регулярно поддерживающим в боевом состоянии сайт своего проекта, обычно отношение в научной среде самое благожелательное. По крайней мере, при защите диссертации, при оценке результатов, полученных в исследованиях по гранту, достойное веб-представительство работ уже много лет расценивается как самая надежная валюта. Горбунов-Посадов

• А Вы сами могли, хотели бы открыть коллективный удаленный проект? Над какой бы проблематикой вы предложили бы поработать? Могли бы Вы возглавить, вдохновить ряд людей? Не жалко ли вам было бы времени, чтобы обучать молодых людей? Может быть у вас есть знакомые коллеги, которые могли бы с вами поработать, и показать мастер-класс? --SSJ 23:37, 10 февраля 2012 (UTC)

Совершенно неожиданный для меня вопрос. Готового ответа на него у меня определенно нет. Мне представляется, что к коллективному удаленному проекту надо достаточно долго сознательно стремиться, прорабатывать детали, и лишь тогда у него появляются шансы на успех. Спонтанно предлагать тему и выходить с ней на всеобщее обозрение как-то не хотелось бы.

Мастер-класс, мне кажется, лежит в несколько иной плоскости. Мастер довел свои навыки в чем-то до совершенства и готов ими поделиться. Что-то как-то не чувствую в себе таких заслуживающих тиражирования навыков. Если Вы имеете в виду тематику расширяемых программ из заинтересовавшей Вас моей книги, то, увы, мастер-класс мне сейчас определенно не по силам. Первое, что здесь понадобилось бы, — доведенное до блеска владение какой-либо из современных инструментальных сред программирования. Похвастать мне тут нечем. Административные хлопоты съедают все время, программирую от силы месяц в году (летом, когда появляется перерыв в бесчисленных заседаниях и отчетах), за год все навыки безнадежно забываются, впору самому идти учиться... Горбунов-Посадов (обсуждение) 06:57, 11 марта 2012 (UTC)

• Ой, я совершенно забыл Вас спросить о институте в котором Вы работаете. Вы не могли бы рассказать в двух словах, чем он занимается проводит ли какие-то исследования/научные проекты, или занимается только обучением? Какие области математики/программирования большего всего изучаются? И вопрос, интересующий скорее только меня, случайно при вашем институте нет ли реферируемого журнала, который публикует статьи по тематике "искусственного интеллекта" или "моделирования/симуляции"? --SSJ (обсуждение) 11:48, 11 марта 2012 (UTC)

Об Институте можно почитать, например, в Википедии или на нашем сайте здесь и здесь. Институт является учредителем только трех журналов, кажется, все из Перечня ВАК. Журнала по интересующей Вас тематике нет. Точнее, есть журнал "Математическое моделирование", но его профиль далек от интересующего Вас направления "моделирование/симуляция". Горбунов-Посадов (обсуждение) 21:16, 11 марта 2012 (UTC)

Вторая часть

Вторая часть моих вопросов будет относиться непосредственно к вашей профессиональной научной деятельности.

• Наверное наиболее полно ваши идеи в области разработки программ отражены в книге «Расширяемые программы» . На мой взгляд, в книге подымаются очень важные и глубокие темы для программирования. Но правда ли, что тираж только 3000 экз.? Я честно говоря, удивлен, что стал обладателем такой редкой книги. И при этом я купил её не в Москве, и даже не в России, а в Риге. Конечно, книга больше теоретического плана, но очень полезна будущим практикам в программировании. Вы наверное получали какие то отзывы после выхода книги. Как вам кажется, насколько известно рядовым программистам то, о чем вы писали, сейчас, через более чем 10 лет после выхода книги? Интересуются ли такими вопросами опытные программисты на практике? Почему? --SSJ 00:58, 8 февраля 2012 (UTC)

У заинтересовавшей Вас книги сложная трехступенчатая история. Первая ее редакция вышла в 1993 году тиражом 5 000 экз. и была раскуплена за 1-2 дня. В 1994 году вышла переработанная редакция тиражом 20 000 экз. и разошлась в магазинах за 1-2 месяца. А книга, о которой Вы говорите, — третье издание, вышедшее в 1999 году действительно тиражом 3 000 экз.: я сам перевозил тираж, книг на складе было ровно столько, сколько указано в выходных данных. Так вот эта последняя книга продавалась лет десять, только сейчас она кончается в последних интернет-магазинах.

Объяснить утраченный интерес к книге, мне кажется, можно достаточно просто. В начале 90-х в стране еще оставались тысячи или, скорее, десятки тысяч программистов, имевших дело с программами масштаба сотен тысяч и миллионов строк кода. Такие программы в 60-80-х годах писались, в основном, для оборонки, которая в 90-е просто перестала существовать. И, соответственно, исчезли потенциальные читатели книги. Прекрасно помню залы всесоюзных конференций на 200-300 человек в 70-80-х годах, где каждый действительно имел дело с программами такого объема и где бурно обсуждались проблемы крупных программ. Трудно представить, что сейчас удалось бы собрать подобную аудиторию.

В 1999 году тираж книги определял я сам. Ситуация с отсутствием читателей в тот момент уже легко прогнозировалась, и я выбрал безумный тираж 3000 экз. именно в расчете на то, что книга пролежит на прилавках лет десять. Ведь каждое переиздание требует от автора заметных трудозатрат. Так что чем реже книга переиздается, тем автору легче.

Отзывы о книге встречаются самые пестрые. Чаще ругают, воспринимая как обычное академическое словоблудие. Ругают, думаю, искренне, поскольку человеку, не имевшему дела с крупными программами, трудно переварить большинство из того, что там написано. Да я и не рассчитывал на такого читателя.

Жалко, конечно. Еще в 80-х программистский девиз книги "Ищи однородность — найдешь расширяемость" вполне мог бы быть воспринят и даже, возможно, вошел бы в учебники. Сейчас в нашей стране у него нет никаких шансов. Любопытно, что выложенную в свободный доступ коротенькую англоязычную аннотацию к книге до сих пор читают не менее десяти посетителей в день: на Западе интерес к такой проблематике пока сохраняется.

Самый интересный и лестный отзыв о книге я получил от своего одноклассника, далекого от программирования. Он рассказал, что всегда читает мою книгу перед сном. Как читатель этого интервью, вероятно, заметил, я вообще обычно пишу в убаюкивающем ритме, так что тут с книгой был достигнут полный успех. Горбунов-Посадов

• Чтобы задать вам следующий вопрос я выскажу некоторые свои критические замечания. Я отлично понимаю, что ваша книга писалась, а потом выходила к своему читателю еще в то время когда объектно-ориентированный подход (ООП) только начинал свое "победное шествие". И ваши идеи о сборочном программировании одинаково относятся как к процедурному подходу, так и к ООП. Но если в условно западных книгах, которые как правило пишутся на 1000 страниц, ориентируются на практика, и показывают как на том или ином языке сделать то или другое, какие имеются концепции и как их применить, то у вас читателю сложно связать предлагаемые идеи с практикой. На каком языке можно использовать ваши конструкции? Было ли это реализовано в коде? Как ваши конструкции можно реализовать в коде известных языков? Все это те вопросы на которые вы не даете ответа. После прочтения возникает ощущение, что вы где то использовали ваши конструкции, но не рассказываете этого в книге. Далее, вы никак не связываете свои концепции с тем, что уже есть. Так, например, был когда то такой язык Clarion. Он как раз таки построен по принципу сборочного программирования. Что-то подобное также реализовано в языке 1C (правда в чудовищной вариации). Почему вы никак не связываете свои концепции с подобными языками? С другой стороны, вы вскользь упоминаете концепции повторного использования, и немного критикуете ООП. Но не вдаетесь в детали. Так же стоит отметить, что концепция т.н. «Рефакторинга», которую знают многие программисты сейчас - это по сути есть развитие вашего безболезненного развития программ. Почему вы не связываете одно с другим ? В итоге получается, что Вы пишите как бы о "достижениях в России", а все что известно и что так или иначе используется в Америке, в Европе проходит параллельно как тень. И читатель с этим не знакомый не может провести эти параллели. Поэтому во-первых, видите ли Вы сами эти параллели? И если да, почему не пишите о них? --SSJ 19:00, 10 февраля 2012 (UTC)

Вопросов много. Отвечу на некоторые из них.

Почему в книге нет (точнее, мало) примеров на конкретных языках? Выше уже отмечалось, что книга была рассчитана на то, чтобы лет десять быть доступной в магазинах. А популярные языки и популярные инструментальные среды — материя довольно-таки динамичная. В частности, месяца два назад C# обошел по популярности C++, а ведь в 1999 году, когда была издана книга, о C# никто и не слышал. Так что отсутствие примеров на конкретных языках и средах — решение, в основном, сознательное.

Искомые примеры можно найти в моих статьях. В частности, статья "Безболезненное развитие программы" вся построена на примерах. Однако вряд ли сейчас кто-либо помнит чрезвычайно популярные в то время продукты фирмы Борланд, на которые опирается изложение.

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

Были ли когда-либо предлагаемые в книге конструкции реализованы? Были, но лишь отчасти. Инструментарий поддержки вариантного программирования был разработан в 1970-х годах для БЭСМ-6. В ИПМ им.М.В.Келдыша на нем работало 150-200 программистов, он был передан в 30-40 организаций. Но в 80-е годы задачи уже стали помельче, и переносить эти наработки на новые платформы оказалось нецелесообразным.

Как сейчас взяться за реализацию средств расширяемого программирования в полном объеме, не знаю. Тут образовался порочный круг. Думаю, многие согласятся с тем, что расширяемость — наиболее ценимое опытными программистами свойство программы. Тем не менее, большинство существующих инструментальных сред не допускают расширения. Т.е. рядовой пользователь, пожелавший органично включить, например, в C# из MS Visual Studio какой-либо новый, изобретенный им оператор, быстро осознает, что задача эта практически неразрешима. Беда в том, что до сих пор не сформировалась, если хотите, мода на расширяемость. Создавший программный продукт разработчик, не предоставивший своему пользователю возможности легкого безболезненного развития этого продукта, чувствует себя сейчас вполне комфортно, не терзаясь угрызениями совести и не теряя авторитета среди коллег. А объясняется сложившееся положение в первую очередь тем, что современные разработчики работают в средах, не поддерживающих расширяемые конструкции, т.е. они не в состоянии, даже если сильно захотят, дать своим пользователям комфортные средства расширения. Итак, дополнить современную инструментальную среду реализацией своих расширяемых конструкций я не могу, поскольку среда не дает возможностей расширения. А возможностей она не дает именно потому, что я не смог дополнить ее ими.

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

Параллели с существующими средствами? Очень многие читатели писали мне о них. Чаще всего это звучало приблизительно так. "Вот Вы тут что-то доморощенное зачем-то изобретаете. По-видимому, Вы до сих пот работаете в Турбо-Паскале версии 7.8.2 и не знаете того, что в версии 7.8.3 все волнующие Вас проблемы раз и навсегда полностью решены!". Действительно, некоторые интересные подвижки в направлении поддержки расширяемости время от времени случаются. Но почему-то никто даже близко не подходит к компактной формуле, в справедливости которой я убежден и с надеждой на торжество которой писалась книга.

(1) Любая точка роста программы представима в форме расширяемого набора однородных модулей.

(2) Любое эволюционное изменение программы представимо в форме совокупности модулей, предназначенных для пополнения одной или нескольких точек роста. Горбунов-Посадов

• Спрошу более четко: вы знакомы с такими понятиями как паттерны проектирования и рефакторинг? Если да, то что вы о них думаете? Не считаете ли вы, что с помощью этих приемов можно лучше, чем вы предлагаете, решить например проблему „оформления варианта“? Понятно, что когда вы предлагали свой вариант решения, они еще не были известны, но может быть сейчас именно это и является тем инструментом об отсутствии которого вы говорите? --SSJ 00:49, 20 февраля 2012 (UTC)

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

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

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

Паттерны проектирования не интересуются тем, как организуются между собой различные их реализации. Это ни в коем случае не недостаток паттернов, это просто другая постановка задачи.

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

Если уж искать современных соседей предлагаемой в книге технологии, то, на мой взгляд, ближе всего к ней оказывается аспектно-ориентированное программирование. Горбунов-Посадов 10:22, 23 февраля 2012 (UTC)

Специальные вопросы о программировании

• Но вот смотрите. Как один из вариантов решения задачи "оформления варианта" вы описываете использование подпрограмм. На самом деле, этот вариант является структурно более правильным, т.к. гнездо/подпрограмма получает имя и параметры, которые охарактеризовывают, что это за вариант (напр., линейный поиск или хеширование) и какие входные/выходные данные нужны. Т.е. все в полном согласии с принципами парадигмы структурного программирования. Но вы указываете, что такой способ не безболезненный для изменения. Но если использовать рефакторинг "Выделение метода", а его уже ряд редакторов поддерживает, то автоматически будет выделена указанная часть и оформлена как метод с параметрами, и вместо текста будет подставлен вызов. Т.е. применение подпрограмм уже не несет в себе угрозу безболезненности даже при первом оформлении подпрограммы. А программа становится более структурной. Если пойти дальше, то в месте вызова могут образоваться ветвление с оператором case. Но применяя следующий рефакторинг "Замена case иерархией наследования", нам останется лишь создавать объект нужного нам класса. Т.е. и тут все будет безболезненно. Вы же предлагаете использовать препроцессор, и вы так или иначе указываете начало и конец выделяемого участка, и вносите код, что на самом деле не столь и безболезненно. Но главный минус вашего предложения, на мой взгляд, что программа не становится структурной, и если подпрограмму затем можно спокойно вызвать из другого места, то подставить туда тот или иной вариант опасно, так как оно окажется в незнакомом окружении, а входные/выходные параметры, если я правильно помню, у вас не определены. Что вы на это скажите? --SSJ 11:27, 23 февраля 2012 (UTC)

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

Вы упоминаете "Выделение метода". В соответствующем разделе главы есть, как мне казалось, прямой ответ на Ваш вопрос (цитирую):

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

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

Что же касается упоминаемых Вами неожиданных поворотов судьбы полученной таким образом подпрограммы, то они меня в контексте книги просто не интересовали. В первой главе речь шла только об оформлении варианта, а не о последующей многоплановой утилизации такого оформления. Более того, мне видится, что подпрограмма, выделенная из потребности оформления варианта, скорее всего, нигде вне контекста этого варианта применяться не будет. Горбунов-Посадов 14:08, 27 февраля 2012 (UTC)

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

        public event ChangeMyProperty;
        private _MyProperty;
        public MyProperty
        {
           get { return _MyProperty; }
           set 
           { 
               if (_MyProperty != value)
               {
                  _MyProperty = value;
                  ChangeMyProperty();
               }
           }
        }

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

        public event Change#;
        private _#;
        public #
        {
           get { return _#; }
           set 
           { 
               if (_# != value)
               {
                  _# = value;
                  Change#();
               }
           }
        }

И тогда, можем сгенерировать исходный код (практически полностью) элементарной программы для считывания, отображения, записи определенных данных. И для этого нужно лишь вместо знака "#" подставить названия свойств, например, Name, Address, Phone ...

Вопрос: данный пример соответствует тому, что Вы описывали в своей книге (в целом, как выполнение соответствующей идеологии/парадигмы сборочного программирования)? Достоинства видны - можно легко генерировать, а не вручную писать однообразные участки программ. Но какие недостатки по сравнению с ООП Вы тут видите? --SSJ (обсуждение) 14:38, 3 марта 2012 (UTC)

PS. Я тоже извиняюсь за задержку с вопросом, но видимо, в таком режиме нет ничего плохого. --SSJ (обсуждение) 01:29, 4 марта 2012 (UTC)

Попробую сформулировать свое понимание Вашего примера. Пусть в некоторой среде предстоит работать с устойчивыми парами: переменная и событие, сообщающее об изменении этой переменной. И переменная, и событие должны быть видны вовне, т. е. специфицируются как public. Естественно, возникает желание каким-то образом подчеркнуть принадлежность переменной и события одной и той же паре. Вас почему-либо не устраивает традиционное ООП-решение, где пара локализовалась бы в классе MyProperty, а переменная и событие именовались бы в виде <имя экземпляра MyProperty>.Value и <имя экземпляра MyProperty>.Change. Вы хотите, чтобы идентификатор переменной совпадал с идентификатором (именем экземпляра) пары, а в идентификаторе события к идентификатору пары был приконкатенирован префикс Change (т.е. слева, а не справа, и без точки).

Далее Ваши действия могут пойти по одному из трех направлений.

1. Вы просто принимаете эти соглашения и, не выходя за рамки имеющейся ООП-среды, присваиваете своим событиям и переменным идентификаторы в соответствии с указанным правилом. Ваша программа благополучно работает, мнемоника Вам помогает. Но правило всего лишь висит в воздухе, его ничего не стоит нарушить, его может не заметить невнимательный читатель вашего кода, так что возникает некоторая неудовлетворенность.

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

3. Вы разглядели в анализируемой ситуации фундаментальную проблему, требующую поддержки на уровне используемой инструментальной среды и, в частности, на уровне синтаксиса инструментального языка программирования. Объем работ по реализации такого решения на много порядков превышает усилия по написанию макроопределения, но зато теперь любой программист будет располагать средствами для адекватного оформления подобной ситуации и синтаксический разбор будет выдавать диагностические сообщения там, где это удобно и понятно потребителю.

Относится ли Ваш пример к проблематике каркасного подхода, о котором я пишу в книге? На мой взгляд, скорее, нет. Меня вполне устроило бы общепринятое ООП-решение описанной Вами проблемы, потребности в какой-либо модификации традиционной инструментальной среды у меня тут не возникает. Хотя, возможно, я не разглядел каких-то существенных нюансов Вашей постановки задачи.

Но что касается способа иллюстрации возможного решения проблемы, не охваченной современными инструментальными средами, то тут я к Вам присоединяюсь. Сначала подробно описываем проблему, показываем, как она решается в традиционной инструментальной среде. Такое решение, конечно, всегда существует, однако без системной поддержки оно зачастую выглядит весьма неуклюже (характерные примеры неуклюжих решений, к которым толкает существующая среда, можно увидеть, например, в статье). Чтобы продемонстрировать, как могло бы выглядеть более-менее аккуратное решение, проще всего привлечь несложный и известный всем аппарат препроцессирования и макрогенерации, что я бегло и делаю во многих примерах в книге. В то же время для фундаментального решения требуется основательное внедрение новых средств в инструментальную среду, и эту последнюю фазу я, как правило, в книге опускаю, чтобы не привязаться жестко к специфике того или иного инструментального языка. Если в результате у Вас сформировалось ощущение, что в моей книге содержится апологетика препроцессирования и макрогенерации, то должен принести извинения: что-то, вероятно, я просто невнятно излагал. По существу же препроцессирование и макрогенерация играют у меня сугубо вспомогательную, иллюстративную роль. Горбунов-Посадов (обсуждение) 09:22, 9 марта 2012 (UTC)

• Спасибо, вам за ответы - кое-что стало более понятно. Единственно, вы наверное пропустили один вопрос в первой части, ответьте если возможно? Ну, и не забывайте нас и наш пока еще маленький проект. Но у нас большие амбиции - привлечь различных ученных, исследователей и желающих обучаться/обучать в одно сообщество, которое общаясь вместе сможет чего-то добиться, не меньше чем реальные институты. Еще раз спасибо. --SSJ (обсуждение) 14:13, 10 марта 2012 (UTC)

Если кого-то из читателей заинтересовали подробности обсуждавшихся выше проблем, добро пожаловать на мою персональную страницу Горбунов-Посадов 14:08, 27 февраля 2012 (UTC)