Оберон-клуб «ВЄДАsoft»

Диву даюсь. Читал вчера книгу про языки программирования (что-то вроде расширенных интервью с авторами популярных языков), безусловно, книга очень интересная, но в ней рассматривается 27 языков, но не представлены ни Паскаль, ни Модула, ни, тем паче, Оберон! Как обидно. И очень большое количество людей про Оберон ничего не знают (или знают, но превратно, что ещё хуже!). Несправедливо, прям дискриминация какая-то.

А книгу всё же советую, занимательная

Бьянкуцци Федерико — Пионеры программирования. Диалоги

Действительно. Ужасно мало распространен Оберон. И "паскалеподобные" ЯП тоже. Только из-за Дельфи и FP еще и держатся, но Дельфи и FP куда-то не туда пошли - в сторону усложнения. А так везде Си, с плюсами и без, Ява и тому подобное, какие-нибудь скрипты с сишным синтаксисом. "Небольшое, простое, аскетичное, не может принести много денег, в отличие от огромного, запутанного, богатоизукрашенного" - может быть дело в этом?

Риторический вопрос, конечно же. Дело в том, что в мутной водичке гораздо проще ловить рыбку. Посмотри на описание языка Java — это больше похоже на рекламный проспект, чем на действительно объективную информацию. Программирование попсеет. Мне кажется, это неизбежно происходит именно из-за размытия социума. Скажем, был Спектрум, и на нём технари, да и вообще творческие люди были доминирующим социумом. Появился ПК, мобилки, смарты, и пришёл обыватель, и теперь он диктует законы, потребности (давай всё, и побыстрее, вдумчиво до завтра делать некогда, спеши сделать это вчера. Потребитель всегда прав). И что можно поделать в такой ситуации? И тут приходят "на помощь" гиганты IT, которые говорят с программистами на языке потребителя: "ты сделаешь это ещё быстрее, срубишь бабла и скорее пойдёшь домой". А творец потонул в общей массе, он стал мелок, чувствует себя не в своей тарелке, и голос его слышится тихо.

Кстати, вот Страуструп в книге высказался предельно ясно. Симпатичный мужик, делал язык для своих целей. Рад, что смог кому-то помочь им. Старается сделать лучше. Про Гвидо ван Россума другое у меня впечатление: "Я сделал так, потому что у меня интуиция. Объяснить, почему именно так, не могу. Но внутренний голос..." — пропадает всякое желание возиться с Питоном. А вот про APL — действительно поучительно. Оказывается, были APL-системы... Но почему всё же автор не вставил туда хотя бы про Delphi? Неужто он подсознательно ненавидит всё, что связано с Паскалем, и предпочитает о нём тихо молчать? Кстати, как правило, люди-сишники подсознательно чувствуют, что Паскаль в чём-то гораздо лучше Cей, но они же — и первые, кто орёт на всех углах "Паскаль умер". Противоречие. Или автор считает Паскаль таким незначительным событием в языкостроении? Но ведь, кстати, даже Алгол-68 упоминается в книге. Именно 68! этот презренный Си-подобный по своим вывертам диалект. А не Algol-60 или виртовский Algol-W. Такое умалчивание, как минимум некорректно, мне кажется.

Как научиться отладке?

Томас Курц: Прежде всего, не надо всё сводить к этому, то есть нужно лучше продумывать всё заранее.
Один из наших бывших студентов стал сотрудником Apple, делал там очень важную работу и затем вышел в отставку. Прежде он работал в вычислительном центре в Дартмуте. Он написал компилятор PL/1 — это крупная штука — и проверял его, смотрел на него и так далее, но ни разу не тестировал и ни разу не запустил, пока всё не было готово. Это 20 или 30 тысяч строк кода, и всё тестирование заключалось в том, что он читал этот код. Затем он запустил его, и всё заработало с первого раза!
Это исключительный случай в истории программирования! Если кто-то напишет программу в 20000-30000 строк, и она заработает с первого раза, это нечто необычное, верно? Но он сделал это, и это пример другим. Он работал в одиночестве — не в команде. Тот, кто работает один, всегда продуктивнее. Он очень тщательно проверял, как работают вместе разные части программы, и тщательно перечитывал код, а читая код, на самом деле эмулируешь то, что будет делать компьютер, поэтому проверяешь каждый шаг: это верно, это верно и т.д.
Поэтому когда он нажал кнопку «пуск» и всё заработало, это удивительно — так ни у кого не бывает! Но идея понятна. Чтобы уменьшить количество ошибок, нужно прежде всего стараться не делать их.
Многие имеющиеся коммерческие программы кишат ошибками, потому что их пишут не хорошие программисты, а команды, а функции программы определяются в отделе маркетинга. Он должен представить в определённый срок программу с определённой функциональностью, поэтому в ней полно ошибок. Софтверные компании считают, что большинство пользователей лишь поверхностно используют свои программы, из-за чего не сталкиваются со многими ошибками.

Каков главный урок, извлечённый вами из своего долгого и обширного опыта?

Том: Делайте так, чтобы пользователям проще было работать с вашей программой.
Можете называть это дружественностью Пользователю, если хотите, но учтите, что в отрасли определили дружественность, как мне кажется, в смысле «снисходительность». Настоящая задача дружественности пользователю в том, чтобы определить разумные значения по умолчанию в создаваемом вами приложении, чтобы человеку, впервые с ним встречающемуся, не нужно было изучать все варианты и степени свободы, которые ему предоставлены. Пользователь должен сесть и сразу начать работать. Если ему потребуется что-то иное, должен быть относительно простой способ это получить.
Чтобы это стало возможным, нужно иметь некоторое представление о своих будущих пользователях.
Я часто работал с Microsoft Word, и с моей точки зрения это совершенно не дружественное пользователю приложение.

Такой компьютерный язык, как Бейсик, не рассчитан на профессиональных программистов. Если вы специалист в какой-то области и решили написать для неё приложение, то выберете для такой работы более простой язык, чем это сделал бы профессионал. В частности, я имею в виду широко распространившиеся объектно-ориентированные языки.
У меня есть некоторый опыт работы с одним из них, невероятно сложным. Это единственный язык в моей жизни, с которым я не справился, а количество языков, на которых я писал программы, приближается к трём десяткам.

Как создавать язык, облегчающий отладку? Как при проектировании языка добавить или убрать функции, чтобы улучшить отладку?

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

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

Это нерешённый вопрос в исследовании систем: как создать язык, чтобы его можно было расширить за пределы первоначальной предметной области, не модифицируя сам язык? У вас есть механизм расширения?

