我知道这是非常抽象的,但我相信它非常集中。
今天有很多高级语言:C#、Java、VB、Python等,所有这些语言都是为了抽象出低级复杂性并提供更加用户友好的编程体验而创建的。高级语言可以减少并在大多数情况下完全消除执行低级、特定于进程的操作(例如指针操作和内存管理)的必要性。许多还删除了平台细节(如文件操作、用户界面生成等)
我的两个问题是:
- 还有什么可以/应该抽象的?在当今的高级语言中是否存在更多将/应该进一步抽象的低级语义?
- 通用的高级语言在什么时候变得非常高级,也就是面向目标的?
我知道这是非常抽象的,但我相信它非常集中。
今天有很多高级语言:C#、Java、VB、Python等,所有这些语言都是为了抽象出低级复杂性并提供更加用户友好的编程体验而创建的。高级语言可以减少并在大多数情况下完全消除执行低级、特定于进程的操作(例如指针操作和内存管理)的必要性。许多还删除了平台细节(如文件操作、用户界面生成等)
我的两个问题是:
在语言中包含非常高级抽象的问题之一是,有时它们不足以完成您想要完成的所有事情,因此您最终也需要较低级别的抽象。在同一种语言中具有高级抽象和低级抽象的问题在于,如果您可以通过低级抽象来探测高级抽象,它们很容易泄漏。
例如,Java 甚至不是一种高级语言,但它的设计首先是安全的(在抽象不会泄漏的意义上)。因此,有些事情在 Java 中是不可能做到的。例如,您不能在 Java 中编写 Java 的垃圾收集器,或者使用指针转换多态来滚动您自己的对象系统,或者编写操作系统(至少不是传统的操作系统)。
相比之下,D 提供高级和低级设施。例如,D 的垃圾收集器是用 D 编写的。这听起来不错,而且大部分情况下确实如此。但是,当您开始在单个代码库中混合抽象级别时,抽象可能会泄漏,尤其是当您使用强制转换或联合来破坏类型系统时。因此,为了在 D 中成功编程,您可能偶尔需要了解一些低级细节来处理泄漏抽象,即使您手头的任务不需要它们。
但实际上……当然,这条线完全是任意的。
某些特定领域的语言可能非常“高级”。一个很好的例子是Inform(用于编写文本冒险),其中编程语言与普通英语没有太大区别。以下是示例项目的摘录:
The fireplace is scenery in the Entrance Hall. The description is "Unlit, vacant
[if Search is happening]. It is almost as though you are not expected[end if]."
The sound of the fireplace is "whistling wind". Understand "fire" or "whistling"
or "wind" as the fireplace. Instead of burning the fireplace: say "There is no
fuel prepared for a fire."
这是实际的源代码。:)
我认为一种假设的未来语言将允许您编写验证器而不是实现。然后编译器分析该验证器并(尝试)编写与您的规范匹配的实现。(显然编译器有时必须失败或退回到蛮力,因为它不是一个停止求解器。)
本质上,与暴力破解答案相比,一种具有荒谬优化的逻辑语言。
尽管验证代码可能比实现代码更长,但它可以作为更好的文档,并且更接近规范的外观。您可以用更多的代码输入时间换取更少的文档/规范/代码不同步。
例如:
int32 Remainder(int32 numerator, int32 denominator) {
requires denominator != 0
ensures Math.Abs(result) < Math.Abs(denominator)
ensures exists n suchthat n*denominator + result == numerator
}
int32 EuclideanRemainder(int32 numerator, int32 denominator) {
requires denominator != 0
ensures result >= 0
ensures result < Math.Abs(denominator)
ensures exists n suchthat n*denominator + result == numerator
}
结果是:
//warning: suggested precondition: denominator != int32.MinValue due to Math.Abs
int32 Remainder(int32 numerator, int32 denominator) {
return numerator % denominator;
}
int32 EuclideanRemainder(int32 numerator, int32 denominator) {
return ((numerator % denominator) + denominator) % denominator;
}
Tcl 有一个官方提案(Tcl Improvement Proposal (TIP) 131,它几乎可以永久解决问题。它所需要的只是一个志愿者来完成这项工作。甚至还有一个骨架实现,只省略了一些细节。
Hrm,我认为一些语言正在尝试带头一些额外的抽象:带有 STM 的 Clojure 和带有 Actor 模型的 Erlang。
想象一下它们在一个统一的环境中的结合,因为开发环境是开发的重要组成部分,就像人们可以访问的库及其访问级别一样。
我认为框架是下一步。