Почему интерпретаторы всех популярных языков сценариев записаны в C (если не в C, по крайней мере, не в C++)?

Почему интерпретаторы всех популярных языков сценариев написаны на C, а не на C ++?

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

Вот несколько примеров:

Ruby

• BlueRuby: написано на ABAP
• HotRuby: JavaScript
• Red Sun: ActionScript
• SmallRuby: Smalltalk / X
• MagLev: Ruby, GemStone Smalltalk
• Smalltalk.rb: Smalltalk
• Alumina: Smalltalk
• Кардинал: PIR, NQP, PGE
• RubyGoLightly: Go
• YARI: Ио
• JRuby: Java
• XRuby: Java
• Microsoft IronRuby: C #
• оригинальный IronRuby от Вилко Бауэра: C #
• Ruby. NET: C #
• NETRuby: C #
• MacRuby: Objective-C
• Rubinius: Ruby, C ++
• MetaRuby: Ruby
• RubyVM: Ruby

Python

• IronPython: C #
• Jython: Java
• Pynie: PIR, NQP, PGE
• PyPy: Python, RPython

PHP

• P8: Java
• Quercus: Java
• Phalanger: C #

Perl6

• Ракудо: Perl6, PIR, NQP, PGE
• Мопсы: Haskell
• Sprixel: JavaScript
• v6.pm: Perl5
• Эльф: CommonLisp

JavaScript

• Na rcissus: JavaScript
• Ejacs: ELisp
• Jint: C #
• IronJS: F #
• Rhino: Java
• Mascara (справочная реализация ECMAScript Harmony): Python
• Справочная реализация ECMAScript 4: стандартный ML

JVM HotSpot написана на C ++, Animorphic Smalltalk VM (от которого происходит HotSpot и V8) написана на C ++, Self VM (на которой основана Animorphic Smalltalk VM) написана на C ++.

Достаточно интересно, что во многих из вышеупомянутых случаев реализации, которые не написаны на C, на самом деле быстрее , чем реализации, написанные на C.

В качестве примера из двух реализаций, написанных на C, возьмем Lua и CPython. В обоих случаях они фактически написаны в небольшом подмножестве очень старой версии C. Причина этого в том, что они хотят быть легко переносимыми. CPython, например, работает на платформе, для которой компилятор C ++ даже не существует . Кроме того, Perl был написан в 1989 году, CPython в 1990 году, Lua в 1993 году, SpiderMonkey в 1995 году. C ++ не был стандартизирован до 1998 года.

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

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

Многие возможности C ++ также проблематичны - STL был стандартизирован много лет назад, и ему до сих пор не хватает одной замечательной реализации.

ООП, безусловно, великолепен, но он не перевешивает недостатки C ++ во многих сценариях.

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

Наиболее известные книги по компиляторам написаны с примерами на C. Также два основных инструмента lexx (строит лексер) и yacc (переводит грамматику на C) поддерживают C.

Рискну предположить, что это частично связано с тем, что C++ не был стандартизирован до 1998 года, что делает достижение переносимости намного сложнее.

Все перечисленные вами языки были разработаны до этой стандартизации.

История Ruby началась в 1995 году. Если бы вы писали интерпретатор в 1995 году, какие у вас были варианты? В том же году была выпущена Java. (И он был мучительно медленным в версии 1.0 и во многих отношениях не стоил того, чтобы его использовать)

C ++ еще не был стандартизирован, и его поддержка компилятором была очень отрывочной. (он также еще не перешел на «современный C ++», который мы используем сегодня. Я думаю, что примерно в это же время STL был предложен для стандартизации. На самом деле он не был добавлен к стандарту И даже после того, как он был добавлен, потребовалось еще несколько лет, чтобы 1) компиляторы наверстали упущенное, и 2) люди привыкли к этому общему стилю программирования. В то время C ++ был в первую очередь языком ООП, и во многих случаях этот стиль C ++ был немного медленнее, чем C. (В современном коде C ++ эта разница в производительности в значительной степени устранена, частично частично за счет лучших компиляторов и отчасти за счет лучших стилей кодирования, меньшей зависимости от конструкций ООП и большего от шаблонов и общего программирования)

Python был запущен в 1991 году.Perl еще старше (1987)

PHP тоже из 1995, но, что важно, был создан парнем, который практически ничего не знал о программировании . (и да, конечно, это во многом повлияло на язык)

Языки, о которых вы говорите, были начаты на C, потому что в то время C был лучшим выбором для портативной, ориентированной на будущее платформы.

И хотя я не искал этого, я готов поспорить, что помимо случая с PHP, который в большей степени обусловлен некомпетентностью, разработчики других языков выбрали C, потому что они * уже знали об этом . Так что, возможно, урок заключается не в том, что «C - лучший», а в том, «что язык, который вы уже знаете, лучше всего»

. Есть и другие причины, по которым часто выбирают C:

• опыт и доступность: C - простой язык, который справедливо легко забрать, снизив барьер входа. Он также популярен, и вокруг него много опытных программистов на C. Одна из причин, по которой эти языки стали популярными, может заключаться в том, что легко было найти программистов, которые помогли бы в разработке интерпретаторов. C ++ сложнее изучить и хорошо использовать. Сегодня это могло быть не такой большой проблемой, но 10 или 15 лет назад?
• Взаимодействие: большинство языков общаются через интерфейсы C. Поскольку ваш модный новый язык будет полагаться на компоненты, написанные на других языках (особенно в ранних версиях, когда сам язык ограничен и имеет несколько библиотек), всегда приятно и просто вызывать функцию C.Так как у нас все равно будет некоторый код на C, может возникнуть соблазн пройти весь путь и просто написать все на C.
• производительность: C не мешает вам много. Это не делает ваш код быстрым волшебным образом, но позволяет достичь хорошей производительности. Так же, конечно, C ++ или многие другие языки. Но это верно и для C.
• Переносимость: Практически на каждой платформе есть компилятор C. До недавнего времени компиляторы C ++ пользовались гораздо большим успехом.

Эти причины не означают, что C на самом деле является лучшим языком для написания интерпретаторов (или для чего-либо еще), они просто объясняют некоторые мотивы, которые заставили других писать на C.

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

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

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