Ал: Есть проверенный временем подход — библиотеки.

Даже в С++ и Java ожидаются изменения.

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

Хорошо ли это само по себе?

Ал: Конечно, очень желательно иметь возможность пользоваться старыми программами. Я когда-то написал статью для журнала «Science Magazine*, озаглавленную «Software and the Future of Programming Languages* (Программное обеспечение и будущее языков программирования). Там я попытался оценить объём программного обеспечения, на работе которого держится наше существование, учитывая программы, используемые как организациями, так и отдельными людьми.
У меня получилось от половины до одного триллиона строк исходного кода. Исходя из того что создание конечной строки кода стоит от 10 до 100 долларов, я сделал вывод, что мы просто не можем позволить себе заново написать сколь-нибудь значительную часть имеющихся программ. Из этого следует, что нынешние языки и системы сохранятся достаточно долго. Аппаратное обеспечение во многом более подвижно, чем программное, поскольку мы всегда стремимся к созданию более быстрой платформы для работы старых программ.

Ядро UNIX действительно изменилось. Не всем это нравится, но Си по-прежнему остаётся одним из лучших языков для написания такого программного обеспечения, как AWK или ядро. Почему одни вещи оказываются долгожителями, а другие — нет?

Брайан: Отчасти выживание связано с тем, что эти программы действительно хорошо решают свою задачу. Си занимает прочную позицию среди языков программирования. Он чрезвычайно выразителен, но в то же время не слишком сложен или велик, а кроме того, написанные на нём программы эффективны, и это всегда будет иметь значение на каком-то уровне. С этим языком удобно работать, потому что если нужно что-то выразить, он предоставляет для этого не так много разных способов. Я посмотрю на ваш код и скажу: да, мне понятно, что он делает. Едва ли то же самое можно сказать о таких языках, как Perl и С++. Я посмотрю на ваш код и останусь в недоумении, потому что тут есть много способов написать одно и то же.

С++ сложен и огромен, и выразить что-либо можно многими способами. Если мы с вами будем писать на С++, то можем прийти к весьма разным способам описания какойнибудь большой задачи. В Си такого не бывает. Си сохранился потому, что у него оказалось хорошее соотношение выразительности и эффективности, и для важных приложений он остаётся лучшим инструментом.

Вот поэтому мы не заменили систему X Window в UNIX. Всюду используется Xlib или что-то, где используется Xlib. Какой бы вычурной ни была Xlib, она вездесуща.

Брайан: Именно так. Она делает своё дело, и достаточно хорошо. Переписывать её с чистого листа — слишком большой труд.

Теперь, если обратиться к С++ , то при его проектировании ставилась задача — ошибочная или нет — обеспечить обратную совместимость с Си. Теоретически, если вы хотите сделать нечто взамен X, оно должно незаметным для пользователя образом выполнять строки программ, написанных на X. С++ не вытеснил Си во многих областях, хотя номинально такая задача стояла.

Брайан: Бьёрн голову себе сломал, пытаясь добиться максимальной совместимости с Си. Одной из причин успеха С++ в сравнении с другими языками была хорошая совместимость на уровне как исходного, так и объектного кода, а это означало отсутствие необходимости полностью перестраивать работу, чтобы использовать С++ в среде Си.
За свои решения, связанные с совместимостью, Бьёрну наверняка приходится постоянно слышать упрёки, потому что людям не нравится то или иное. Но он принял эти решения совершенно сознательно, после долгих размышлений, потому что обеспечение совместимости имело важное значение и в итоге должно было оправдать себя.

Одним из крупнейших прегрешений считают чрезмерную близость к Си.

Брайан: Возможно, но чем дальше он отошёл бы от Си, тем меньше были бы его шансы на успех. Здесь трудно соблюсти правильную меру, и я думаю, что он очень хорошо справился со своей задачей.

В какой мере стремление к обратной совместимости препятствует новаторству и революционным преобразованиям?

Брайан: Такая дилемма возникает абсолютно всюду, и я не вижу способа её разрешить.

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

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

Наблюдается ли возрождение малых языков или его можно ожидать в будущем?

Брайан: Не думаю, что «возрождение» здесь правильное слово, но малые языки будут создавать и в будущем.

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

Питер Вайнбергер: Я бы процитировал — возможно, неточно — Эйнштейна: «Делайте как можно проще, но не проще того».

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

Самое простое, что сможет работать? По-моему, это сказал Кент Бек. Как добиться простоты и отказаться от того, в чём нет прямой нужды?

Питер: Это зависит от того, кто находится перед вами. Во многих случаях есть хорошая проверка: «Будет ли это понятно вашим родителям?» Не всегда это удаётся, но мне кажется, что это может быть хорошей отправной точкой. При более общей проверке стоит задуматься о тех, на кого рассчитана ваша функция: «Поймёт ли это средний пользователь?», а не «Найдутся ли пользователи, способные в этом разобраться?»

Влияет ли реализация на конструкцию языка?

Питер: Разумеется. Думаю, это заметно вне всяких сомнений. Мне кажется, например, что долгое время сборка мусора была относительно редким явлением. Ею занимались разработчики Лиспа и кое-кто из работавших в функциональном программировании, а все остальные лишь наблюдали, поскольку было неясно, как это сможет работать, скажем, в таких языках, как Си. Но потом разработчики Java объявили, что сделают это. Это был компромисс совершенно иного рода, в виде относительно небольшого изменения в характеристиках языка; я не утверждаю, что именно так произошло с Java, но, отказавшись от доступности фактических адресов памяти для программистов, можно было попробовать осуществить сборку мусора или сжатие сборщиков мусора и так далее.

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

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

Как выбор языка влияет на безопасность кода?

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

Кажется, какое-то время ходили слухи, что Microsoft при создании системы, превратившейся в Vista, собиралась всюду заменить Си и С++ на С#, после чего у вас не было бы никаких переполнений буфера, потому что их просто не могло быть. Но, конечно, этого не произошло. Взамен выполняемые модули на машинном языке подвергаются изощрённому контролю в надежде помешать применить переполнение буфера и аналогичные вещи.

Но есть ещё один вид проблем безопасности, появляющихся на стыке между программами из-за того, что ряд интерфейсов определён не очень корректно или весьма неформально, — таких как межсайтовый скриптинг для HTTP и XML и аналогичные. С безопасностью нужно что-то делать, но что — я не знаю.

Есть ли польза от того, что язык препятствует возникновению определённого рода ошибок?

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

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

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

Они служат фактором эффективности.

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

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

