?: Устойчивость объектов - вот область, где достоинства С++ не очевидны. Существует ряд библиотек/методов, но в большинстве случаев вы приходите к необходимости использования специального препроцессора или некоторой вручную кодируемой функции. Механизм идентификации типа во время исполнения RTTI выглядит перспективным в этом отношении, но если здесь не будет введен некоторый стандарт, то не появится ли еще одно непереносимое расширение?

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

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

Исходите из проблемы, которую нужно решить. Полезный язык - это решение хорошо понятого множества проблем, а не просто нечто, удовлетворяющее неким модным критериям того, как должен выглядеть язык программирования. Если вы не имеете действительно серьезной проблемы, которая не может быть решена с использованием любого из существующих языков, то даже и не думайте о проектировании еще одного языка. Помните, что проектирование языка - эта та сфера деятельности, где вероятность неудач составляет почти 100%. И никому не советую этим заниматься, если есть альтернатива. Сопротивляйтесь такой работе. Если же все-таки вы должны проектировать новый язык, то заимствуйте из уже известных языков столько, сколько сможете (не забывая выражать благодарность их авторам). И будьте готовы к неудаче и к очень большой работе - может быть, и преуспеете.

?: Visual Basic - это еще один добившийся огромного успеха язык. Некоторые утверждают, что он обеспечивает то, что С++ в области объектно-ориентированного программирования обещал, но в полной мере не реализовал, а именно: массу встраиваемых (pluggable) компонентов, истинное повторное использование кода - все это, может быть, ценой недостаточно выстроенных инженерных аспектов. Правильно ли, по-вашему, что вопросы совместимости, обеспечивающей согласованную работу различных компиляторов С++, бывают отданы на откуп независимым разработкам, а не являются частью стандарта? Понятно, что любой стандарт на двоичный код ограничил бы свободу разработчиков компиляторов, но в конце концов любой стандарт ограничивает чью-то свободу. Скажем, отказом от поддержки множественного наследования можно добиться большей производительности, но это все-таки не причина, чтобы удалять MI из С++. Почему же к вопросу двоичного стандарта применяется иной подход (хотя, конечно, двоичный стандарт - это только один шаг по направлению к "надлежащим" программным компонентам)?

Язык С++ обеспечивает то, что обещал. Нельзя ожидать, что даже такой язык окажется способен покрыть все вдруг вошедшие в моду и сверх всякой меры рекламируемые при раскрутке какого-то другого языка особенности. С++ - это язык программирования, а не язык спецификации модулей или операционная система. Он, как и другие языки, не может обеспечить всем все. Вы можете строить "встраиваемые компоненты", используя С++, но это не то, для чего он в основном предназначен, а потому - требует усилий. Совместимость - тяжелая проблема. Не все понимают, что только через огромную работу по достижению соглашений между многими организациями, к тому же конкурирующими между собой, могла быть достигнута совместимость фрагментов программ на Си, подвергшихся компиляции с помощью различных компиляторов. Должно быть соглашение о последовательности вызова функций, форматах данных, деталях арифметики с плавающей точкой и т.д. С++ в этом отношении потяжелее, чем Си, но ненамного. Вообще, почти все тяжелые проблемы имеют не технический, а политический характер. Вопрос же множественного наследования стоит совершенно отдельно от любого вопроса, связанного с двоичными стандартами и совместимостью компиляторов С++. Я полагаю, что отсутствие MI (по крайней мере - в ранних версиях SOM) если о чем и говорит, так только о неравнодушии их авторов к Smalltalk и Objective C. В языках же, подобных С++, которые полагаются на статическую проверку типов интерфейсов, некоторая форма множественного наследования весьма существенна. Альтернатива - деформированный код, небезопасный интерфейс, или все это вместе.

?: Могли бы Вы назвать какие-то новые понятия, идеи, особенности, которые могут определить лицо С++ следующего поколения, и вообще, как-то предсказать судьбу С++? Хотя я предполагаю, что прежде всего Вы хотели бы видеть С++ стабильным, пусть на какое-то время.

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

на главную