gh login
gh new-repo $(rand).paradigm.org

loginGh(id, secret): VO
newGhRepo(id): VSO

gh=Gh.login(id,secret): SV
gh.newRepo: SVO
# 范式是跨语言的
(u= gh login root toor)=="gh badguy"
$u repo new (randProj)

这样才符合人类直觉： 不要光 call, 要 with 🥰

虽然他没有“优化掉”arg0（为全局 省字数），但因为全局是可以随便加的，class{} 键值是密封的，在开小号之外，我们又有了类型和补齐

gh=Gh.new(id,secret): Snew
gh.Repo.new('jackass'): SnewO

Gh.static.setApiURL(): SgetsetO
这一条是不依赖登录的（静态函数）。

Gh.login(uid,secret, otp=> device._2fa.get(otp))

一般来说，FP 用户不会缺少对OOP的进阶理解，比如用 get(otp) 重载 db.otp.getKey(otp) 、用 atoi:Int=>[Int ValueError Mayfail]，这种摘要性（或者说严谨）好的心智模型，而不是和JQ那样只懂起名和拼凑调用链的库一样。
Vue对单 ref() 多显示的理解也是靠起名无法实现的。

btw. 命名动词还是有意义的。 比如佐人经常区分「买」和「雇佣」，「赤字」和「借」，但事实上是一样的。 混淆视听会损失类比的空间。

# 指针宽度

指针就是超链接。 它的域名是你的内存，地址是一个64或32位的整数，有 rw, r, rx 三种经典鉴权段位。 对JVM和v8来说，并不是所有bit都用于标记一串byte元组(struct)的读写位置，至少x64上的void* 只有52个有效位。
C, Java, JS(Vue) 里本质上是指针(Any/interface{}类型) 的模型，信息量也不同。

C: 单个内存地址，比如x32就是2**32, 4G 随便存，x64就是天文数字 （但是没有意义，比如，连是 int, 普通struct, Umbrastr 都分不清，需要printf手写%d ）
Java: this=data+funcs 双指针，把变量树和方法表存在一起，可以 override ，再比如用 args=Array[0:length] 取代 (argc,argv) 元组，也是头尾双指针
Vue: ref()= N个回调 多指针， 回调可用于赋值，可以随便组合数据与计算、业务逻辑；SQL外键同理，可以用于拆分表单，多处复用

# 类型系统

C: 基于sizeof，没有 range/str/list/kv(tuple set) 等(可变)容器， 没有 T::fun 等模块化
Java: 基于 obj.(type) ，类型存在于编译期和运行期，可以数据化（反射），可以像函数值字典的Builder一样写class{}
Vue: 因为领域不同，JS 更重视业务而不是可维护性。 类型只是IDE的工具，没有优劣，🤓 DOM 的宽广和稳固、框架的繁荣让JS无需类型即可安全高效

最后，在标志性「语言特性」上，自古以来是这样：
- biosC=x86nasm+函数和8种整数的超链接
- C=biosC+ld文件maps内存段+CPU分片 (作为"libc的JVM")
- PyJS=C+双指针和kw左值传参 [双指针fatPtr] ([len,] {type:}和{proto:{vtable}} {_树内硬链接refcount:0} 均占用16byte)
- FP=PyJS+单函数组合+正择解构再构 (谈UIUX框架，没有[轮询或卡线程pull]是evpoll&push、多监听取代不了的，只是，C的无闭包和while(1)死循环，禁止了回调链表新加异步栈)

import scrypt
scrypt.hash("text", "abra.js", N=2**21, r=8,p=1) 

#https://www.jsdelivr.com/package/npm/scrypt-pbkdf 慢一点
let { scrypt } = await import('https://esm.run/scrypt-pbkdf'); alert(await scrypt("text", "abra.js", 64, {N:2**20, r:8,p:1})) 

臉書的人在介紹 GraphQL 時，寫了一篇很好的文章，說明為什麼 REST 變得有問題： https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html#why-invent-something-new 他們沒有那麼嚴厲，也承認 REST 確實解決了一個問題。

從他的文章裡：

但現在是時候打破沉默，承認 RESTful API 的概念可能是網路軟體史上被廣泛採用的最糟糕的點子之一。 Roy 可能是一個很棒的人，而且他肯定有很多很棒的想法。 然而，我不認為 RESTful API 是其中之一。

HATEOAS： 要符合 RESTful，你的應用程式需要公開一個初始 URI，並讓你的應用程式中的所有狀態變化都可以通過超媒體「被發現」。 這也很有局限性。 SOAP 試圖解決其中一些問題，但它並沒有取得多大成功，而且也不是銀彈

国内编程界经典拿“底层实现”当“本质”的遗毒之一，其他的例子还有谈虚函数（甚至谈子类型多态）必须扯虚表，谈Promise必须扯事件循环等等。必须用这种朴素的还原论才能理解上层的性质吗…其实恰恰相反，并非底层的实现决定了上层的性质，而是上层的性质要求了底层如此（只是一种可能的）实现