По моему «скромному, но верному» мнению, некоторые языки обладают рядом характеристик, облегчающих написание кода, но очень осложняющих его сопровождение. Особенно отличаются этим практически все объектно-ориентированные языки.

Никто не рассчитывал, что его код проживёт 30 лет. Если бы вы сказали, что к тому времени UNIX будет ещё жива или Фортран будет ещё жив, каждый ответил бы: да, и мы перепишем их заново. Таков был наш образ жизни. Ты это написал, ты это и будешь переписывать. С каждым разом всё лучше, и каждый раз добавляя несовместимости, пока не падёшь жертвой эффекта второй системы, когда продукт становится очень слабо совместимым и значительно хуже. Теоретически нам была понятна мысль, что есть только два вида программных проектов: либо провалившиеся, либо ставшие кошмаром сопровождения.

Мы не понимали, что невозможно год за годом продолжать писать программы и при этом переписывать их заново. Объём программного обеспечения растёт, и либо вы будете заниматься только переписыванием старых программ, либо оставите их такими как есть. За всем не угнаться. Проблема сопровождения выглядит всё более грозно, хотя говорю это потому, что у меня много времени уходит на неё в Google, где она кажется мне довольно серьёзной.

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

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

Замкнутость

Язык должен быть определён в терминах модели данных, состоящей из набора объектов с чётко определёнными свойствами. Для каждого оператора языка должны быть определены его операнды и результат в виде объектов модели данных. Семантика каждого оператора должна определять результат действия этого оператора на все свойства участвующих в его работе объектов.

Полнота

Для каждого объекта модели данных должны иметься операторы, которые его создают, разлагают на элементарные части (если они есть) и сравнивают с другими объектами того же типа.

Ортогональность

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

Единообразие

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

Простота

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

Расширяемость

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

Абстрагирование

Язык не должен демонстрировать особенности конкретной реализации или зависеть от неё. Например, удаление дубликатов из группы значений должно описываться в терминах абстрактной концепции, такой как «первичный ключ», а не физической стратегии, такой как «уникальный индекс». (В ранних версиях SQL такая ошибка присутствовала.) В области баз данных это понятие иногда называют «независимостью данных».

Возможность оптимизации

Язык не должен налагать ненужные ограничения на алгоритмы выполнения его выражений. Например, определение языка должно допускать некоторую свободу в порядке вычисления предикатов. Семантическая спецификация языка должна по возможности быть декларативной, а не процедурной, чтобы предоставить возможность автоматической оптимизации. Иногда лучше смириться с некоторой недетерминировавностью (например, при обработке какого-то запроса ошибка может генерироваться или нет в зависимости от порядка вычисления предикатов).

Эластичность

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

И для Objective-C, и для C++ отправной точкой является Си, но направления их дальнейшего развития весьма различны. Какой подход вы предпочли бы сегодня?

Том Лав: Есть удачное направление, и есть тот подход, который Бьёрн выбрал для C++. В одном случае появился небольшой, простой и, осмелюсь сказать, элегантный язык программирования, очень чёткий и ясный. В другом случае мы имеем весьма некрасивый, запутанный, сложный язык с рядом весьма мучительных особенностей. Думаю, в этом и состоит разница между ними.

Вы считаете, что С++ в каких-то отношениях слишком сложен?

Том: Несомненно.

Он продолжает развиваться. В него до сих пор добавляют новые возможности.

Том: Давайте разберёмся. Мне лично нравится работать с достаточно простыми языками. APL — прекрасный язык программирования, потому что он невероятно прост и чрезвычайно силён в определённого рода приложениях. Если мне нужно написать статистический пакет, то APL — классный язык для такой задачи, потому что я не знаю языка, который лучше него справляется с алгебраическими операциями над матрицами. Это всего лишь один пример.

Как вы думаете, почему C++ используется чаще, чем Objective-C?

Том: Потому что за ним стояла AT&T.

Только и всего?

Том: Думаю, да.

Что вы думаете о сегодняшнем Objective-C?

Том: Он до сих пор жив. Этого мало?

В Objective-C 2.0 появилось много интересных возможностей — он явно пользуется поддержкой Apple.

Том: Недавно я разговаривал с человеком, который пишет программы для iPhone, Он сказал, что скачал Developers Kit для iPhone, и тот целиком состоит из Objective-C. Жив язык.

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

Том: Мы впервые познакомились с Брэдом, когда я взял его на работу в группу перспективных исследований для телефонной отрасли — ITT. Нам была поставлена задача заглянуть на 10 лет вперёд. Один из полученных выводов: мы плохо умеем прогнозировать на 10 лет вперёд, в особенности в области ПО. Мы хорошо предсказывали развитие аппаратных технологий на 10 лет вперёд, но ошибались на 10 лет в отношении программ. То есть события, которых мы ожидали к 1990 году, в действительности случались на 10 лет позднее.

Даже в конце 1990-х люди продолжали с недоверием относиться к идеям Лиспа и других языков, успешно применявшимся в них уже 30 или 40 лет.

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

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

С аппаратным обеспечением положение такое же?

Том: Думаю, там нет таких различий в знаниях.

Почему развитие аппаратного обеспечения мы можем предсказывать на 10 лет вперёд, а ПО — нет?

Том: У нас есть хорошие данные для аппаратуры, которые можно измерить количественно. Для программ таких количественных мер нет.

Как вы полагаете, можно ли наращивать и развивать язык?

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

Как вы решаете вопрос о добавлении в язык той или иной функции?

Том: Необходим минимум функций, обеспечивающий максимум функциональности и гибкости.

У меня есть книга Smalltalk 80 издания 1983 года. Похоже, работы тут больше, чем на неделю, но сам компилятор не очень сложен.

Том: Да, не очень. Языки со строгим обоснованием не бывают очень сложными. Напротив, можно себе представить, что компилятор C++ окажется весьма уродливой вещью, потому что язык неаккуратный. В нём полно всяких специфических и необычных конструкций, не вполне согласованных между собой, и это проблематично.

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

Том: Думаю, это разумный подход. Я бы начал с нескольких примеров действительно простых и действительно чётких языков, и первое, что тут приходит на ум, это Smalltalk и APL. Вероятно, можно вспомнить и другие.

Если бы сегодня вы начали проектировать новый язык, каким бы он стал?

Том: Учтите, что я готов расширять техническое разнообразие только в тех случаях, когда это совершенно необходимо. Я бы начал с вопроса: «А так ли уж мне действительно совершенно невмоготу без такого языка?».

