似乎在过去20年中出现的大多数新编程语言都是用C语言编写的。这完全有道理，因为C语言可以看作是便携式汇编语言。但我感到好奇的是，这是否会以某种方式限制语言的设计。引发我的问题是想到Python直接使用C堆栈来调用函数。显然，编程语言设计师可以在任何语言中做任何想做的事情，但对我而言，选择用哪种语言编写新语言会让你进入某种思维模式，并给你某些难以忽视的快捷方式。这些语言是否还有其他特征源于用该语言编写（好或坏）？
使用C语言实现其他编程语言是否会在某种程度上限制它们的设计？
22
- guidoism
2
2我简直不敢相信没有人提到 Haskell。Hugs 解释器是用 C 写的，而 Haskell 与 C 相去甚远。 - NullUserException
2你能否提出一个类似的问题，即汇编语言的设计是否限制了语言设计？如果基本语言不能直接提供所需的表达性结构，则需要进行引导。 - jamesdlin
9个回答
8
我有不同的看法。
我认为，一个语言的编译器或解释器是否是用C实现并不是最重要的。毕竟，你可以使用C实现一个虚拟机，它与其主机环境完全不同，这意味着你可以摆脱C / 接近汇编语言的思维方式。
然而，更难以否认的是，C语言本身对后来的语言设计产生了影响。例如，使用花括号{ }将语句分组成块、空白和缩进大多不重要的概念、本地类型的名称（int、char等）和其他关键字，或者变量定义的方式（即类型声明先于变量名称，可选初始化）。今天许多流行的、广泛使用的语言（如C++、Java、C#等）都与C共享这些概念。（这些概念可能在C之前并不是全新的，但据我所知，C提出了这种特定的语言语法组合。）
- stakx - no longer contributing
3
如果我没记错的话，C语言和大多数其他命令式语言被归类为“ALGOL-like语言”，因为它们受到ALGOL的很大影响。 - rmeador
我上次查看时，它是C家族。 - Puppy
2在我看来，@rmeador和@DeadMG都是正确的。ALGOL提供了一些主要的语言概念（在C或Pascal等语言中找到），而C后来提供了一种流行的语法。 - stakx - no longer contributing
5
不是这样的。事实上，看看用C语言编写的语言，比如Lua，它与C之间的距离几乎可以说是最远的，除非变成Perl。它具有一流的函数、完全自动化的内存管理等特点。
新语言受其实现语言影响并不常见，除非该语言存在严重的限制。虽然我确实不赞成C语言，但它并不是一种受限制的语言，只是与更现代的语言相比，编程速度慢且容易出错。哦，除了在CRT中。例如，Lua不包含目录功能，因为它不是CRT的一部分，所以无法在标准C中实现可移植性。这是C语言的一种限制方式。但在语言特性方面，它并没有受到限制。
如果您想构建一个论点，说使用C实现的语言具有XYZ限制或特征，则需要证明在C中另外实现这些功能是不可能的。
新语言受其实现语言影响并不常见，除非该语言存在严重的限制。虽然我确实不赞成C语言，但它并不是一种受限制的语言，只是与更现代的语言相比，编程速度慢且容易出错。哦，除了在CRT中。例如，Lua不包含目录功能，因为它不是CRT的一部分，所以无法在标准C中实现可移植性。这是C语言的一种限制方式。但在语言特性方面，它并没有受到限制。
如果您想构建一个论点，说使用C实现的语言具有XYZ限制或特征，则需要证明在C中另外实现这些功能是不可能的。
- Puppy
8
1你说得有道理，我点了个赞，但请注意，即使是Lua和Perl仍然是命令式语言。函数式语言（如Haskell、ML衍生语言、Pure、Clean）通常不会用C编写。我认为这是因为创建这种语言的人已经了解其他函数式语言，其中大多数比C更适合编写编译器。 - user395760
7你“不赞成 c 语言”？哇，这听起来很严厉。虽然我不喜欢使用 Java，但我只是选择不用它，我将我的不赞同留给更加严重的事情，比如捕鲸和穿袜子配凉鞋等恶劣行为。 - AShelly
@delnan：看一下bdonlan的回答。他们将Haskell预处理成C语言。
@AShelly：这真的不是答案的重点。 - Puppy
@DeadMG：我知道 GHC 可以输出 C 并通过 gcc 编译它，但这是不同的——首先，这只是运行 Haskell 的几种方式之一，其次，GHC 本身就是用 Haskell 写的。 - user395760
@delnan：那又怎样？你可以将Haskell转换成C。这就是我的回答的重点。 - Puppy
显示剩余3条评论
5
即使使用C实现，你在实现方面仍然有很大的自由度。例如，chicken scheme 使用C作为中间语言，但仍然成功地将堆栈用作其垃圾收集器中的幼年代。
话虽如此，在某些情况下会存在一些限制。一个例子是：GHC Haskell编译器有一个名为Evil Mangler的Perl脚本，用于更改GCC输出的汇编代码以实现一些重要的优化。他们正在向内部生成的汇编和LLVM转移，部分原因就在于此。话虽如此，这并没有限制语言设计，只是限制了编译器可用优化的选择。
话虽如此，在某些情况下会存在一些限制。一个例子是：GHC Haskell编译器有一个名为Evil Mangler的Perl脚本，用于更改GCC输出的汇编代码以实现一些重要的优化。他们正在向内部生成的汇编和LLVM转移，部分原因就在于此。话虽如此，这并没有限制语言设计，只是限制了编译器可用优化的选择。
- bdonlan
4
C堆栈就是系统堆栈，这个概念比C出现得早得多。如果你学习计算机理论，你会发现使用堆栈非常强大。
使用C实现语言对这些语言的影响可能很小，但设计和实现语言的人对C（和其他类似C的语言）的熟悉程度可能对其设计产生了很大影响。即使你没有在积极地复制另一种语言的最佳部分，当你看到之前的东西时，很难不受到影响。
许多语言确实使用C作为它们与其他事物之间的粘合剂。其中一部分原因是许多操作系统提供C API，因此要访问它很容易使用C。此外，C非常普遍和简单，许多其他语言都有某种方式与之交互。如果您想将两个用不同语言编写的模块粘合在一起，则使用C作为中间人可能是最简单的解决方案。
使用C实现语言对其他语言的影响可能最大的地方可能是字符串中如何进行转义，但这可能并不具有限制性。
使用C实现语言对这些语言的影响可能很小，但设计和实现语言的人对C（和其他类似C的语言）的熟悉程度可能对其设计产生了很大影响。即使你没有在积极地复制另一种语言的最佳部分，当你看到之前的东西时，很难不受到影响。
许多语言确实使用C作为它们与其他事物之间的粘合剂。其中一部分原因是许多操作系统提供C API，因此要访问它很容易使用C。此外，C非常普遍和简单，许多其他语言都有某种方式与之交互。如果您想将两个用不同语言编写的模块粘合在一起，则使用C作为中间人可能是最简单的解决方案。
使用C实现语言对其他语言的影响可能最大的地方可能是字符串中如何进行转义，但这可能并不具有限制性。
- nategoose
3
唯一限制语言设计的是语言设计者的想象力和技术技能。正如你所说，C可以被认为是“可移植汇编语言”。如果这是真的，那么问C是否限制了设计就类似于问汇编是否限制了语言设计。由于任何语言中编写的所有代码最终都会作为汇编执行，因此每种语言都会受到相同的限制。因此，C语言本身没有强加任何约束，这些约束将通过使用不同的语言来克服。
话虽如此，在一个语言中做某些事情比在另一个语言中容易。许多语言设计师会考虑到这一点。如果该语言被设计成具有强大的字符串处理功能但性能并不是一个问题，那么使用具有更好内置字符串处理设施（例如C ++）的语言可能更加优化。
许多开发人员选择C有几个原因。首先，C是一种非常常见的语言。特别是开源项目喜欢它相对较容易找到经验丰富的C语言开发人员，而不是在其他一些语言中找到同等水平的开发人员。其次，C通常适用于微观优化。在编写脚本语言解析器时，解析器的效率对该语言编写的脚本的整体性能有很大影响。对于编译语言，更高效的编译器可以减少编译时间。许多C编译器非常擅长生成极其优化的代码（这也是许多嵌入式系统使用C的原因之一），并且关键性能代码可以用内联汇编语言编写。此外，C是标准化的并且通常是静态目标。代码可以按照ANSI / C89标准编写，而无需担心它与未来版本的C不兼容。在C99标准中所做的修订增加了功能，但不会破坏现有代码。最后，C非常可移植。如果给定平台上至少存在一个编译器，则最可能是C编译器。使用像C这样高度可移植的语言使得更容易最大化可以使用新语言的平台数量。
话虽如此，在一个语言中做某些事情比在另一个语言中容易。许多语言设计师会考虑到这一点。如果该语言被设计成具有强大的字符串处理功能但性能并不是一个问题，那么使用具有更好内置字符串处理设施（例如C ++）的语言可能更加优化。
许多开发人员选择C有几个原因。首先，C是一种非常常见的语言。特别是开源项目喜欢它相对较容易找到经验丰富的C语言开发人员，而不是在其他一些语言中找到同等水平的开发人员。其次，C通常适用于微观优化。在编写脚本语言解析器时，解析器的效率对该语言编写的脚本的整体性能有很大影响。对于编译语言，更高效的编译器可以减少编译时间。许多C编译器非常擅长生成极其优化的代码（这也是许多嵌入式系统使用C的原因之一），并且关键性能代码可以用内联汇编语言编写。此外，C是标准化的并且通常是静态目标。代码可以按照ANSI / C89标准编写，而无需担心它与未来版本的C不兼容。在C99标准中所做的修订增加了功能，但不会破坏现有代码。最后，C非常可移植。如果给定平台上至少存在一个编译器，则最可能是C编译器。使用像C这样高度可移植的语言使得更容易最大化可以使用新语言的平台数量。
- bta
3
我想到的一个限制是可扩展性和编译器托管。以C#为例，编译器是用C/C++编写的，完全是本地代码。这使得在C#应用程序中使用它非常困难。
这对C#的工具链有广泛的影响。任何想要利用真正的C#解析器或绑定引擎的代码都必须至少有一个组件是用本地代码编写的。这最终导致了大部分C#语言的工具链都是用C++编写的，这对于一种语言来说有点倒退。
这并不限制语言本身，但肯定会影响语言周围的体验。
这对C#的工具链有广泛的影响。任何想要利用真正的C#解析器或绑定引擎的代码都必须至少有一个组件是用本地代码编写的。这最终导致了大部分C#语言的工具链都是用C++编写的，这对于一种语言来说有点倒退。
这并不限制语言本身，但肯定会影响语言周围的体验。
- JaredPar
2
...但也许如果他们用C#编写下一个 C#编译器，但是使用当前用C语言编写的编译器进行编译... - FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner 确实，那是一个选项。 - JaredPar
2
垃圾回收。基于Java或.NET的语言实现使用虚拟机的垃圾回收器。而基于C的语言实现则倾向于使用引用计数。
- dan04
7
6大多数Java和.NET虚拟机是用C或C++编写的。 - Jerry Coffin
JVM/CLR是用哪种语言编写的？Sun的JVM是C++，我猜CLR也是如此。好吧，这比C高了一步，但仍然... - user395760
1我认为 C 语言中的垃圾回收不应该仅限于参考计数方案（即使这可能是最容易实现的方案）。据我所知，Hans Boehm 的 GC 是很不错的 C 语言 GC 之一。 - stakx - no longer contributing
1++ 感谢 @stakx 提到 Boehm。它是保守的（例如不会捕获所有对象，只能捕获大部分），但不使用引用计数。 - user395760
@stakx：我敢打赌CLR不是使用COM编写的（COM是用C实现的）。 - JeremyP
显示剩余2条评论
1
我能想到的一件事是，函数在语言中不一定是一等成员，这不能仅仅归咎于C语言（我不是在谈论传递函数指针，尽管可以说C语言提供了这个功能）。
如果用groovy(/scheme/lisp/haskell/lua/javascript/还有一些我不确定的语言)编写DSL，函数可以成为一等成员。使函数成为一等成员并允许使用匿名函数可以编写简洁且更易读的代码（就像LINQ所演示的那样）。
是的，最终所有这些都在C语言（或者如果你想达到那个级别，汇编语言）下运行，但是从提供语言用户更好地表达自己的能力方面来看，这些抽象化做得非常出色。
- Gangadhar
1
1在C语言中实现类似于一等函数的东西看起来非常丑陋，是的。但同样适用于动态类型、对象和其他十几个基于C的语言特性。 - user395760
1
在C语言中实现编译器/解释器没有任何主要限制。另一方面，将语言X实现到C编译器则有限制。例如，根据C--的维基百科文章，编译高级语言到C时，你不能进行精确的垃圾回收、高效的异常处理或尾递归优化。这是C--旨在解决的问题类型。
- dsimcha
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接