程序员是否应该创造面向 IDE 而非人类的编程语言?

本文探讨了编程语言设计的一种新思路:是否应为IDE而非人类创造编程语言,以解决当前编程语言在表达复杂概念时的局限性。文章讨论了文本表示的缺点,如数学表达式的晦涩、变量命名限制及在智能手机上的编程挑战。通过分析HackerNews上开发者的观点,本文深入探讨了格式与语义耦合的问题,并提出了解耦方案。同时,文章还讨论了Smalltalk和Literate Programming的概念及其面临的挑战。

640?wx_fmt=gif

我一直在思考一个问题:为什么我们要为人类创造编程语言,而不是为IDE创造编程语言,然后用人类可读的格式来显示程序呢?

640?wx_fmt=jpeg

用文本来表示数学表达式是非常糟糕的方式。

640?wx_fmt=png

完全不如下述表达式清晰:

640?wx_fmt=png

在处理编程语言中向量等非简单类型的时候情况会更糟,你只能通过引用传递结构。如果你不想耗费无谓的内存开销,那么就必须使用如下形式:

640?wx_fmt=png

这些还只是最简单的公式。我在做图形引擎的开发时编写的着色器代码在调试时就是一个噩梦,因为它的表现形式十分晦涩难懂。

其次是变量的命名。再次举一个数学的例子:P(A | B)能够精准地表达含义且易于理解,并且简洁易于辨认。不幸的是大多数的编程语言都不允许我们以P(A | B)的形式命名变量。同样,有关camelCase和snake_case的争论也是由于不能在变量名中使用空格而造成的。

另一个问题是:我们如何在智能手机上编程?虚拟键盘不适合代码,基于图形的解决方案可能有效,但我很确定没有多少人喜欢在台式机上绘制图形。

制表符和空格的争论也是另一个由文本书写代码的假设引起的。同时,这两种方法都是严重过时的对齐工具。

对于上述每种情况,关键问题都在于格式和语义之间存在紧密耦合。只要我们以纯文本显示代码,就会产生这些问题。

连字和自定义运算符提供了一些帮助,但这些方法始终没有解决核心的问题。

那么如果我们将文件的表现从纯文本改成其他更丰富或结构化更强的形式呢?通过去除这种格式和语义之间的耦合,我们还可以在不同的系统上使用截然不同的格式(例如图形编辑器),然后修改底层相同的语义。

对此,你怎么看?

 

640?wx_fmt=png

Hacker News 上开发者的观点

 

评论1:

你忽略了一点:文本文件是最简单的。虽然有时它们可能有点麻烦,但作为“构成表达的物质”,它们是无可比拟的。你可以使用现有最常见的人机界面设备来创建或修改文本,现在的孩子在上学之前就学会使用文本了。你可以阅读包含一百万种不同程序的文本,并对其进行样式化、过滤、格式化、剪切和粘贴以及其他无数的操作。书写方程式时的不足只是为这种灵活性付出的很小的代价。

如果按照你提议的方式“解耦”格式和语义,那么将无法避免语义与编辑器的耦合。这种情况下就只能使用一种编辑器,直到你开发出其他一些可以与语法树的结构化表示交互的东西。并不是说我们做不到或不应该这么做,APL就曾经做过,像Scratch这样的教育工具做得也很好,当然还有各种“无需编程经验”的流程图和建模语言,但是这种想法只能在一些非常具体的情况下才能与文本文件对抗。

评论2:

我觉得Smalltalk可以作为一个回答你的问题的例子。Smalltalk就像你描述的那样:一种为IDE构建的语言。你无法在该IDE外部使用这种语言,因为它没有按照纯文本的格式存储数据,而是采用了图像格式。该IDE为用户提供了各种不错的功能和分析,自从20世纪70年代创建以来,Smalltalk的创意已经影响了许多其他语言和IDE。那么为什么我们都不使用Smalltalk呢?我认为关键在于互操作性。Smalltalk是一个独立的世界。它无法与Smalltalk世界之外的工具很好地交互。例如,如果不解决如何以二进制的图像格式合并代码,那么就不能享受Git带来的便利性。当我需要完成一项特定的任务时(比如某种构建任务),我需要知道如何使用Smalltalk的工具在Smalltalk世界中完成所需的一切。Smalltalk违背了Unix哲学:它提供的不是一个功能,而是所有一切,因为它是一个微型的虚拟机。

我无权说这是我们不使用类似于Smalltalk的语言编程的所有理由,但是我觉得这是其中一部分理由。很多新的编程语言在尝试用新的方式、交互式的方式推动编程语言(例如Eve),但它们都没有解决关键的问题或赢得人们的认可。其中必然存在一些内在的原因为什么这样的语言无法取得成功。希望以上文字可以提供一些见解!

评论3:

Donald Knuth在1979年描述了Literate Programming的概念(https://en.wikipedia.org/wiki/Literate_programming)。

我之前公司的一位同事Raymond Chen在研究生期间是Donald Knuth的学生,他曾用过Donald Knuth的Literate Programming进行编程。

但他建议是不要采用这种编程方式。

原文:https://dev.to/drbearhands/should-programming-languages-be-made-for-ides-rather-than-humans-3dnf

作者:DrBearhands,软件工程师和数据科学家,他感兴趣的领域有人工智能、3D算法(图形、导航等)、逻辑、高性能计算/并行、功能编程和创新。

译者:弯月,责编:郭芮

【完】


 

微信改版了,

想快速看到优快云的热乎文章,

赶快把优快云公众号设为星标吧,

打开公众号,点击“设为星标”就可以啦!

640?wx_fmt=gif

640?wx_fmt=jpeg

推荐阅读:

640?wx_fmt=gif

640?wx_fmt=gif

本指南详细阐述基于Python编程语言结合OpenCV计算机视觉库构建实时眼部状态分析系统的技术流程。该系统能够准确识别眼部区域,并对眨眼动作与持续闭眼状态进行判别。OpenCV作为功能强大的图像处理工具库,配合Python简洁的语法特性与丰富的第三方模块支持,为开发此类视觉应用提供了理想环境。 在环境配置阶段,除基础Python运行环境外,还需安装OpenCV核心模块与dlib机器学习库。dlib库内置的HOG(方向梯度直方图)特征检测算法在面部特征定位方面表现卓越。 技术实现包含以下关键环节: - 面部区域检测:采用预训练的Haar级联分类器或HOG特征检测器完成初始人脸定位,为后续眼部分析建立基础坐标系 - 眼部精确定位:基于已识别的人脸区域,运用dlib提供的面部特征点预测模型准确标定双眼位置坐标 - 眼睑轮廓分析:通过OpenCV的轮廓提取算法精确勾勒眼睑边缘形态,为状态判别提供几何特征依据 - 眨眼动作识别:通过连续帧序列分析眼睑开合度变化,建立动态阈值模型判断瞬时闭合动作 - 持续闭眼检测:设定更严格的状态持续时间与闭合程度双重标准,准确识别长时间闭眼行为 - 实时处理架构:构建视频流处理管线,通过帧捕获、特征分析、状态判断的循环流程实现实时监控 完整的技术文档应包含模块化代码实现、依赖库安装指引、参数调优指南及常见问题解决方案。示例代码需具备完整的错误处理机制与性能优化建议,涵盖图像预处理、光照补偿等实际应用中的关键技术点。 掌握该技术体系不仅有助于深入理解计算机视觉原理,更为疲劳驾驶预警、医疗监护等实际应用场景提供了可靠的技术基础。后续优化方向可包括多模态特征融合、深度学习模型集成等进阶研究领域。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

优快云资讯

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值