Я не испытываю потребности в новом языке. Большую часть своего времени я размышляю о проблемах, возникающих ещё до того, как будет написана первая строчка кода.

Что можно сказать о модульности проекта?

Том: Чем лучше спроектирована система, чем она более модульна, тем, по всей вероятности, лучше объектная модель этой системы, тем дольше она будет полезна.

Вы по-прежнему моделируете свои системы с помощью шариков из полистирола, представляющих отдельные классы?

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

Я подсчитал, что мы делали это в 19 проектах. В одном из них было 1856 классов, что очень много — возможно, больше, чем следовало. Это был крупный коммерческий проект, так что всё должно было быть крупным.

Как вы оцениваете простоту проекта?

Том: В прежние времена была такая оценка, как количество страниц с БНФ, описывающими язык, и она была неплохой, потому что она позволяла различать сложные и простые языки.

Если взглянуть под определённым углом зрения на программу на APL или Smalltalk, язык перестаёт быть виден. Он как бы исчезает, и это хороший признак.

Насколько велико справочное руководство по языку? Что в него включено? Язык Objective-C не очень сложен, но сложны написанные на нём библиотеки, накопившиеся с годами. Описывать их во всех деталях — трудно, громоздко и чревато ошибками. Сложно тестировать, сложно документировать.

Даже у такого простого языка, как Си, может быть сложная семантика — кто отвечает за управление памятью для данной конкретной библиотеки?

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

Какой самый полезный совет вы могли бы дать на основании своего опыта?

Том: Могу укоротить его до четырёх слов. Делайте интересные новые ошибки.

Не нужно переворачивать всю историю, но посмотрите на пройденный путь. Много ли вы знаете 25-летних выпускников компьютерной специальности, написавших хоть одну программу на APL?

Думаю, их почти нет. А ведь это важные знания, потому что это, конечно, специализированный язык для приложений определённого рода, но, думаю, опытный APL-программист при написании статистического приложения заткнёт за пояс любого, кто попытается работать с каким-то другим языком.

Я беседовал с некоторыми людьми из Института программирования по поводу того, как сейчас учат программистов, если считать, что этим вообще кто-то занимается, и как мало программ для получения степени, где сознательно стараются научить людей, как создавать системы, а не просто разрабатывать алгоритмы. Думаю, здесь у нас есть упущения.

Почему вы решили расширять уже существующий язык, а не создали новый?

Брэд Кокс: Меня вполне удовлетворял Си, не считая известных, но терпимых ограничений. Изобретать базовый язык для ООП было бы пустой тратой времени.

Почему вы остановились на Си?

Брэд: Потому что у нас не было ничего другого. Ада — это нечто немыслимое, Паскаль считался игрушкой для учёных. Оставались Кобол и Фортран. По-моему, всё сказано. Ах, да, был ещё Chill (язык для телефонии). Единственной разумной альтернативой для Си был Smalltalk, но Xerox не рассталась бы с ним.

Нашей задачей было перенести ООП из исследовательской лаборатории в заводские условия. Единственным надёжным вариантом был Си.

Зачем понадобилось эмулировать Smalltalk?

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

Что вы думаете о сборщиках мусора?

Брэд: Это замечательная вещь. Всегда так считал. Мне приходилось сражаться с маркетологами, которые считали это «особенностью» языка, которую можно без особых хлопот подрисовать к Си, не потревожив тех, кто выбрал Си из-за его эффективности.

Почему в Objective-C запрещено множественное наследование?

Брэд: Историческая причина состоит в том, что Objective-C является прямым потомком Smalltalk, где тоже не поддерживается множественное наследование. Если бы мне сегодня предоставилась возможность пересмотреть то давнее решение, то, возможно, даже одиночного наследования не осталось бы. Наследование не играет большой роли. Инкапсуляция — вот в чём главный вклад ООП.

Ваш проект, видимо, повлиял на Java, поскольку одиночное наследование было перенесено и туда. А из Java тоже можно было бы удалить одиночное наследование?

Брэд: Вероятно, да. Но этого не должно быть и не будет. Оно там есть, оно работает, и оно оправдывает своё назначение. Просто им иногда злоупотребляют, как и любыми возможностями языка, и оно не так важно, как инкапсуляция.

Сначала я активно использовал наследование, чтобы оценить пределы его применения. Затем я понял, что настоящим достижением ООП является инкапсуляция, и с её помощью можно вручную сделать почти всё, для чего я применял наследование, но более понятным образом.

С тех пор моё внимание было перенесено на объекты с более высоким уровнем детализации (OOP и JBI/SCA), которые, заметьте, вообще не поддерживают наследование.

Иногда разработчики языка начинают с описания маленького формализованного ядра, а затем на этом фундаменте возводят язык. Вы подошли к созданию Objective-C так же — или решили позаимствовать всё, что можно, у Smalltalk и Си?

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

Я видел, что все заняты языками, то есть паяльниками, и никого не интересуют компоненты. Мне показалось, что этот подход устарел. Оказывается, очень важно то, почему у производителей чипов было такое видение: кремниевые компоненты состоят из атомов, и есть бизнес-модель для их покупки и продажи. Для программных компонентов такая бизнес-модель в действительности оказывается очень недолговечной.

Всё программное обеспечение недолговечно.

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

SOA поддерживает объекты крупной детализации, размещаемые в сети и по необходимости параллельные, поскольку обычно они располагаются на разных машинах. JBI Sun и SCA OASIS усиливают эту модель посредством объектов/компонентов большей детализации, из которых собираются объекты SOA. Это первое проявление в разработке ПО подхода с различной степенью детализации, являющегося нормой в разработке аппаратуры: мелкие объекты (логические элементы) собираются в средние (чипы, «программные ИС»), которые собираются в более крупные объекты (карты), которые... и так далее. Главное отличие в том, что в материальных областях системы действительно фрактальны и имеют гораздо больше уровней, а у нас их всего три. Пока.

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

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

Брэд: Вы правы — если под ООП понимать инкапсуляцию в стиле Objective-C/Java, которую в своей второй книге «Superdistribution» (Addison-Wesley Professional) я назвал интеграцией на уровне чипов. Но если рассматривать интеграцию на уровне чипов лишь как один уровень в комплекте средств многоуровневой интеграции, являющемся нормой при проектировании аппаратных средств, то объекты уровня логических элементов гармонично вписываются в фрактальный мир инкапсуляции уровней чипов, карт и выше.

Именно поэтому я занялся сегодня SOA (уровень шасси) и JBI (уровень шины). Они поддерживают инкапсуляцию на том же уровне, что и традиционное ООП. И даже выше: они инкапсулируют не только данные+процессы, но и весь свой поток управления.

