使用 C 来实现其他语言是否会以任何方式限制他们的设计？
过去 20 年来出现的大多数新编程语言似乎都是用 C 编写的。这是完全有道理的，因为 C 可以被视为一种可移植的汇编语言。但我很好奇的是，这是否以任何方式限制了语言的设计。引发我问题的是思考如何在 Python 中直接使用 C 堆栈来调用函数。显然，编程语言设计者可以用他们想要的任何语言做任何他们想做的事情，但在我看来，你选择用来编写新语言的语言会让你处于某种心态，并给你一些难以忽视的捷径。这些语言是否还有其他因用该语言编写而产生的特征（好或坏）？
It seems that most new programming languages that have appeared in the last 20 years have been written in C. This makes complete sense as C can be seen as a sort of portable assembly language. But what I'm curious about is whether this has constrained the design of the languages in any way. What prompted my question was thinking about how the C stack is used directly in Python for calling functions. Obviously the programming language designer can do whatever they want in whatever language they want, but it seems to me that the language you choose to write your new language in puts you in a certain mindset and gives you certain shortcuts that are difficult to ignore. Are there other characteristics of these languages that come from being written in that language (good or bad)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我倾向于不同意。
我不认为语言的编译器或解释器是用 C 实现的——毕竟，你可以用 C 实现一个与其宿主环境完全不同的虚拟机，这意味着你可以得到远离 C/近汇编语言的思维方式。
然而，很难说 C 语言本身对后来语言的设计没有任何影响。以使用大括号
{ }将语句分组为块为例，空格和缩进的概念大多不重要，本机类型的名称（int、char等）和其他关键字，或者变量的定义方式（即首先是类型声明，然后是变量的名称，可选的初始化）。当今许多流行且广泛使用的语言（C++、Java、C#，我相信还有更多）与 C 共享这些概念。（这些对于 C 来说可能并不是全新的，但据我所知，C 提出了这个概念）语言语法的特定组合。）I tend to disagree.
I don't think it's so much that a language's compiler or interpreter is implemented in C — after all, you can implement a virtual machine with C that is completely unlike its host environment, meaning that you can get away from a C / near-assembly language mindset.
However, it's more difficult to claim that the C language itself didn't have any influence on the design of later languages. Take for example the usage of curly braces
{ }to group statements into blocks, the notion that whitespace and indentation is mostly unimportant, native type's names (int,char, etc.) and other keywords, or the way how variables are defined (ie. type declaration first, followed by the variable's name, optional initialization). Many of today's popular and wide-spread languages (C++, Java, C#, and I'm sure there are even more) share these concepts with C. (These probably weren't completely new with C, but AFAIK C came up with that particular mix of language syntax.)即使使用 C 实现，您在实现方面也令人惊讶地自由。例如，鸡方案使用 C 作为中间体，但仍然设法使用堆栈作为苗圃生成它的垃圾收集器。
也就是说，在某些情况下存在限制。举个例子：GHC haskell 编译器有一个名为 Evil Mangler 更改 GCC 输出的汇编代码以实现一些重要的优化。部分出于这个原因，他们已经转向内部生成的汇编和 LLVM。也就是说，这并没有限制语言设计——只是编译器对可用优化的选择。
Even with a C implementation, you're surprisingly free in terms of implementation. For example, chicken scheme uses C as an intermediate, but still manages to use the stack as a nursery generation in its garbage collector.
That said, there are some cases where there are constraints. Case in point: The GHC haskell compiler has a perl script called the Evil Mangler to alter the GCC-outputted assembly code to implement some important optimizations. They've been moving to internally-generated assembly and LLVM partially for that reason. That said, this hasn't constrained the language design - only the compiler's choice of available optimizations.
不，简而言之。现实情况是，环顾一下用 C 编写的语言。例如，Lua 与 C 的差距是在不成为 Perl 的情况下所能达到的最大程度。它具有一流的功能、完全自动化的内存管理等。
新语言很少会受到其实现语言的影响，除非该语言包含严重的限制。虽然我绝对不赞成 C，但它并不是一种有限的语言，只是与更现代的语言相比非常容易出错且编程速度慢。哦，CRT 除外。例如，Lua 不包含目录功能，因为它不是 CRT 的一部分，因此它们无法在标准 C 中可移植地实现它。这是 C 受到限制的一种方式。但就语言特性而言，它并不受限制。
如果你想构造一个论点，说用 C 实现的语言具有 XYZ 限制或特征，那么你必须证明用其他方式做事在 C 中是不可能的。
No, in short. The reality is, look around at the languages that are written in C. Lua, for example, is about as far from C as you can get without becoming Perl. It has first-class functions, fully automated memory management, etc.
It's unusual for new languages to be affected by their implementation language, unless said language contains serious limitations. While I definitely disapprove of C, it's not a limited language, just very error-prone and slow to program in compared to more modern languages. Oh, except in the CRT. For example, Lua doesn't contain directory functionality, because it's not part of the CRT so they can't portably implement it in standard C. That is one way in which C is limited. But in terms of language features, it's not limited.
If you wanted to construct an argument saying that languages implemented in C have XYZ limitations or characteristics, you would have to show that doing things another way is impossible in C.
C 堆栈只是系统堆栈，这个概念早于 C 相当多的时间。如果您研究计算理论，您会发现使用堆栈非常强大。
使用 C 来实现语言可能对这些语言的影响很小，尽管设计和实现语言的人对 C（和其他类似 C 的语言）的熟悉程度可能对他们的设计产生了很大的影响。即使您没有积极复制另一种语言的最佳部分，也很难不受到以前见过的事物的影响。
不过，许多语言确实使用 C 作为它们和其他语言之间的粘合剂。部分原因是许多操作系统提供了 C API，因此使用 C 来访问它很容易。此外，C 是如此常见和简单，以至于许多其他语言都有某种方式与其交互。如果您想将两个用不同语言编写的模块粘合在一起，那么使用 C 作为中间人可能是最简单的解决方案。
用 C 语言实现一种语言对其他语言影响最大的地方可能是诸如如何在字符串中完成转义之类的事情，这可能并没有那么限制。
The C stack is just the system stack, and this concept predates C by quite a bit. If you study theory of computing you will see that using a stack is very powerful.
Using C to implement languages has probably had very little effect on those languages, though the familiarity with C (and other C like languages) of people who design and implement languages has probably influenced their design a great deal. It is very difficult to not be influenced by things you've seen before even when you aren't actively copying the best bits of another language.
Many languages do use C as the glue between them and other things, though. Part of this is that many OSes provide a C API, so to access that it's easy to use C. Additionally, C is just so common and simple that many other languages have some sort of way to interface with it. If you want to glue two modules together which are written in different languages then using C as the middle man is probably the easiest solution.
Where implementing a language in C has probably influenced other languages the most is probably things like how escapes are done in strings, which probably isn't that limiting.
唯一限制语言设计的是语言设计者的想象力和技术能力。正如你所说，C 可以被认为是一种“可移植的汇编语言”。如果这是真的，那么询问 C 是否限制了设计就类似于询问汇编是否限制了语言设计。由于用任何语言编写的所有代码最终都会作为汇编执行，因此每种语言都会受到相同的约束。因此，C 语言本身没有施加使用其他语言可以克服的限制。
话虽如此，有些事情用一种语言比另一种语言更容易完成。许多语言设计者都考虑到了这一点。如果该语言被设计为在字符串处理方面功能强大，但性能不是问题，那么使用具有更好的内置字符串处理设施的语言（例如 C++）可能会更理想。
许多开发人员出于多种原因选择 C。首先，C是一种非常通用的语言。尤其是开源项目，找到经验丰富的 C 语言开发人员比找到具有同等技能的其他语言开发人员相对容易。其次，C 通常适合微优化。当为脚本语言编写解析器时，解析器的效率对该语言编写的脚本的整体性能有很大影响。对于编译型语言，更高效的编译器可以减少编译时间。许多C编译器非常擅长生成极其优化的代码（这也是许多嵌入式系统用C编程的部分原因），并且可以使用内联汇编编写性能关键的代码。此外，C 是标准化的，通常是静态目标。代码可以按照 ANSI/C89 标准编写，而不必担心它与未来版本的 C 不兼容。C99 标准中所做的修订增加了功能，但不会破坏现有代码。最后，C 语言非常可移植。如果给定平台至少存在一个编译器，那么它很可能是 C 编译器。使用 C 等高度可移植的语言可以更轻松地最大化可以使用新语言的平台数量。
The only thing that has constrained language design is the imagination and technical skill of the language designers. As you said, C can be thought of as a "portable assembly language". If that is true, then asking if C has constrained a design is akin to asking if assembly has constrained language design. Since all code written in any language is eventually executed as assembly, every language would suffer the same constraints. Therefore, the C language itself imposes no constraints that would be overcome by using a different language.
That being said, there are some things that are easier to do in one language vs another. Many language designers take this into account. If the language is being designed to be, say, powerful at string processing but performance is not a concern, then using a language with better built-in string processing facilities (such as C++) might be more optimal.
Many developers choose C for several reasons. First, C is a very common language. Open source projects in particular like that it is relatively easier to find an experienced C-language developer than it is to find an equivalently-skilled developer in some other languages. Second, C typically lends itself to micro-optimization. When writing a parser for a scripted language, the efficiency of the parser has a big impact on the overall performance of scripts written in that language. For compiled languages, a more efficient compiler can reduce compile times. Many C compilers are very good at generating extremely optimized code (which is also part of the reason why many embedded systems are programmed in C), and performance-critical code can be written in inline assembly. Also, C is standardized and is generally a static target. Code can be written to the ANSI/C89 standard and not have to worry about it being incompatible with a future version of C. The revisions made in the C99 standard add functionality but don't break existing code. Finally, C is extremely portable. If at least one compiler exists for a given platform, it's most likely a C compiler. Using a highly-portable language like C makes it easier to maximize the number of platforms that can use the new language.
我想到的一个限制是可扩展性和编译器托管。考虑 C# 的情况。编译器是用 C/C++ 编写的，完全是本机代码。这使得它在 C# 应用程序的进程中使用非常困难。
这对 C# 工具链具有广泛的影响。任何想要利用真正的 C# 解析器或绑定引擎的代码都必须至少有一个用本机代码编写的组件。这最终导致 C# 语言的大部分工具链都是用 C++ 编写的，这对于语言来说有点落后。
这并不限制每个人所说的语言，但肯定会对语言体验产生影响。
The one limitation that comes to mind is extensibility and compiler hosting. Consider the case of C#. The compiler is written in C/C++ and is entirely native code. This makes it very difficult to use in process with a C# application.
This has broad implications for the tooling chain of C#. Any code which wants to take advantage of the real C# parser or binding engine has to have at least one component which is written in native code. This eventually results in most of the tooling chain for the C# language being written in C++ which is a bit backwards for a language.
This doesn't limit the language per say but definitely has an effect on the experience around the language.
垃圾收集。 Java 或 .NET 之上的语言实现使用 VM 的 GC。 C 之上的那些倾向于使用引用计数。
Garbage collection. Language implementations on top of Java or .NET use the VM's GC. Those on top of C tend to use reference counting.
我能想到的一件事是，函数不一定是该语言中的第一类成员，这不能单独归咎于 C （我不是在谈论传递函数指针，尽管可以说 C 为您提供了具有该功能）。
如果用 groovy（/scheme/lisp/haskell/lua/javascript/以及其他一些我不确定的）编写 DSL，函数可以成为一等成员。将函数设为第一类成员并允许匿名函数可以编写简洁且更易读的代码（如 LINQ 所示）。
是的，最终所有这些都在 C 下运行（如果你想达到那个级别，则在汇编下运行），但在为语言用户提供更好地表达自己的能力方面，这些抽象做得非常出色。
One thing I can think of is that functions are not necessarily first class members in the language, and this is can't be blamed on C alone (I am not talking about passing a function pointer, though it can be argued that C provides you with that feature).
If one were to write a DSL in groovy (/scheme/lisp/haskell/lua/javascript/and some more that I am not sure of), functions can become first class members. Making functions first class members and allowing for anonymous functions allows to write concise and more human readable code (like demonstrated by LINQ).
Yes, eventually all of these are running under C (or assembly if you want to get to that level), but in terms of providing the user of the language the ability to express themselves better, these abstractions do a wonderful job.
用 C 语言实现编译器/解释器没有任何重大限制。另一方面，将 X 语言实现为 C 编译器则可以。例如，根据维基百科关于C--的文章，在编译更高级别时从语言到 C，您无法进行精确的垃圾收集、高效的异常处理或尾递归优化。这就是 C-- 旨在解决的问题。
Implementing a compiler/interpreter in C doesn't have any major limitations. On the other hand, implementing a language X to C compiler does. For example, according to the Wikipedia article on C--, when compiling a higher level language to C you can't do precise garbage collection, efficient exception handling, or tail recursion optimization. This is the kind of problem that C-- was intended to solve.