其实现在的内存分配器早就不基于堆数据结构了（叫自由存储区还比这靠谱点），函数调用时也不保证总会生成一个栈（例如内联成功的函数），局部变量有时也会被优化到寄存器上，全局常量也可能被优化到不占常量区空间。如果仍然假定总会生成一个栈，容易写出未定义行为，导致程序出错，不如学习更加正规的c++内存模型：函数体内的普通变量是自动生命周期，定义时构造，函数体结束时（抵达｝时）释放；全局变量是静态生命周期，程序启动时（进入main函数前或dll加载时）构造，程序退出时（离开main函数后）释放；new和delete管理的对象是动态生命周期，new时构造，delete时释放。c++内存模型和堆栈内存模型并不只是名称上的不同，主要的区别有：每个独立的变量之间有任意大的不可访问区域，自动生命周期的对象所占内存并不和栈一样保证向下生长，new/delete，new【】/delete【】和malloc/free不得混用。更严重的问题是，堆栈模型只是说对象存储在哪里，并没有说明对象的生命周期（构造和析构的时机）：例如要了解func(string().c_str());是否安全，但用c++内存模型就很容易解释：c++规定，临时变量string()的生命周期限定于func这一行，直到分号前都是有效的，而堆栈模型根本没有说明这样的情况，string究竟存在堆上还是栈上，你想了半天，想到了string有“小字符串优化”，小于15字节时会存在栈上，但这对于回答“临时变量什么时候失效”毫无帮助，只是增加你的心智负担，最终还是要回归正规c++内存模型来学习。有人说如果报错“栈溢出”不还是说明还是要学堆栈吗？函数调用栈当然是所有支持函数语言都有的特性，这里的栈要了解，并不能等同于那个连函数调用约定都一清二楚的底层堆栈模型，那就过头了，解决“栈溢出”并不需要了解x86函数调用约定，正如你在python中遇到“栈溢出”不需要查看python虚拟机里的字节码一样，不要偷换概念。类似的概念有“因为linux系统会报segfault所以必须学段内存管理”，然而现代操作系统早已废弃了段式内存管理，而是采用分页内存管理，SIGSEGV实际上应该叫page fault，segfault只是个已经约定俗成没法改的别名而已，正如所谓的“堆内存”早已不是“堆”数据结构一样。
“底层八股文”对C++编程的“积极指导作用”：比如，我知道GCC编译器的实现中，函数调用通常都是x86的call指令实现的，call指令会压栈返回地址，由被调用函数的ret指令取出。所以，我可以通过对第一参数的指针-1，构造一个指针修改返回地址，这样就可以读取或修改返回地址了！比如，我知道Python中GIL阻止了多线程并行，所以我通过ctypes.memmove强行修改了Python解释器内存中的GIL对象，这样不就可以自由的多线程并行了！我真是个天才，然而，我开启-O1优化后，发现GCC编译器把这个函数内联了，没有call指令了，我读到的返回地址有误，并不能形成完整的ebp链表，我认为这肯定是GCC编译器的Bug，我们老师明明说过函数调用约定会压栈的！我通过魔改GIL开始在Python中自由并行后，发现结果混乱，最终Python解释器在一声SIGSEGV中崩溃了，我给Python官方提交了Bug反馈，谁让他们不支持无锁并发数据结构的！另外，通过一个变量魔改另一个变量这个事有原型的，并不是我编的，请看：https://github.com/parallel101/opengltutor/issues/29 小彭老师的教学过程中，不论是群里还是b栈上，依然能遇到大量的“底层八股文”受害者，小彭老师看不得受害者，可你一和他“耐心讲解”，律师帽子就扣上来了。


哗众取宠。用于内存分配的堆栈这两个词在某个特定语言的标准里没有提到，不妨碍这两个概念在许多语言的规范或实现里都存在，说白了就是一个大家都明白的、有助于理解底层原理的抽象，本来就不和某个具体语言绑定。Up 在视频里列出的 strict aliasing 相关的 bug，规范角度说是因为标准里对怎么访问一个对象有明确规定，不符合规定的属于 UB；实现角度上说是因为编译器没有像程序员想当然的那样将变量连续分配，或者做了进一步的优化，跟堆栈这些概念有什么关系？告诉你有个栈，变量在上面就一定是紧密排列？更何况C++23 的 STL 里面还有 <stacktrace> ，如何能说“C++没有堆栈”？
看 up 的评论，貌似还想树个靶子说堆栈这个概念会跟同名数据结构混淆？那首先栈它在逻辑上通常就是一个数据结构意义上的栈，至于 heap 的词源已经很难考证了，未尝跟 binary heap 没有关系，但至多也只是名字起得不好罢了，既学过 binary heap 又学过内存的 heap 的人不至于自己查资料澄清的能力都没有吧。