Самое замечательное то, что многоуровневая интеграция не стоит вам ничего и показала свою пригодность, будучи использована в любых масштабах в других областях производства. Единственная зацепка — в трудности убедить сторонников одноуровневого ООП. Всё это мы видели — борьбу ООП и традиционного процедурного программирования, а сегодня — SOA с JBI и Java.

Все верят мифу о том, что новые технологии делают «устаревшими» старые, такие как ООП. Этого никогда не было и не будет. Новое всегда вырастает поверх старого.

Похоже, мы вступаем в эру экспериментов с языками и готовности программистов опробовать непривычные для них технологии вроде Rails и функционального программирования. Какие уроки из своей работы над Objective-C вы могли бы предложить модернизаторам и авторам языков?

Брэд: Я пытался, но не вполне успешно, понять синтаксис таких языков, как Haskell, — по крайней мере, не настолько успешно, чтобы составить твёрдое мнение о нём. Я довольно активно применяю XQuery, а это функциональный язык. И я считаю, что читать XQuery гораздо приятнее, чем XSLT.

Мне кажется, я умею осваивать новые методы, но что касается Haskell, то я просто не могу понять его синтаксис. Примерно та же проблема была у меня с Лиспом. Тем не менее на меня произвёл впечатление проект для военно-морского флота, в котором сложная политика авторизации и аутентификации была выражена в виде правил Haskell, допускающих проверку.

Я вижу будущее не в том, чтобы непрерывно множить всё новые и новые нотации для одной и той же работы, которой мы занимаемся десятилетиями, — написания процедурного кода. Это не означает, что работа на таком уровне не имеет значения: из неё в конечном итоге возникают компоненты более высокого уровня, и тут вряд ли что-то изменится. Я только хочу сказать, что новые способы написания процедурного кода — это не передний край инноваций.

Что я нахожу увлекательным, так это появление новых видов нотации для совершенно нового занятия, а именно для составления систем более высокого уровня из библиотек существующих компонентов. Конкретным примером служит BPEL, допускающий применение на двух уровнях интеграции: SOA для объектов крупной детализации и JBI (Sun) или SCA (OASYS). Посмотрите, например, редактор BPEL в NetBeans. В этой области OMG проделала отличную работу с архитектурой, управляемой моделями.

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

Брэд: Многоуровневая интеграция (она же инкапсуляция) интересовала меня, сколько я помню, всегда: разбить работу на части и поручить их специалистам, затем воспользоваться тем, что они сделали, не нарушая или почти не нарушая инкапсуляцию, знать, «что внутри», чтобы успешнее применять.

Меня не удовлетворяет в Си (и подобных ему языках) то, что на программистов полностью обрушивается вся сложность программы, за исключением небольшой её части, инкапсулированной в функциях. Единственной действительной границей инкапсуляции было всё пространство процесса, что равносильно чрезвычайно эффективной капсуле верхнего уровня, интенсивно используемой в UNIX в виде двухуровневой инкапсуляции посредством скриптов оболочки и понятия «каналов и фильтров».

В попытках объяснить преимущества объектно-ориентированного программирования я часто пользовался термином Software-IC (программные ИС), чтобы обозначить новый уровень интеграции, более крупный, чем функции Си (уровень логических элементов), и меньший, чем UNIX-программа (уровень шасси). Главным мотивом разработки Objective-C явилось для меня желание сделать простой программный паяльник, чтобы собирать большие функциональные блоки (уровня шасси) из многократно используемых «программных ИС». Напротив, C++ возник из совершенно другого представления: огромная автоматизированная фабрика для изготовления тесно связанных блоков из элементов уровня логических узлов. Если интерпретировать метафору аппаратуры для программирования, то интеграция на уровне чипов происходит только на этапе компоновки; интеграция на уровне логических элементов — на этапе компиляции.

Большие перемены произошли потом в связи с появлением «вездесущих систем», открывших новые уровни интеграции, более крупные, чем пространство процесса UNIX. Например, в архитектуре, ориентированной на сервисы (SOA), интернет представляет собой нечто вроде проводов между компонентами HiFi-системы, а сервисы (программы) на отдельных серверах сами функционируют как компоненты. Я считаю, что это невероятно интересно, поскольку это первый уровень интеграции, аппроксимирующий естественное для повседневной жизни распределение обязанностей.

Поможет ли строительство систем из мелких «кирпичиков» избегать в будущем проблем с устаревшим программным обеспечением?

Брэд: Я убеждён в силе компонентного подхода, но не хочу излишне навязывать эту идею: компоненты решают не все проблемы. Компоненты — это изобретённый нами способ решения задач объёма выше среднего: что-то из того, чем мы отличаемся от шимпанзе. Мы открыли, что можно решать задачи, просто перекладывая их на чужие плечи. Это называется разделением труда, только и всего. Вот этим люди отличаются от шимпанзе, которые до такого не додумались. Они умеют делать инструменты, у них есть язык для общения, поэтому, на первый взгляд, люди и шимпанзе мало отличаются друг от друга. Мы открыли способ решения проблем путём перекладывания их на других — посредством экономической системы.

Как можно улучшить качество ПО?

Брэд: Один из путей — хранить ПО на серверах, как в схеме «ПО как сервис» (Software as a Service, SaaS). Есть надежда, что такая система окажется экономически эффективной, хотя очевидно, что при этом пострадают определённые аспекты (секретность, безопасность, производительность и так далее).

Есть другое экономическое решение, сегодня весьма широко распространённое: реклама. Здесь пользователи не являются ни охотниками, ни добычей: они — приманка. Несмотря на успех Google, полагаю, этот путь не приведёт ни к чему хорошему. Мы все свидетели того, к чему привела эта модель на радио и телевидении, и точно то же самое происходит с интернетом.

Последним вариантом остаётся модель open source в каких-то из её многочисленных вариантов и разновидностей — бесплатного, условно-бесплатного, добровольно оплачиваемого и так далее ПО. Сегодня я в основном работаю над этой моделью. Не потому, что лучше неё ничего нельзя придумать, а потому, что других не осталось, и она решает одну из проблем, в которых виновато само Минобороны: замкнутость на проприетарности.

Что мешает нам создавать программные объекты такого же качества, как «реальные»?

Брэд: Экономическая система вознаграждения за усовершенствования.

Вы считаете, что для повышения качества ПО нужны лучшие стимулы?

