Похоже, что большинство новых языков программирования, появившихся за последние 20 лет, были написаны на C. Это имеет смысл, поскольку C можно рассматривать как своего рода переносимый язык ассемблера. Но мне любопытно, ограничивает ли это дизайн языков каким-либо образом. Что вызвало мой вопрос, было думать о том, как C-стек используется непосредственно в Python для вызова функций. Очевидно, разработчик языка программирования может делать все, что захочет, на любом языке, который им нужен, но мне кажется, что язык, на котором вы решили написать свой новый язык, ставит вас в определенную точку зрения и дает вам определенные ярлыки, которые трудно игнорировать. Существуют ли другие характеристики этих языков, которые исходят из того, что они написаны на этом языке (хорошо или плохо)?Использует ли C для реализации других языков каким-либо образом ограничивает их дизайн?
ответ
Даже с реализацией C вы удивительно свободны в плане реализации. Например, chicken scheme использует C как промежуточное звено, но все же удается использовать стек в качестве генерации детского сада в сборщике мусора.
Сказанное: есть случаи, когда есть ограничения. Пример: компилятор GHC haskell имеет скрипт perl, называемый Evil Mangler, для изменения кода сборки GCC для реализации некоторых важных оптимизаций. По этой причине они перешли на сборку внутри компании и LLVM. Тем не менее, это не ограничивает языковой дизайн - только выбор компилятором доступных оптимизаций.
Нет, короче говоря. Реальность такова: посмотрите на языки, написанные на C. Lua, например, примерно так же далеко от C, как вы можете получить, не став Perl. Он имеет первоклассные функции, полностью автоматизированное управление памятью и т. Д.
Необычно, что на новые языки влияет их язык реализации, если только этот язык не содержит серьезных ограничений. Хотя я определенно не одобряю C, это не ограниченный язык, просто очень подверженный ошибкам и медленный, чтобы программировать по сравнению с более современными языками. О, кроме ЭЛТ. Например, Lua не содержит функций каталогов, поскольку он не является частью CRT, поэтому они не могут выполнять его совместимость в стандартном C. Это один из способов ограничения C. Но с точки зрения особенностей языка это не ограничивается.
Если вы хотите построить аргумент о том, что языки, реализованные в C имеют ограничения XYZ или характеристики, вы должны показать, что делать вещи по-другому невозможно в C.
У вас есть точка, и я поддержал ее, но обратите внимание, что даже lua и perl по-прежнему являются императивными языками. Функциональные языки (Haskell, ML-производные, Pure, Clean) обычно не выполняются в C. Я обвиняю это в том, что те, кто создает такой язык, уже знают другие функциональные языки, большинство из которых лучше для написания компилятора, чем C. – delnan
Вы "не одобряете c"? Ничего себе, это кажется суровым. В то время как я «не люблю» и предпочитаю не использовать Java, я сохраняю свое неодобрение за более отвратительные вещи, такие как охота на китов и носки с сандалиями. – AShelly
@ delnan: Проверьте ответ bdonlan. Они предварительно обработали Haskell в C. @AShelly: Это действительно не точка ответа. – Puppy
Одна вещь, которую я могу думать о том, что функции не обязательно являются первыми членами класса в языке, и это нельзя обвинять только в C (я не говорю о передаче указателя функции, хотя можно утверждать, что C предоставляет вам эту функцию).
Если кто-то должен был написать DSL в groovy (/ scheme/lisp/haskell/lua/javascript/и еще кое-что, что я не уверен), функции могут стать членами первого класса. Создание функций класса первого класса и использование анонимных функций позволяет писать сжатый и более понятный для человека код (как показано LINQ).
Да, в конечном итоге все они работают под C (или сборкой, если вы хотите добраться до этого уровня), но с точки зрения предоставления пользователю языка возможности проявить себя лучше, эти абстракции делают замечательную работу ,
Очень сложно сделать что-то в C, которое выглядит как первоклассные функции для реализованного языка, да. Но то же самое относится и к динамическому набору текста, к объектам и еще к десяткам других функций. В любом случае языки на основе C. – delnan
Я склонен не согласиться.
Я не думаю, что это так много, что компилятор или интерпретатор языка осуществляется в C — в конце концов, вы можете реализовать виртуальную машину с C, которая полностью в отличии от своего окружения хозяина, а это означает, что вы можете уйти из менталитета языка C/near-assembly.
Однако сложнее утверждать, что язык C сам не оказал влияния на дизайн более поздних языков. Возьмем, к примеру, использование фигурных скобок { } для группировки операторов в блоки, представление о том, что пробелы и отступы в основном несущественны, имена родного типа (int, char и т. Д.) И другие ключевые слова или способ определения переменных (т.е. сначала введите объявление типа, за которым следует имя переменной, необязательная инициализация). Многие из сегодняшних популярных и широко распространенных языков (C++, Java, C#, и я уверен, что их еще больше) разделяют эти понятия с C. (Вероятно, они были не совсем новыми для C, но AFAIK C придумал это конкретное сочетание синтаксиса языка.)
IIRC, C и большинство других императивных языков классифицируются как «языки, подобные ALGOL», поскольку они сильно зависят от ALGOL. – rmeador
Последний раз, когда я проверил, это C-семья. – Puppy
И @rmeador, и @DeadMG верны, ИМХО. ALGOL предоставил некоторые основные языковые концепции (найденные на таких языках, как C или Pascal), а C позже предоставил популярный синтаксис. – stakx
Сбор мусора. Языковые реализации поверх Java или .NET используют GC виртуальной машины. Те, кто находится на вершине С, имеют тенденцию использовать подсчет ссылок.
Большинство Java и.NET VM написаны на C или C++. –
И на каком языке была написана JVM/CLR? Sun JVM - это C++, я думаю, что это относится и к CLR. Хорошо, это на один шаг выше C, но все же ... – delnan
Я не вижу причин, почему сборка мусора на C должна быть ограничена схемами подсчета ссылок (даже если это возможно, поскольку подсчет ссылок может быть проще всего реализовать). IIRC есть некоторые хорошие GC для C, например. один - Хансом Бёмом. – stakx
C-стек - это всего лишь системный стек, и это понятие предшествует C совсем немного. Если вы изучаете теорию вычислений, вы увидите, что использование стека очень мощное.
Использование языка C для реализации языков, вероятно, очень мало повлияло на эти языки, хотя знакомство с C (и другими C-подобными языками) людей, которые разрабатывают и реализуют языки, вероятно, сильно повлияло на их дизайн. На вас очень трудно не влиять то, что вы видели раньше, даже если вы не активно копируете лучшие фрагменты другого языка.
Многие языки используют C как клей между ними и другими вещами. Часть этого состоит в том, что многие операционные системы предоставляют API C, поэтому для доступа к нему легко использовать C. Кроме того, C настолько распространен и прост, что многие другие языки имеют какой-то способ взаимодействия с ним. Если вы хотите склеить два модуля вместе, которые написаны на разных языках, то использование C, как среднего человека, возможно, является самым простым решением.
Там, где реализация языка в C, возможно, повлияла на другие языки, наиболее вероятно, что это похоже на то, как экранирование выполняется в строках, что, вероятно, не ограничивает это.
Единственное, что имеет ограниченный языковой дизайн, - это воображение и технические навыки языковых дизайнеров. Как вы сказали, C можно рассматривать как «язык ассемблерных ассемблеров». Если это так, то вопрос о том, сдерживает ли C проект, сродни тому, чтобы спросить, имеет ли сборка ограниченный языковой дизайн. Поскольку весь код, написанный на любом языке, в конечном итоге выполняется как сборка, каждый язык будет иметь те же ограничения. Поэтому сам язык C не налагает ограничений, которые можно было бы преодолеть, используя другой язык.
Это, как говорится, есть некоторые вещи, которые проще сделать на одном языке, а другой. Многие разработчики языка учитывают это. Если язык разрабатывается так, чтобы быть, скажем, мощным при обработке строк, но производительность не вызывает беспокойства, то использование языка с лучшими встроенными средствами обработки строк (например, C++) может быть более оптимальным.
Многие разработчики выбирают C по нескольким причинам. Во-первых, C - очень общий язык. Проекты с открытым исходным кодом, в частности, относительно легче найти опытного разработчика на C-языках, чем найти эквивалентно-квалифицированного разработчика на некоторых других языках. Во-вторых, C обычно поддается микро-оптимизации. При написании парсера для скриптового языка эффективность парсера оказывает большое влияние на общую производительность скриптов, написанных на этом языке. Для компилируемых языков более эффективный компилятор может сократить время компиляции. Многие компиляторы C очень хорошо подходят для создания чрезвычайно оптимизированного кода (что также является частью причины, по которой многие встроенные системы запрограммированы на языке C), а критически важный для работы код может быть записан в встроенной сборке.Кроме того, C стандартизирован и, как правило, является статической целью. Код может быть записан в стандарт ANSI/C89 и не должен беспокоиться о том, что он несовместим с будущей версией C. Изменения, внесенные в стандарт C99, добавляют функциональность, но не нарушают существующий код. Наконец, C чрезвычайно портативен. Если хотя бы один компилятор существует для данной платформы, это скорее всего компилятор C. Использование переносимого языка, такого как C, упрощает максимальное число платформ, которые могут использовать новый язык.
Внедрение компилятора/интерпретатора в C не имеет серьезных ограничений. С другой стороны, реализация языка X-C компилятор делает. Например, согласно Wikipedia article on C--, при компиляции языка более высокого уровня на C вы не можете выполнять точную сборку мусора, эффективную обработку исключений или оптимизацию хвостовой рекурсии. Это та проблема, которую C-- должен был решить.
Единственное ограничение, которое приходит на ум, - это расширяемость и хостинг компиляторов. Рассмотрим случай C#. Компилятор написан на C/C++ и является полностью родным кодом. Это делает очень сложно использовать в процессе с помощью приложения C#.
Это имеет широкие последствия для цепочки оснастки C#. Любой код, который хочет использовать настоящий синтаксический анализатор или механизм привязки C#, должен иметь хотя бы один компонент, который написан в собственном коде. Это в конечном итоге приводит к большей части цепочки инструментов для языка C#, который написан на C++, который немного отстает от языка.
Это не ограничивает язык, на который говорят, но определенно влияет на опыт общения с языком.
... но, возможно, если они написали * следующий * C# компилятор в C#, но скомпилированы с помощью текущего компилятора написанного в C ... – FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner действительно это опция. – JaredPar
Не могу поверить, что никто не упомянул Haskell. Интерпретатор объятий написан на языке C, а Haskell находится как можно дальше от C. – NullUserException
Не могли бы вы сделать аналогичный вопрос о том, что дизайн сборки затрудняет разработку языка? Если базовый язык напрямую не дает вам выразительных конструкций, которые вы хотите, вы загружаете. – jamesdlin