分享 编程语言的语法就该类似这样

maglev · July 28, 2021 · Last by maglev replied at August 09, 2021 · 1446 hits

如果有一门编程语言的语法能类似下面这样,我看行。

结构化编辑器(例如 MPS)就可以做到,不过是不是比原来容易写(大概率不是),是不是比原来易读(一半一半)

Reply to mizuhashi

比这例子更容易读那就不设强类型,把颜色分配给其他功能

啊?这是编程语言?昨天我看到还以为是编辑器配色方案😓

Reply to gaicitadie

😄 是啊,可是编程语言也不是语言。人机交互原则是怎么方便怎么来。搞个编程输入法在输入效率肯定比拼音输入法高好几个级别。块代码还是像 python 装饰器那样固定为下一行效果好,符号可弄个更好的。if 语句组的符号如果不够直觉化,可以重想一个更直觉化的。要真有那样的编程语言,哪怕是定位幼儿编程语言,也是极好的。

结构化编辑上,给 Lisp 做自动缩进和加括号的努力 Parinfer 都不温不火,如今仅剩一个 Rust 实现在延续,而 Lisp 的语法已经是很简单的了,我认为可能是最适合发展结构化编辑的编程语言了。

编程语言的可读性我觉得不在于块结构上面,像 Ruby VB Elixir 这种有 end 的、和 C 风格的花括号,都没有什么高下之分,甚至 Python 备受嘲讽的“游标卡尺”能不能作为一个成立的笑话都不一定。真正拉开差距的是其他地方吧:比如 Perl 被认为是只读语言,就是因为写法灵活加上魔符的大量使用,导致回头看的时候很难一眼知道这是在干啥;Rust 使用所有权来保证安全,付出的代价就是些许语法噪声和编码时消耗更多脑力;Go 的生态中大量推崇代码生成器,虽然确实显式但缺乏了对常见模式的抽象;编程语言之外的 CSS 本身设计很好,但早期浮动布局时代的清除浮动等等充斥着反模式,加上至今也不支持文本结构上的“层叠”导致风评被害;所以如果把改造重心放在块结构上面效果没多大用,何况你提出的这个方案能不能称得上改造还有待商榷(比如说石头剪刀布的设想,凭啥石头代表 if?凭啥?说神经病一点不冤)。

另一个是很可能会走 DSL/Low Code 的老路:有很多 DSL 作为使开发人员快速解决领域问题的语言,却怀着扩大疆域到非开发人员的行业人员上,因此为了隐藏基于文本的控制流和逻辑复杂度,使用从 GUI 借来的经验来提升可读性,结果就是:辛辛苦苦造出来的 DSL,行业人员因为没有简化领域的根本问题而不会去使用,开发人员因为过于和领域问题耦合,无法和其余生态配合而不学。所以在这个连 DSL 都只剩下 eDSL,Low Code 基本只在 CRM 和表单生成器发光发热的时代,很难说这样一种没有完全脱离文本,又要强制在所有地方融入基于图形的结构化表征的思路,会产生什么成功。

我的感觉是,要不就完全图形化,像面向少儿编程的 Scratch,或者问卷星;要不就专攻文本,通过完善 IDE(起码要达到当年 SmallTalk 的水平吧)和提升语言/库在控制流上的支持(比如 Elixir 的那些控制流都是宏写出来的,核心只有模式匹配,这样能够很方便的造出新的控制流,甚至实现 Pipe),要么就二者融合,但保证可选(如一个 Business Logic 引擎,既可以让用户拖拖拽拽定义审批流,开发人员又可以对这个审批流进行 Transform 之类的;或者交互式编程中,Mathematica 以及其他领域的 Notebook 就是把图形表示嵌入语言的良好实践)。

原来这个叫结构化编辑

感觉单独提出来作为一种语法不太合适。但是若能够对已有语言解析生成这些字体,颜色,流程箭头等特征,还是非常有帮助的,期待早日开发出来

Reply to 459650075

鉴于已经有那么多让机器高性能的的编程语言,我只说两件事,1 精力是编程者的,2 算力是机器的。讲那么多我听不懂,你讲的太权威了,甚至带点法西斯卷心菜味道,

Reply to maglev

不是……语言能使机器高性能,和可读不可读,开发者的心智负担高不高有什么关系呢?带有函数式血统的语言,比如 ML 和 Lisp 家族由于使用 Lambda 演算而非图灵机作为模型,性能上可能会比较难以优化,可这也不影响可读性好,心智负担低啊?转过来想汇编性能最高,甚至 Chez Scheme 作者自己写 Intel 的汇编器,可是现在除了搞 JIT 的、搞模拟器的、搞 CPU 的还有搞 BIOS/UEFI Bootstrapping 的,还有谁会平时写汇编嘛?

结构化编辑作为辅助声明式语言的优秀工具,虽然由于场景有限导致发展不大,但我还是一把子支持的。不过你这个感觉要走的路就很长啊,比如为啥要以交通灯和石头剪刀布代表控制流,这个本身就不自洽的情况下当作文本之外的视觉辅助还姑且能用,可是你一开始就把文本符号去掉了,不就白费功夫了吗。

用颜色、字体和字体装饰来修饰 token 的类型就更怪了。别的语言使用 CamelCase、kebab-case、snake_case 及其变种来充当规范,这还不够还需要加上魔符来提示,早期的工程更是大量使用匈牙利命名法。而你这个真的三眼都看不出来是什么东西的。再退一万步讲,色盲色弱怎么办?

循环语义和定义类的结构倒比较合理,其中使用类似表格定义的方式让人很难不想到 COBOL。不过 COBOL 能够那样做的原因是它太简单了,把它认为是商务的 DSL 的不冤枉的。

代码是写给人看的,这种代码鬼都看不懂。大家居然还在下面一本正经讨论,让我感到匪夷所思。

楼上两个不要羡慕嫉妒恨啦,否则 python,Ruby 等动态里面都要被你们骂出翔了。

You need to Sign in before reply, if you don't have an account, please Sign up first.