Брэд: Если вы посмотрите, благодаря чему повысилось качество носков, свитеров и булочек Twinkie, то увидите, что двигателем этой системы служит экономика. Именно негодная экономика ПО — причина его нынешнего примитивного уровня развития.

Фармацевтическая компания тратит миллиарды долларов на исследования, потому что от продажи лекарств, появляющихся в их результате, она получает десятки и сотни миллиардов. В их науке присутствует сильный монетарный фактор, хотя значительная часть исследований ведётся открыто.

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

Влияет ли университетское образование на ваши взгляды, касающиеся разработки ПО?

Брэд: Несомненно. Постоянно.

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

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

У ПО есть постоянная проблема прав собственности и вознаграждения за продукты и труд.

Не сместился ли интерес исследований компьютерной науки из академической сферы в производственную?

Брэд: Никогда не считал себя «учёным в области компьютерных наук» или академическим работником (хотя и проработал какое-то время в этой сфере). Всё остальное время я работал в условиях производства и, естественно, отдаю предпочтение ему.

При этом успехи академических исследований не производили на меня впечатления до недавней поры, когда я заметил растущее академическое участие в таких организациях, как W3C, Oasis и других, занимающихся выработкой стандартов. С моей точки зрения, это замечательно.
Мне нравится следующая цитата с virtualschool.edu:

"Таким образом, компьютерная наука не мертва. Она просто никогда не существовала".

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

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

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

Каковы недостатки наших способов обучения разработке ПО?

Брэд: Лично я, занимаясь преподавательской работой, пытался информировать слушателей о недостатке надёжных экономических рычагов, влияющих на качество ПО. Как правило, экономические вопросы отсутствуют и игнорируются в учебных программах по компьютерным наукам и программированию, им не уделяется никакого внимания.

Как вы узнаёте простоту?

Андерс Хейлсберг: Есть настоящая простота, а есть ложная — то, что я называю «simplexity» и с чем часто встречаюсь. Это когда сначала строят нечто сверхсложное, а потом говорят: «Нет, в этом никто не сможет разобраться; это слишком сложно, но мы должны сохранить всю мощь нашей конструкции; попробуем построить поверх неё простую систему; обернём это всё в какой-нибудь простой интерфейс».

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

Стали бы вы придерживаться такого принципа, если бы вам сегодня пришлось создавать новый язык?

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

Часто люди совершают ошибку, создавая новый язык, потому что они одержимы некоторой конкретной задачей, которую хотят решить. Возможно, язык программирования поможет решить эту задачу, поэтому они начинают с него и часто делают отличную работу. Но каждый язык программирования — подчёркиваю, каждый — на 10% состоит из нового и на 90% из обычных для программирования вещей, которые просто обязаны в нём быть. И все эти новые изобретательные решения, которые вы встречаете в новых языках программирования, замечательны в своих 10% нововведений и ужасны в тех 90%, которые должны быть в каждом языке, чтобы на нём действительно можно было писать программы, и потому оказываются неудачными.

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

Какой язык вы стали бы создавать: универсальный или для конкретной области?

Андерс: Думаю, ни тот и ни другой. Я постарался бы создать универсальный язык, пригодный для создания проблемно-ориентированных языков. Опасность, подстерегающая нас при создании языков для конкретных предметных областей, заключается в том, что со своей областью они могут справляться хорошо, а с универсальностью у них оказывается плохо. Есть несколько универсальных функций, необходимых буквально каждому языку для конкретной области. Если только проблемно-ориентированный язык не оказывается чистым языком описания данных, но тогда, мне кажется, с таким же успехом можно использовать XML.

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

Одна из проблем современных универсальных языков программирования в том, что они становятся более пригодны для создания внутренних проблемно-ориентированных DSL, и в качестве примера можно рассматривать LINQ. А плохо в них в данное время то, что с паттернами применения этих внутренних DSL они справляются слабо. В каком-то смысле, создавая внутреннюю DSL, вы фактически хотите ограничить возможности универсального языка программирования. Вам нужно отключить универсальность языка и оставить её только в некоторых местах своей DSL. Это один из недостатков современных универсальных языков программирования. Видимо, стоило бы этим заняться.

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

Андерс: Это так. Кажется, Гослинг сказал, что все файлы конфигураций в конечном счёте превращаются в отдельные языки программирования. Это верно замечено, и об этом всегда нужно помнить.

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

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

Вы сказали, что платформа в чём-то важнее языка. Будем выпускать компоненты для многократного использования?

Андерс: Я сказал это потому, что если посмотреть, как в последние 25-30 лет развивались языки, инструменты и программные среды, то бросается в глаза, как мало изменились языки программирования. В той же мере удивительно, как выросли за это время среды программирования и исполнения. Они выросли, наверное, на три порядка по сравнению с тем, какими были 25-30 лет назад. Когда я начинал работать с Turbo Pascal, в библиотеке времени исполнения было 100 или 150 стандартных функций, и всё. Сейчас у нас есть среда .NET, в которой 10000 типов и 100000 членов. Очевидно, что важность повторного применения этой работы неуклонно растёт. Важность обусловлена тем, что это определяет наше представление о задачах, но важность среды растёт, потому что это то, что мы многократно применяем в своих программах.

Повторное использование — это сегодня всё. С точки зрения программирования, ваш компьютер — бездонная яма. Вы можете всю жизнь писать для него код, и он никогда не наполнится. Возможности его огромны, а конечные пользователи ждут ещё большего. Единственный путь к успеху сегодня — это поиск умных способов повторного использования уже сделанной работы. 25-30 лет назад такой проблемы не было. Когда у вас 64К памяти, её можно заполнить за пару месяцев.

В какой мере продуктивность программиста определяется языком и способностями?

Андерс: Думаю, то и другое тесно связаны. Язык влияет на то, как мы думаем. Работа программиста состоит, если хотите, в том, чтобы думать. Это сырьё, чистая энергия, участвующие в процессе. Язык — это то, что определяет ваше мышление; его задача — помочь вам думать продуктивным образом. Например, языки с поддержкой объектов заставляют вас думать над задачей так. Функциональные языки заставляют вас думать над задачей иначе. Динамические языки заставят вас думать ещё как-то. Выбрав язык, вы выбираете особый способ мышления. Иногда бывает полезно принять сразу два способа мышления и рассмотреть задачу с разных точек зрения.

Кстати, как вы отлаживаете код С#?

Андерс: Мой главный инструмент отладки — Console.Writeline. Честно говоря, думаю, так работают многие программисты. В более сложных случаях я применяю отладчик — если нужно сделать трассировку стека, посмотреть локальные переменные и так далее. Но очень часто можно быстро добраться до сути с помощью простых маленьких проверок.

