duangsuse::Echo

#js #code 再来说个有趣的：动态作用域 🥰 a=3 - f(a)=a+1 f(1), a //2, 3 >请把程序写成数组的形式 (也就是“更易做”正则替换) with(DSL) $dyn=[ [a,3], [f, [[a], [0, [a],1,['+'] ]] ], [r0, [0, 1,[f]], [a]] ] DSL=new Proxy({},{get:(o,k)=>k, has:(o,k)=>k[0]!='$'}) 在这个解释器里，$=, ()=>[] 就是内联宏啦，反正函数不能跳转…

#statement #dev readability :
@duangsuse 其實我覺得你的 code 有個小缺點：不好讀
太像 minified 的程式碼了……

duangsuse, [2023/10/2 19:48]
欸，是啊😓
像 min.js
或许我应该写文档。因为，我是把贴文里已经说了的eval规则，直译为JS了，没有把细节写得很明确

我这个贴文主要是讲原理，写示例的时候，并没有把它视为应用代码的，就写得比较急，随意😓

duangsuse, [2023/10/2 20:09]
加几个换行只会让程序看起来逼格更高吧…… 没有注释也一样难读
或许是我的分词语感更紧凑，我觉得?换行: 这样让人找不到重点，更别说满屏幕 if else{} return 取代 when 和“map=>重写”等意图

duangsuse, [2023/10/2 20:12]
所以我一般是不写代码，只说明心智模型的。当然有时间的时候也会写点注释

我是觉得，如果Devs只是看到了很合规的源码，「能够准确分词」，但get不到语义的话，是不能继续添加功能的。 能用和懂之间的差别，不是在是否 syntax error 上。
只有对自主默写有用的代码风格，那才是实质上的读懂

一般来说我写代码都是 quick prototype ，像这样重写…… 我做的设计很多，所以拖得很后很后

ram:
我们对于可读性的认知的偏差，应该是来自于参与过的软件工程项目。
在我的理解里，代码不仅仅是为了自己此刻的理解而写，也是为了 reviewer 和其他 contributor 甚至是多年后自己的理解而写。

没有 abstraction layer 的写法我只在 code golf 里面见过。code golf 的大部分人是先写 proper code 再手动改成那个难读的样子的

duangsuse, [2023/10/2 20:35]
我的原文里，这是用来把

- just(a)
  - f()=a
  f
just(0)()

语法结构：

with(DSL)$lex=[[],
  [just, [[a], [f,[[],[a] ]], [f] ]],
  [f,[0, 0,[just]]],
  [0, f]
]

对应到JS：

()=>(just=(a)=>(f=()=>(a),f),f=just(0),f())

为此请判定3种规则：
[refval], [rv, vs] 引用-重赋值
[[args], funCalls] 箭头函数/整个文件
[0,arg, fn] 向栈变量赋值

如果抛开作为示范实现的 JS，可读性还可以

duangsuse, [2023/10/2 20:18]
因为贴文里，我主要是讲原理，不能贴长篇代码👀。我的抽象层就是「中文」。以后有机会转Web 我会写明确命名版
我都不知道贴文有几个人阅读，是笔记。我每天背后有不会发的设计，都在耗时的……

这个真的就是快速开发的问题，我从来不以JS,Py 这样的代码的有损形式「维护项目」的。都是设计稿。

duangsuse, [2023/10/2 21:38]
编译原理有一大堆应用层用不到的概念，或者说「意义未知的算式」。
当你想要跨界（尤其是直接上手写能用的 interpreter ），就要做好增加词汇量的准备。像SQL那样禁用缩写，只是新手入门的辅助记忆法，晚点也会被 BaaS,GraphQL,ORM 那样的技术替换

我是挺希望有编程语言，能同时照顾新手的迷茫和老鸟的读写效率，
因此我的绝句里有规范 - Str.as(regex:Str.RE, :[Fn1 Str.RE.Paren]-Str) Str, -'T' swap (A:[Var T], B:Var“or @T”) 等等缩写法和约定俗成，不要因为没 boilerplate 而不易读

主要是我要反思自己的设计，因为能提升的还有太多（我现在看知乎，唯一就是要寻找「灵感」，真的很有效）他们的理论或许很绕，但给我了一个切入点思考自己的
Kotlin 正则的 "abc".toInt()?.let{} ?: 0 甚至比 bool 有效。但正则不是模块化层面的问题…… 它就是「有缺点的战士」

duangsuse, [2023/10/2 20:43]
还有种可能.. 我自己的代码在用『物理命名法』来写这个第一版的👀，它标明了类型：
a数组, e树叶 v值 N计数..
许多人没法用这些单字断言变量的含义，阅读时就会很迷糊。
但如果我不用物理名字，我就无法快速地完成代码，而且会各种 type mismatch 。 😱

物理命名，这种对「编程世界」的归纳对我个人而言，是种革命，让我的代码能横跨更多平台/博采到更多文章🦄 ，无视变量间无谓的术语差异、减少新功能的代码量

但美中不足，它与其他程序员的习惯相悖🙇🏾…… 许多人不习惯单字符，更没有 '所有可索引值都叫 aXXX' 这种认知。如果有一门主攻语言的话，是不需要这种「超出文字」的编程模型，来解读代码的

我没法在教 tree walk 的帖子里，教读者JS原型链是怎么一回事。我以为在这时缩短篇幅，会让读者抓住重点，
—
谁知道大家都是「通篇阅读」我的代码，而不是：找出code和我贴文所述概念的「联系」

就像视频有「60fps vs 关键帧+弹性动画」，音乐有「441k vs .midi+乐器包」，图片有「500px vs SVG+滤镜」
代码也有「1个月5万行 vs 100行的'定义式框架'+keypoints」。极简主义者都属于后者。我告诉电脑怎样漂亮，不是它命令我'必须500px' 或怎么写。

编程界确实存在一种频谱，能无视术语和范式，绕过一切的烧脑的刻板印象，只量化每个函数本初的比重，一统工程和学院派：在写到纸上/内存上之前，我们对代码已心如明镜。
只试两次对错，是没法在第三次发现进步的。方法论总会反转，与其嘲笑旧的不好，更要明白它错在哪、又好在哪！

— 🤔💭
我们程序员对一段功能的「设计力」，不是按「能读懂的术语表」来计算的，小心伪理解。
你要建立的思路和关系，是：变量|此问题的领域，而非变量|仅有名字相同的常识。只懂常识难有创作

我已经习惯于用「必须要定义/调用的API」来解析代码了， 我看不懂的代码是不会逐字猜测的
是我先站在作者的视角，去推测他的选型和「私货」，然后慢慢把我的猜测与实际合一；这时短的魔法是不影响理解的👀

对不懂中文的人来说，优美和丑陋的中文词汇/文章结构都是难读的，你要先熟悉语感。对任何编程项目也一样。

CSS规范就像这术语表，但设计的实质，是 tailwind 那样“有规范地杂乱”。我的文章是教你规范，代码仅供示范
如果你是为了用现有的心智模型，看懂代码，那你的收获只会小于 Google 爬虫对文章做的关键词聚类。而当你get到算法的思想，会发现你仿佛见过那些“全新流行”的文本，过目不忘。