Перевел для dprogramming.ru интервью Bitwize Magazine с Walter Bright 2006ого года, с чего и начну свои посты о языке DigitalMars D. Перевод весьма вольный, в первую очередь старался передать смысл и сделать удобочитаемым. Просьба прочитавшим: если нашли серьезную неточность - оставьте, пожалуйста, комментарий.
Чтобы было проще сравнивать, разделил на части по авторам с указанием исходного английского текста.
(скрыто - жмите на заголовок для просмотра)
After a lifetime of writing C and C++ compilers, Walter Bright decided to go one step beyond with the creation of D. In this exclusive interview, he tells Huw Collingbourne and Dermot Hogan about the past, present and future of the D programming language
Всю жизнь занимаясь написанием компиляторов С и С++, Walter Bright решил выйти на новый уровень созданием языка D. В данном эксклюзивном интервью он рассказывает Huw Collingbourne и Dermot Hogan про прошлое, настоящее и будущее языка программирования D.
----------------------------------------------------
What Is D?
“D is a general purpose systems and applications programming language. It is a higher level language than C++, but retains the ability to write high performance code and interface directly with the operating system API's and with hardware. D is well suited to writing medium to large scale million line programs with teams of developers. D is easy to learn, provides many capabilities to aid the programmer, and is well suited to aggressive compiler optimization technology.”
From the The Digital Mars Overview of the D Language
Чем является D?
"D - язык программирования систем и приложений общего назначения. Он более высокоуровневый, чем С++, но при этом сохраняет возможность создавать быстро исполняемый код и обращаться непосредственно к API операционных систем и аппаратному обеспечению. D хорошо подходит для написания средних и больших программ с миллионами строк исходного кода большими командами разработчиков. D легко изучается, имеет множество средств в помощь разработчику и удобен для применения технологий агрессивной оптимизации компилятором."
Из обзора The Digital Mars Overview of the D Language
----------------------------------------------------
Huw: First of all, quite simply, why did you decide to create D? What was really so wrong with C++ anyway? And why didn't Java measure up?
Во-первых, проще говоря, прочему вы решили создать D? Что, собственно, было не так с С++? И почему не устраивала Java?
----------------------------------------------------
Walter Bright: I really like C++. I was instantly attracted to it back in 1986, and created the first native C++ compiler (Zortech C++). Over the years since, C++ has grown by layering on needed features without disturbing backwards compatibility. Often this results in some very strange rules and surprising corner cases. In the meantime, the rest of the programming world certainly has grown, too, with features and paradigms with proven productivity.
At some point, it just makes sense to look at where we are, and try to design a language that gets there in a straight line, rather than try to be compatible with obsolete decisions made 20 or 30 years ago. (For example, the text #inclusion system was a good idea 30 years ago, but has long passed any shred of sensibility in today's world. For another, the design of C++ is rooted in its ASCII past, making support of modern requirements like UTF difficult.)
C++ has reached a certain level of maturity now, its period of rapid evolution is over. So the time is right to see what can be done with a redesign. Java isn't it, for the simple reason that it isn't powerful enough. For example, a garbage collector cannot be written in Java.
Prior to the D language and compiler, Walter Bright wrote Northwest Software, C, Datalight C, Zorland C, Zortech C++ (the first native C++ compiler), Symantec C++ and Digital Mars C++ and the Symantec Visual Café Java compiler.
Я действительно люблю С++. Язык быстро привлек меня в 1986ом, и я создал первый платформозависимый компилятор С++ (Zortech C++). После этого с годами С++ рос путем наслоения необходимых новшеств без затрагивания обратной совместимости. Результатами такого подхода часто являлись некоторые очень странные правила и удивительные частные случаи. В то же время, прочие направления мира программирования также развились, создав свои новшества и парадигмы с проверенной продуктивностью.
Есть мнение, что стоит взглянуть на существующее положение дел и попытаться спроектировать язык программирования, непосредственно соответсвующий современным требованиям, а не пытаться сохранить совместимость с устаревшими решениями двадцати- и тридцатилетней давности. (К примеру, система включений #inclusion была хорошей идеей 30 лет назад, но давно потеряла всякую актуальность в сегодняшнем мире. Другой пример - дизайн С++ основан на его ASCII-прошлом, что усложняет поддержку современных требований, таких как UTF.)
С++ сейчас достиг определенного уровня развития, период его активного эволюционирования завершен. Настало нужное время для того, чтобы оценить, что можно сделать вплане редизайна. Java - не то, просто потому, что недостаточно мощна. Например, на яве нельзя написать сборщик мусора.
----------------------------------------------------
Huw: How big a challenge was it to write Zorland/Zortech C++? If you were doing it these days, what would you do differently?
Насколько сложной задачей было написание компилятора Zorland/Zortech C++? Если бы вы это делали сейчас, что бы сделали иначе?
----------------------------------------------------
Walter Bright: It's a huge challenge for anyone to write a professional quality compiler, and C++ is the hardest of all languages to implement. I wouldn't do it these days, as high quality free C++ compilers exist, but back in 1986 or so, there was plenty of opportunity in implementing one.
Написать компилятор профессионального уровня - очень сложная задача для кого угодно, а С++ - самый сложный для реализации язык программирования. Я бы не стал этого делать сегодня, поскольку уже есть высококачественные свободные компиляторы С++, но тогда, в 1986ом или около того, была реальная возможность написать такой компилятор.
----------------------------------------------------
Huw: What is D's 'unique selling point'? Given all the other languages available, why should a programmer choose D?
Что является уникальным преимуществом D? Если у программиста есть выбор между всеми существующими сегодня языками, почему он должен выбрать именно D?
----------------------------------------------------
Walter Bright: D appeals to programmers who are interested in writing high performance code, want a C++ style language, but need a language that is much easier to master with support for modern techniques like automatic memory management, modules, UTF, etc. It isn't unusual for a D program to have 30% less source code than the equivalent C++, yet run at the same speed or faster. It's simply faster to develop code in D, and faster to get it debugged. Other languages tend to adopt either a different look and feel from C++, or omit necessary power features like pointers. I don't believe any of them have gone as far as D has in developing a well-rounded set of core features.
D предназначен для программистов, заинтересованных в написании высокопроизводительного кода, желающих писать на языке стиля С++, но более легком в освоении и имеющем поддержку современных методик, таких как автоматическое управление памятью, модули, UTF и т.д. Для программы на D иметь на 30% меньше исходного кода, чем в аналогичной программе на С++, но при этом работать так же быстро или быстрее - обычное дело. Просто быстрее и разрабатывать код на D, и отлаживать его. Другие языки стремятся или иметь отличный от С++ стиль, или обойтись без нужных и мощных средств, таких как указатели. Я не верю, что какой-либо из них продвинулся в разработке набора хорошо подобранных основных особенностей настолько, насколько D.
----------------------------------------------------
Dermot: Can you use D for COM interfacing? It would be nice to have something between C# and C++ that didn't use the casting dirty trick that C# uses to query IUnkown.
Можно ли использовать D для работы с COM-интерфейсами? Было бы здорово иметь что-то среднее между C# и С++, что не использовало бы такой же грязный трюк с приведением типов, какой C# использует для запроса IUnknown.
----------------------------------------------------
Walter Bright: Yes, D directly supports building COM classes.
Да, D прямо поддерживает создание классов COM.
----------------------------------------------------
Huw: Is D open source? I see on your web site that you say "the front end" of D is open source. I can't see a mention of the GNU licence anywhere. What are the licence terms and just how open is D?
Имеет ли D открытый исходный код? Вижу на вашем веб-сайте, что вы говорите об открытом исходном коде компилятора D переднего плана. Нигде не вижу упомянания лицензии GNU. Каковы условия лицензии и вообще насколько открыт D?
----------------------------------------------------
Walter Bright: The front end of the D compiler is dual license, GPL and Artistic. David Friedman has taken the front end and grafted it on to gcc, and the result is gdc, the gnu D compiler, which is fully GPL. The runtime library is not GPL, but is freely redistributable and usable for any purpose. Many parts of it are even explicitly public domain.
Компилятор D переднего плана* лицензирован под двойной лицензией - GPL и Artistic. David Friedman приспособил его исходный код под использование GCC в качестве генератора кода, в результате чего получился компилятор gdc, полностью лицензированный под GPL. Библиотека времени исполнения не лицензирована под GPL, но свободно распространяема и пригодна к использованию для любых целей**. Многие ее части являются свободными (public domain).
* заточенного под использование DigitalMars C/C++ compiler в качестве генератора кода. "Компилятор переднего плана (front-end) в качестве результата своей работы формирует образ исходной программы на некотором промежуточном языке. Далее этот образ обрабатывается отдельной компонентой - генератором кода (back-end). Это обычная схема, давно принятая в многоязыковых системах программирования. Так как промежуточное представление выбирается единым для всех входных языков, то в системе достаточно единственного генератора кода, что исключает затраты на реализацию генератора для каждого отдельного компилятора. Кроме того, можно разработать несколько генераторов кода с единого внутреннего представления для различных аппаратных платформ, получив тем самым многоплатформную систему программирования. По этой схеме организована система gcc, похожим образом устроены и продукты семейства TopSpeed и десятки других." - цитата из статьи Евгения Зуева "Редкая профессия", стр. 29 - примечание переводчика
** стандартная библиотека Phobos, уже ставшая opensource и находящаяся сейчас на портале разработчиков D dsource.org. Также существует альтернативная стандартная библиотека Tango, разрабатываемая энтузиастами без участия разработчиков D (Walter Bright, Andrei Alecsandrescu и других). - примечание переводчика
----------------------------------------------------
Huw: In the license agreement I see mentions of Zortech and Symantec. What is the involvement of those companies with D?
Вижу в лицензионном соглашении упомянания о Zortech и Symantec. Как данные компании относятся к D?
----------------------------------------------------
Walter Bright: Zortech was bought by Symantec and no longer exists. The language in the license agreement is there at the request of Symantec to make clear that Symantec has absolutely no involvement with D or Digital Mars products. I used to work on compilers for Symantec.
Zortech был куплен Symantec и более не существует. Язык D в лицензионном соглашении присутствует по просьбе Symantec для того, чтобы прояснить ситуацию, что Symantec не имеет абсолютно никакого отношения к D или продуктам Digital Mars. Я работал над компиляторами для Symantec.
----------------------------------------------------
Huw: Why is there no IDE (at least on Windows)?
Почему нет интегрированной среды разработки (по крайней мере под Windows)?
----------------------------------------------------
Walter Bright: There are several people in the D community who are working on IDEs. D has a number of characteristics which make writing a good IDE for it easier (like it can be parsed without needing a symbol table).
В сообществе D есть несколько человек, работающих над созданием IDE. У D есть несколько свойств, которые упрощают создание хорошей интегрированной среды для него (как, например, код на D может быть проанализирован без необходимости в создании таблицы символов).
----------------------------------------------------
Dermot: I'm curious about your comment on parsing D. C++ is notoriously difficult to parse, and I'm still feeling a bit raw from writing a LL(k) parser for Ruby, so I've got strong feelings on the subject. Is D much easier to parse than C++? If so, is the language 'tighter' than C++ ?(i.e. less ambiguous and prone to 'blowing your leg off' to re-use a famous quotation).
Мне любопытен ваш комментарий по анализу кода D. C++ весьма сложен для анализа, и у меня еще свежи ощущения от написания анализатора LL(k) для Ruby, так что я в теме. D действительно намного проще для анализа по сравнению с С++? Если так, является ли язык "крепче" С++? (то есть менее двусмысленным и склонным к "отрыванию ваших ног", как в известной цитате).
----------------------------------------------------
Walter Bright: C++ isn't hard to parse because it requires arbitrary lookahead; that's an easy problem to solve. It's hard to parse because a particular sequence of tokens can produce multiple totally different parse trees, depending on what some of the symbols are declared as. Even worse, many of those symbols aren't known at parse time, because they aren't declared yet. So it has to be parsed into some indeterminate state that gets "fixed" later.
This issue makes it impossible to correctly parse C++ code without building most of a C++ compiler front end, including all the hard stuff. It's further complicated by the preprocessor - unless the parser has full implementation of the preprocessor, and includes all the #includes and command line #defines, it cannot successfully parse an arbitrary C++ source file. This cripples the utility of source formatters, analyzers, syntax directed editors, documentation generators, source code instrumentation tools, etc. To avoid these problems, the D language was designed with the following rules in mind:
1) no text preprocessor
2) no command line switch can change the syntax
3) no imported file can change the syntax
4) a source file can be tokenized without reference to syntax or semantics
5) a source file can be syntactically analyzed without needing any semantic information
This should make it easy to build tools that work with D source code. Parsing D still requires arbitrary lookahead, but this is an easy problem to deal with. The D lexer and parser are GPL open source, so the proof of that is plain to see.
Анализ С++ сложен не потому, что требует произвольного предварительного просмотра; это проблема решается просто. Он сложен потому, что некоторые последовательности знаков могут создавать множество совершенно разных деревьев анализа, в зависимости от того, как объявлены некоторые символы. Даже хуже, много значений таких символов не известно во время анализа, потому что они еще не объявлены, потому код должен быть проанализирован в какое-то промежуточное частично определенное состояние, которое "налаживается" после.
Из-за этого невозможно корректно анализировать код С++ без создания большей части компилятора С++, включая все сложные вещи. Далее все еще более усложняется из-за препроцессора - до тех пор, пока анализатор не имеет полной реализации препроцессора, не добавляет все #inlcude и #define, он не может успешно проанализировать произвольный файл с исходным кодом на С++. Это мешает использованию форматирования исходного кода, анализаторов, синтаксически-ориентированных редакторов, генераторов документации, средств применения исходного кода и прочих. Чтобы избежать подобного, в основе дизайна языка D были следующие правила:
1) нет текстового препроцессора
2) ни одна директива коммандной строки не может изменить синтаксис
3) ни один импортируемый файл не может изменить синтаксис
4) файл с исходным кодом может быть разделен на знаки (tokenized) без ссылок на синтаксис или семантику
5) файл с исходным кодом может быть синтаксически проанализирован без нужды в какой-либо семантической информации
Все это должно упростить создание средств для работы с исходным кодом D. Анализ D все еще требует произвольного предварительного просмотра, но эта проблема легко решается. Лексер (lexer) и анализатор (parser) D имеют открытый исходный код, потому доказательства всего сказанного легко увидеть.
----------------------------------------------------
Dermot: Again, relating to a comment you've made below on programming errors, YACC LALR parsers are notorious for saying things like 'there's an error in here somewhere, but I'm not sure where'. Ruby is particularly bad in this respect - are you saying that D uses a better bag of tricks than YACC?
Еще раз касательно вашего вышесказанного комментария про ошибки программирования, анализаторы YACC LALR нелюбимы за получаемые сообщения типа "где-то тут есть ошибка, но я не уверен, где именно". Ruby особенно плох в этом плане - вы хотите сказать, что D использует лучший "мешок фокусов" чем YACC?
----------------------------------------------------
Walter Bright: I've never used YACC; all the lexers and parsers I've built are hand made. Producing good error diagnostics, and doing good error recovery so parsing can continue without generating a blizzard of spurious messages is much more art than science.
From a theoretical perspective, however, being able to generate a good diagnostic requires that there be redundancy in the syntax. The redundancy is used to make a guess at what was intended, and the more redundancy, the more likely that guess will be correct. It's like the English language - if we misspell a wrod now and then, or if a word missing, the redundancy enables us to correctly guess the meaning. If there is no redundancy in a language, then any random sequence of characters is a valid program.
A good language design must find that sweet spot between enough redundancy to be able to detect errors and issue good error diagnostics, and not so much redundancy that it becomes too wordy and tedious.
Я никогда не использовал YACC; все сделанные мной лексеры и анализаторы полностью самодельные. Создание хорошего диагностирования ошибок и выполнение хорошего восстановления после ошибок для того, чтобы анализ мог быть продолжен без генерации моря ложных сообщений в гораздо большей степени искусство, чем наука.
С точки зрения теории, впрочем, возможность генерировать хорошую диагностику требует избыточности в синтаксисе. Избыточность используется для угадывания, что именно подразумевалось, и чем больше избыточности, тем более вероятно успешное угадывание. Это как в английском языке: если мы неправильно пишем солво здесь и далее, или если слово пропущено, избыточность помогает нам корректно угадать значение. Если в языке вообще нет избыточности, то любой произвольный набор символов будет действительной программой.
Хороший дизайн языка должен найти золотую середину в избыточности - чтобы ее было достаточно для определения ошибок и выполнения их хорошего диагностирования, и недостаточно для того, чтобы язык стал слишком многословным и нудным.
----------------------------------------------------
Huw: These days, a number of languages (such as PHP, Python and Ruby) offer special support for the development of web applications. How does D shape up against those languages for web development?
Сейчас несколько языков (таких, как PHP, Python и Ruby) предлагают специальную поддержку для разработки веб-приложений. Как D приспособлен конкурировать с этими языками в веб-разработке?
----------------------------------------------------
Walter Bright: D is very good for developing CGI apps because D has excellent support for strings, arrays, UTF, and regular expressions, as well as automatic memory management.
D очень хорош для разработки CGI-приложений, поскольку имеет отличную поддержку строк, массивов, UTF и регулярных выражений, так же как и автоматическое управление памятью.
----------------------------------------------------
Huw: Recently both Ruby and D entered the TIOBE programming language 'Top 20'. Even though, syntactically, Ruby and D are very different, they do share some common features (e.g. fairly 'pure' OOP, simple syntax, garbage collection, modules and mixins, closures). Are the similarities between Ruby and D more than skin deep?
Недавно и Ruby, и D попали в "Top 20" языков программирования по версии TIOBE. Даже несмотря на то, что D и Ruby очень разные, их объединяют общие черты (такие как "чистое" ООП, простой синтаксис, сборка мусора, модули и mixins, замыкания). Есть ли общее между Ruby и D кроме поверхностного сравнения?
----------------------------------------------------
Walter Bright: There are many fascinating parallels between Ruby and D. Ruby started out as a reengineering of Perl, and Perl has a lot of parallels with C++. Ruby was started by an independent developer out of sheer love of programming languages, and so has D. Neither language has any agenda other than serving the needs of programmers - and so they've succeeded without needing massive corporate backing or budgets. Probably the most fundamental difference between the two is that Ruby lives in the interpretive, dynamic typing world, and D lives in the native compiled, static typing world.
Есть много очаровательных параллелей между Ruby и D. Ruby был начат как переделка Perl, а у Perl много общего с С++. Ruby был начат независимым разработчиком из страстной любви к языкам программирования, так же как и D. Единственные предназначения обоих языков - быть полезными разработчикам, и в этом они преуспели без необходимости в мощной корпоративной финансовой поддержке. Наверное, наиболее существенное отличие между этими языками в том, что Ruby существует в мире интерпретирования и динамической типизации, а D - в мире платформозависимой компиляции и статической типизации.
----------------------------------------------------
Huw: Where is D going next? What is the next really important feature that you plan to add to the language?
В каком направлении D будет двигаться дальше? Какую следующую действительно важную особенность вы планируете добавить в язык?
----------------------------------------------------
Walter Bright: D is going wherever the D community wants it to go. I have a special interest in the types of features that lend themselves to better detection of programming errors and better optimization. Andrei Alexandrescu has been particularly generous with his time in helping me to understand the issues and coming up with solutions. These kinds of issues are steadily becoming more and more critical to professional software development. D already has many of these things, like contracts, built-in unit testing, guaranteed initialization, scope guards, etc., but much more can be done.
D будет двигаться в том направлении, в котором пожелает его сообщество. У меня есть особый интерес в тех видах нововведений, которые ведут к лучшему обнаружению ошибок и лучшей оптимизации. Andrei Alexandrescu уделил много времени, помогая мне понять спорные вопросы и предлагая решения. Подобные спорные вопросы неуклонно становятся все более и более критичными для профессиональной разработки программного обеспечения. В D уже есть множество подобных вещей, таких как контракты, встроенное тестирование модулей, гарантированная инициализация, scope-обертки и прочее, но еще многое можно сделать.
----------------------------------------------------
Huw: You mentioned the parallels between Ruby and D. How closely do you follow the developments of other languages?
Вы упомянули параллели между Ruby и D. Насколько пристально вы следите за разработками других языков?
----------------------------------------------------
Walter Bright: I obviously closely follow developments in C and C++. My interest in other languages is contextual - if I'm working on a better way to do X, and a certain other language does X very well, then I'll check it out. I'm also very interested in why some languages succeed, and others fail. Why did C++ succeed and Modula 2 fail? Why is Eiffel always trailing way behind? Why did Ruby leap so quickly to the fore? Do languages succeed because they have a killer feature, killer marketing, or are just well oiled machines?
Я, конечно же, слежу за разработками С и С++. Мой интерес к другим языкам - предметный: если я работаю над лучшим способом делать Х, а некоторый другой язык делает Х очень хорошо, тогда я смотрю его. Мне также очень интересны причины успеха одних языков и неуспеха других. Почему С++ успешен, а Modula 2 - нет? Почему Eiffel постоянно плетется в хвосте? Почему Ruby так быстро выскочил в лидеры? Успешны ли языки потому, что в них есть абсолютное новшество, абсолютное продвижение на рынке, или это просто работающие как швейцарские часы механизмы?
----------------------------------------------------
Huw: Other than D itself, which modern program languages do you think are most interesting or have the greatest potential?
Кроме самого D, какой современный язык программирования вы считаете наиболее интересным или имеющим наибольший потенциал?
----------------------------------------------------
Walter Bright: There's no doubt about it, the one to watch is Ruby. C, C++, and Java are mature languages that have reached their potential.
Без сомнений, стоит следить за Ruby. C, C++ и Java - сформировавшиеся языки, достигшие своего потенциала.
----------------------------------------------------
Walter Bright graduated from Caltech in 1979 with a degree in mechanical engineering. He worked for Boeing for 3 years on the development of the 757 stabilizer trim system. He then switched to writing software, in particular compilers, and has been writing them ever since.
Walter Bright окончил Калифорнийский Технологический Институт в 1979 со степенью в машиностроении. Он работал 3 года в Boeing над разработкой системы настройки стабилизатора 757. После этого он перешел на написание программного обеспечения, в основном - компиляторов, и пишет их до сих пор.