Есть ли принципы, которых вы придерживаетесь при разработке API?

Андерс: Ну, прежде всего скажу, что они должны быть проще, но что это значит? Звучит глупо, правда? Я твёрдо верю в то, что API должны содержать как можно меньше методов и как можно меньше классов. Есть люди, которые считают, что больше значит лучше. Я не из их числа. Я считаю, что важно определить, для чего, как вам кажется, чаще всего будут использовать ваш API. Определите пять возможных типичных сценариев работы пользователей и сделайте так, чтобы API был для них максимально прост. В идеале — чтобы было всего одно обращение к API. Не должно быть так, чтобы в обычном сценарии приходилось писать много строк обращений к API. Это указывает на плохой уровень абстракции.

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

Что вы думаете о документации?

Андерс: В целом состояние документации для ПО ужасно. Я постоянно убеждаю программистов и пытаюсь проповедовать это у себя, хотя и не всегда успешно, что ценность поставляемого вами клиенту продукта наполовину состоит из хорошей документации по API. Самый замечательный API бесполезен без документации, описывающей, что он делает и как им надо пользоваться. Это проблема. Во множестве компаний одни люди пишут код, другие документацию, и те и другие между собой не общаются. В итоге в документации вы видите «MoveWidget перемещает виджет» или пространное описание очевидного. Это безобразие. Программисты должны писать больше документации, чем делают это сейчас.

Что вы считаете главными проблемами компьютерных наук?

Андерс: Если даже взглянуть выше, на метауровне, то постоянной тенденцией в развитии языков является неуклонный рост уровня абстракции. Если посмотреть на весь путь от коммутационных панелей и машинного кода до символического ассемблера, Си, С++, а теперь и управляемых исполнительных сред, то с каждым шагом мы поднимались на новый уровень абстракции. Главная задача — всегда искать очередной уровень абстракции.

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

Кроме того, сейчас много говорят о проблемно-ориентированных языках и ме-тапрограммировании. По-моему, здесь больше разговоров, чем дел. Едва ли нам сейчас известны решения. Есть «аспектно-ориентированное программирование», есть «интенциональное программирование», но решение пока не найдено.

Одни вам скажут, что у нас нет проблемно-ориентированных языков, другие — что их у нас полно. Мы не можем даже договориться по поводу того, что такое проблемно-ориентированный язык, но ясно, что это связано с попытками разработать более декларативные способы высказываний. В некоторых отношениях императивный стиль программирования исчерпал себя. Со своими императивными языками программирования мы далеко не уйдём. Не стоит надеяться, что, добавив несколько новых операторов, мы увеличим свою продуктивность сразу в 10 раз.

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

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

Есть ли проблемы в объектно-ориентированной парадигме?

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

В этом смысле у ООП проблема, но вы можете применять его и к неизменяемым объектам. Тогда таких проблем не возникает. Например, нечто похожее происходит в функциональных языках.

Какие уроки можно извлечь из вашего опыта?

Андерс: Если взять первый продукт, над которым я трудился, Turbo Pascal, то для него очень характерно желание не идти стандартными путями. Не нужно бояться. Если вам говорят, что этого сделать нельзя, это не всегда означает, что это действительно невозможно. Это просто значит, что они не знают, как это сделать. Я считаю, что всегда интересно думать нестандартно и искать новые решения для старых проблем.

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

Думаю, чтобы достичь успеха в любом деле, нужно очень его любить. А этому научиться нельзя. Это либо есть, либо нет. Я занялся программированием не потому, что рассчитывал заработать много денег или кто-то меня к этому принуждал. Я занимался этим делом, потому что был совершенно им поглощён. Меня невозможно было остановить. Я ничего другого не хотел, кроме как писать программы. Я был очень, очень увлечён этим.

Чтобы достичь совершенства в чём-либо, необходима страсть, именно она заставит вас отдавать любимому делу всё своё время, а время — это ключ ко всему. Нужно вложить очень много труда.

Каким должен быть подход к преподаванию компьютерных наук?

Айвар Якобсон: Проблема в том, что у большинства университетских преподавателей очень слабое представление о технологии. Мало кто из них сам разработал какую-нибудь полезную программу. Бывает, кто-то из них разработал компилятор, но их компиляторы обычно слишком теоретичны. Бывает, что они пишут программы, облегчающие преподавание. Нельзя рассчитывать на то, что они смогут преподавать технологию создания ПО.

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

Действительно сложным вещам в университете не научишься.

Должны ли студенты получать больше практического опыта, например участвуя в проекте open source или проходя практику в крупной компании?

Айвар: Обучение в университете происходит преимущественно путём получения образования и разработки простых программ.

Мы действительно не учим людей технологиям. Создание ПО — в большей мере технология, нежели искусство. Многим хотелось бы, чтоб было иначе, но заниматься искусством могут позволить себе лишь очень немногие профессиональные программисты. Остальные — инженеры. Это не значит, что их работа не творческая. Разве кто-то будет утверждать, что те, кто получил образование в области машиностроения и, скажем, умеют создавать различные механизмы, занимаются не творческой работой? Разве построить корабль — не творчество? Или дом? Конечно, творчество. И архитектор — тоже очень творческая профессия.

Таким образом, мы должны осознать, что разработка ПО — это инженерная работа, а не искусство. Инженеров нужно учить инженерному делу. Тем не менее во многих университетах США и Европы существует давняя традиция, в соответствии с которой преподавание ведётся в чисто академическом стиле. Я вижу фундаментальную проблему в том, что у нас нет настоящей теории для программной инженерии. Для большинства людей программная инженерия представляется набором идей для конкретных случаев. Это одна из главных проблем, которые мы должны решить.

Пожалуйста, поясните, почему вы считаете эту проблему такой важной.

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

Последняя тенденция — гибкая (agile) разработка, воплощённая в Scrum. Это движение напомнило нам, что первое и главное в разработке ПО — люди. Здесь нет особой новизны: данная тема всплывает примерно раз в десять лет, когда наивные менеджеры пытаются механизировать и коммерциализировать то, что по существу является упражнением в творческом решении задач. Важно, чтобы мы не забывали, как работать в составе команды, как документировать свою работу, как планировать её на день, на неделю, на месяц, и так далее. Но когда мы снова обращаем своё внимание на эти вещи, многое теряется или затемняется новыми названиями для старых вещей, создавая иллюзию полной новизны.

