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

Нет, короче. В действительности, посмотрите на языки, которые написаны на C. Например, Lua примерно настолько далека от C, насколько вы можете получить, не становясь Perl. Имеет первоклассные функции, полностью автоматизированное управление памятью и т. Д.

Это необычно для новых языков, которые будут затронуты языком их реализации, если только этот язык не содержит серьезных ограничений. Хотя я определенно не одобряю C, это не ограниченный язык, просто очень подверженный ошибкам и медленный для программирования по сравнению с более современными языками. Ох, кроме как в ЭЛТ. Например, Lua не содержит функциональных возможностей каталога, потому что он не является частью CRT, поэтому они не могут реализовать его в стандарте C. Это один из способов, которым C ограничен. Но с точки зрения языковых возможностей это не ограничено.

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

Реализация компилятора / интерпретатора в C не имеет каких-либо серьезных ограничений. С другой стороны, реализация компилятора языка X to C делает. Например, согласно статье Википедии о C -, при компиляции языка более высокого уровня в C вы не можете выполнять точную сборку мусора, эффективную обработку исключений или оптимизацию хвостовой рекурсии. Это та проблема, которую C-- должен был решить.

Стек C - это просто системный стек, и эта концепция намного старше C. Если вы изучите теорию вычислений, вы увидите, что использование стека очень эффективно.

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

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

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

Я не согласен.

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

Однако сложнее утверждать, что сам язык C не оказал никакого влияния на дизайн более поздних языков.Возьмем, к примеру, использование фигурных скобок {} для группировки операторов в блоки, представление о том, что пробелы и отступы в основном не важны, имена собственных типов ( int , char ] и т. д.) и другие ключевые слова, или способ определения переменных (т. е. сначала объявление типа, а затем имя переменной, необязательная инициализация). Многие из сегодняшних популярных и широко распространенных языков (C ++, Java, C # и я уверен, что их гораздо больше) разделяют эти концепции с C. (Вероятно, они не были полностью новыми для C, но AFAIK C придумал это. конкретное сочетание синтаксиса языка.)

Единственное ограничение, которое приходит на ум, - это расширяемость и размещение компилятора. Рассмотрим случай C #. Компилятор написан на C / C ++ и представляет собой полностью собственный код. Это делает его очень трудным для использования в процессе с приложением C #.

Это имеет большое значение для цепочки инструментов C #. Любой код, который хочет использовать реальный синтаксический анализатор C # или механизм привязки, должен иметь по крайней мере один компонент, написанный на машинном коде. В конечном итоге это приводит к тому, что большая часть цепочки инструментов для языка C # написана на C ++, что немного отстает от языка.

Это не ограничивает количество слов, но определенно влияет на восприятие языка.

Сборка мусора. Реализации языка поверх Java или .NET используют GC VM. Те, кто находится на вершине C, обычно используют подсчет ссылок.

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

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

Многие разработчики выбирают C по нескольким причинам. Во-первых, C - очень распространенный язык. Проекты с открытым исходным кодом, в частности, любят то, что найти опытного разработчика на языке Си относительно легче, чем эквивалентно квалифицированного разработчика на некоторых других языках. Во-вторых, язык Си обычно поддается микрооптимизации. При написании парсера для скриптового языка эффективность парсера оказывает большое влияние на общую производительность скриптов, написанных на этом языке. Для компилируемых языков более эффективный компилятор может сократить время компиляции. Многие компиляторы языка Си очень хороши в создании чрезвычайно оптимизированного кода (это также является частью причины, по которой многие встраиваемые системы программируются на Си), а критичный к производительности код может быть написан на встроенном ассемблере. Кроме того, язык C стандартизирован и, как правило, является статической целью. Код можно писать в соответствии со стандартом ANSI/C89 и не беспокоиться о том, что он будет несовместим с будущей версией C. Изменения, внесенные в стандарт C99, добавляют функциональность, но не ломают существующий код. Наконец, язык C чрезвычайно переносим. Если для данной платформы существует хотя бы один компилятор, то, скорее всего, это компилятор языка Си. Использование такого переносимого языка, как C, позволяет максимально увеличить количество платформ, на которых может использоваться новый язык.

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

Если бы кто-то написал DSL на Groovy (/ scheme / lisp / haskell / lua / javascript / и еще кое-что, в чем я не уверен), функции могли бы стать членами первого класса. Сделав функции первыми членами класса и разрешив анонимные функции, можно писать краткий и более понятный для человека код (как это продемонстрировал LINQ).

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