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

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

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

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

Если вы хотите рассказать мне о каком-то другом языке, где его интерпретатор не на C, пожалуйста, замените все вхождения popular scripting languages в этом вопросе на Ruby, Python, Perl and PHP.


person wndsr    schedule 10.04.2010    source источник
comment
C ++ на самом деле не намного медленнее, чем C; просто написать кроссплатформенное приложение на C ++ сложнее, чем на C, а в C доступно больше библиотек.   -  person Sasha Chedygov    schedule 11.04.2010
comment
Я имел ввиду конечно из кода C ++   -  person    schedule 11.04.2010


Ответы (8)


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

person Jason Williams    schedule 10.04.2010

История 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.

person jalf    schedule 11.04.2010

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

person Matti Virkkunen    schedule 10.04.2010

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

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

person Stephen    schedule 10.04.2010

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

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

Вот пара примеров:

Рубин

  • BlueRuby: написано на ABAP
  • HotRuby: JavaScript
  • Красное солнце: ActionScript
  • SmallRuby: Smalltalk / X
  • MagLev: Ruby, GemStone Smalltalk
  • Smalltalk.rb: Smalltalk
  • Глинозем: Smalltalk
  • Кардинал: PIR, NQP, PGE
  • RubyGoLightly: Вперед
  • ЯРИ: Ио
  • JRuby: Java
  • XRuby: Java
  • Microsoft IronRuby: C #
  • оригинальный IronRuby от Wilco Bauwer: C #
  • Ruby.NET: C #
  • NETRuby: C #
  • МакРуби: Цель-C
  • Рубиниус: Ruby, C ++
  • MetaRuby: Рубин
  • RubyVM: Рубин

Python

  • IronPython: C #
  • Jython: Java
  • Пайни: PIR, NQP, PGE
  • PyPy: Python, RPython

PHP

  • P8: Java
  • Quercus: Java
  • Фалангер: C #

Perl6

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

JavaScript

  • Нарцисс: JavaScript
  • Эяк: ELisp
  • Джинт: C #
  • IronJS: F #
  • Носорог: Ява
  • Тушь (справочная реализация ECMAScript Harmony): Python
  • Эталонная реализация ECMAScript 4: стандартный ML

JVM HotSpot написана на C ++, виртуальная машина Animorphic Smalltalk (из которой получены HotSpot и V8) написана на C ++, виртуальная машина Self (на которой основана виртуальная машина Animorphic Smalltalk) написана на C ++.

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

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

person Jörg W Mittag    schedule 10.04.2010
comment
+1 Интересно. Но заметили ли вы использование слова «популат» в вопросе :-) - person ; 11.04.2010
comment
@Neil: Я бы сказал, что Ruby, Python, PHP и Perl довольно популярны, и на самом деле OP специально перечислил эти четыре в своем вопросе. А JavaScript - в значительной степени самый популярный язык программирования когда-либо (по крайней мере, для более консервативного определения языка программирования, иначе самым популярным языком был бы Excel). - person Jörg W Mittag; 11.04.2010
comment
@Jorg Да, языки популярны, но я не думаю, что большинство конкретных реализаций, которые вы упомянули. - person ; 11.04.2010
comment
@ Jörg: В соответствии с моим вопросом: популярные, официальные и основные реализации примеров языков, которые я перечислил, все написаны на C. - person wndsr; 11.04.2010
comment
@Neil: Что ж, OP очень тщательно проводил различие между языками и реализациями, и он специально спрашивал о популярных языках, а не о реализации. В любом случае, я думаю, что V8, JRuby и IronPython в некоторой степени популярны, и я предсказываю, что MacRuby, Rubinius и PyPy станут популярными. Кроме того, дико популярны HotSpot и CLR, и оба они написаны на C ++ (хотя я бы не стал классифицировать их как сценарии, что бы это ни означало). - person Jörg W Mittag; 11.04.2010
comment
@ Нил Баттерворт: согласен. Этот ответ на самом деле вводит в заблуждение, потому что в нем не перечислены канонические, наиболее распространенные или оригинальные реализации любого из этих языков. Большинство этих реализаций были созданы и известны (если они известны) наличием реализации на этом языке или виртуальной машине. - person intuited; 11.04.2010
comment
@intuited: в вопросе ничего не говорится о канонических, наиболее распространенных, оригинальных или популярных реализациях. Он просто говорит, что интерпретаторы для популярных языков сценариев написаны на C, а это неверно, что делает недействительной всю предпосылку вопроса. В Ruby, например, 80% существующих в настоящее время интерпретаторов написаны не на C. В Python около 40% написаны не на C. Наиболее близким к канонической реализации JavaScript является эталонная реализация, написанная на стандартном языке. ML, Python и (в будущем) ECMAScript. - person Jörg W Mittag; 11.04.2010

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

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

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

person Bozhidar Batsov    schedule 10.04.2010
comment
Нет отличной реализации STL? Так с чем же поставляются все популярные компиляторы? - person jalf; 11.04.2010
comment
Есть поставка реализации STL, но насколько она хороша - совсем другой вопрос. Раньше я пару лет проработал разработчиком на C ++. В одном из крупнейших проектов нашей компании технический директор запретил использование каких-либо классов STL. В качестве наиболее простого примера я могу указать, что он заметил серьезные проблемы с производительностью при использовании строкового класса по сравнению с использованием необработанного массива символов. И это были не только проблемы с производительностью, которые у нас были с этим STL. Мы использовали GCC, но технический директор сказал, что они протестировали и другие реализации STL - из них исправлены ошибки ... - person Bozhidar Batsov; 11.04.2010
comment
@Божидар Бацов: Давно ли это было? - person Viktor Sehr; 23.04.2010
comment
Значит, твои рассуждения на самом деле просто парни, которые однажды сказали мне, что это отстой? Некоторые сказали бы, что собственное тестирование даст более надежные данные. ;) - person jalf; 06.07.2010
comment
На самом деле многие ребята рассказывали мне похожие вещи, которые делают данные надежными и, как правило, исследуют только то, что меня интересует - я бы предпочел проводить время с Lisp, чем с C ++ ;-) - person Bozhidar Batsov; 06.07.2010

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

person Romain Hippeau    schedule 10.04.2010

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

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

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

person Lothar    schedule 13.08.2010