В результате напрасно тратится много труда, когда заново открываются и перелицовываются старые истины. Молодые и менее опытные сотрудники поддерживают новые тенденции, следуя за новыми гуру, в сопровождении рекламной шумихи в СМИ, всегда охочих до «новостей». Менеджеры, утратившие контакт с настоящими разработками, оказываются в безнадёжном положении: сопротивляясь «новейшим веяниям», они выставляют себя как ретрограды. Запускаются опытные проекты, которые должны быстро подтвердить достоинства нового подхода, но когда масштабы ограничены, воодушевлённые разработчики могут заставить работать что угодно. В результате старый метод побеждается новым, и на помойку выбрасывается как то, что работало в старом подходе, так и то, что не работало. С большим опозданием обнаруживается, что новый подход тоже в одних местах работает, а в других — нет.

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

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

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

Почему так медленно удаётся улучшать методы и процессы программирования?

Айвар: Это серьёзный вопрос. Думаю, наша отрасль ещё очень незрелая. Она чуть более зрелая по сравнению с тем, что было 20 лет назад, но сегодня мы создаём гораздо более сложные системы. Двадцать лет назад у нас были язык программирования и операционная система, сейчас же существуют всевозможные вычислительные среды.

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

Новые популярные методологии сегодня не слишком отличаются от тех, которые у нас были 20 или 30 лет назад, но у них новые акценты, и мы иначе обсуждаем их. Мы также наблюдали противодействие крупным и вполне удачным процессам, таким как CMMI и RUP. Противодействие выражается в осуждении всего, что относится к этим и аналогичным движениям, и в пропаганде чего-то нового и свежего, хотя на самом деле оно не новое и не свежее. Эти «новые методологии» по сути не новшества, а варианты того, что у нас уже было.

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

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

Как можно решить проблему устаревшего ПО?

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

Если в какой-то фирме все люди уволятся одновременно, фирмы не станет. Даже если у вас есть деньги, чтобы нанять новых работников, они не будут знать, что им делать. Создание ПО в этом отношении не является исключением. Такова природа бизнеса. Хорошо, если новые люди смогут разобраться в вашей системе, но чудес ждать не стоит.

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

В какой мере понимание программных технологий связано с конкретными языками программирования?

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

Сейчас у нас появились среды программирования, но изучить среду гораздо труднее. И всё же это относительно просто: это лишь одна из нескольких вещей, которые требуется знать, чтобы стать хорошим разработчиком ПО. Мы должны поднимать наш уровень знаний в программной инженерии.

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

Айвар: Да, и нельзя выбрасывать накопленное. Начните с того, что у вас уже есть. У каждого, кто сегодня пишет программы, есть какие-то практики, которые могут быть не столь хороши, но всё же полезны. Нужно не пытаться изменить всё сразу, а совершенствовать то, что больше всего в этом нуждается.

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

Я читал, что вы предвидите, как в будущем умные агенты будут нашими партнёрами в парном программировани. Каким образом?

Айвар: Разрабатывать ПО не бог весть как сложно. Взгляните на те 5-10 миллионов человек, которые считают себя разработчиками ПО. Очень немногие из них действительно могут творить и предлагать нечто совершенно новое. К несчастью, окружающие считают программистов творческими и талантливыми людьми, а это далеко не так.

Есть научные данные, которые говорят, что сегодня 80% труда программистов в течение рабочего дня — разные обычные и совсем мелкие действия — не являются умственной работой. Они выполняют то, что делали уже 50, 100, 1000 раз прежде. Они действуют по шаблону в новых условиях.

Конечно, творческая работа существует, но большинство ею не занимается. Умственная работа составляет 20%. Даже она оказывается не слишком сложной: просто приходится подумать иначе, чем привыкли думать раньше.

80% работы ведётся по правилам. В некотором конкретном контексте можно применять один шаблон за другим, создавая ПО.

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

Можно описать эти правила и применять их с помощью инструментов. В этом состоит идея умных агентов. Умные агенты знают контекст и что в нём нужно делать, и они это делают. Они могут многое делать сами, если нужно применять простые правила, или могут спросить совета у разработчика, с которым работают.

Основанная мной компания Ivar Jacobson International разработала умных агентов для создания ПО и достигла поразительных результатов. Tata Consulting Services с помощью довольно небольшого набора правил сократила затраты на 20%. Выросло качество и сократилось время обучения программистов и разработчиков. Новые сотрудники быстро начинали работать в полную силу.

Я не сомневаюсь в действенности этой технологии. Проблема в существовании большого числа разных платформ и инструментов, которыми хотят пользоваться. Если вы хотите разработать такое ПО, вам придётся приспособить его к различным инструментам и разным видам платформ, поэтому маленькой фирме трудно разработать свои агенты. Другое дело в масштабах крупной компании, такой как TCS.

Потенциально, с помощью технологии умных агентов можно сократить издержки на 80%. У нас, например, умные агенты применяются для описания сценариев использования, разработки сценариев использования, тестирования сценариев использования и так далее. И это только начало. Не сомневаюсь: здесь есть технология, есть задача, есть деньги.

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

Айвар: Думаю, всё большую часть работы будет выполнять сообщество пользователей, а не программисты. Один из путей к этому — программирование на основе правил. Оно позволяет не вникать в то, как происходит выполнение: вы просто пишете свои правила. Затем их интерпретирует некий движок. Этот подход не содержит принципиальной новизны, поскольку проповедуется сообществом ИИ уже 40 лет. Объектная технология позволила нам лучше понять, как строить средства моделирования. Лет 20 или 30 назад системы на базе правил были монолитными и очень негибкими. С агентами мы получаем некую объектно-ориентированную экспертную систему, которую гораздо легче модифицировать.

Как вы распознаёте простоту?

Айвар: Простота — это главная составляющая того, чтобы быть умным, делать что-то с умом, да и вообще ума. Эйнштейн сказал что-то вроде «всё должно быть как можно более простым, но не проще того». Полностью согласен. Это я и называю умом.

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

Например, составлять заранее технические требования и пытаться определить все требования, ещё ничего не реализовав, не умно. Умным будет определить основные сценарии использования или главные функции и начать их реализовывать, чтобы получить какие-то ответные данные. Я нашёл 10-15 таких случаев умных действий.

Мы должны начать вести себя с умом, разрабатывая ПО. «Умное» программирование — это развитие гибкого. Методология Agile в основном связана с социальной психологией, хотя к ней добавили ещё многое. Не нужно быть умным, чтобы быть гибким, но чтобы быть умным, нужно быть гибким. В моей новой лекции говорится о том, как стать умным.