Почему переводчики всех популярных языков сценариев написаны на C (если не на C, по крайней мере на C ++)? - PullRequest
8 голосов
/ 10 апреля 2010

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

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

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

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

Ответы [ 8 ]

13 голосов
/ 11 апреля 2010

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

10 голосов
/ 11 апреля 2010

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

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

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

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

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

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

Существуют и другие причины, по которым С часто выбирают:

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

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

7 голосов
/ 11 апреля 2010

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

3 голосов
/ 11 апреля 2010

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

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

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

рубин

  • BlueRuby: написано на ABAP
  • HotRuby: JavaScript
  • Red Sun: ActionScript
  • SmallRuby: Smalltalk / X
  • MagLev: Ruby, GemStone Smalltalk
  • Smalltalk.rb: Smalltalk
  • Оксид алюминия: Smalltalk
  • Кардинал: PIR, NQP, PGE
  • RubyGoLightly: Go
  • ЯРИ: Io
  • JRuby: Java
  • XRuby: Java
  • Microsoft IronRuby: C #
  • оригинальный IronRuby от Wilco Bauwer: C #
  • Ruby.NET: C #
  • NETRuby: C #
  • MacRuby: Objective-C
  • Рубинус: Рубин, C ++
  • MetaRuby: Ruby
  • RubyVM: Ruby

Python

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

PHP

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

Perl6

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

JavaScript

  • Нарцисс: JavaScript
  • Ejacs: ELisp
  • Jint: C #
  • IronJS: F #
  • Rhino: Java
  • Тушь для ресниц (Справочная реализация ECMAScript Harmony): Python
  • ECMAScript 4 Эталонная реализация: Стандарт ML

HotSpot JVM написана на 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 года.

3 голосов
/ 11 апреля 2010

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

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

2 голосов
/ 11 апреля 2010

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

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

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

1 голос
/ 11 апреля 2010

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

0 голосов
/ 13 августа 2010

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

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

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

...