duangsuse::Echo
How can something be so nice? 为何这能如此之好？ Yet so shocking, yet so nice. 既令人吃惊，又让人叫好 How can something be so new? 为何这能如此之新？ Yet so known but yet so new? 虽很常见，仍耳目一新 Ohh, one two, three, the time has gone. 哦一、二、三，时光飞逝 Problematic things undone. 问题仍然没解决 How can…
尝试翻译了一下，可能会有很多错误。how can something be so nice
这是很强的东西
yet so shocking yet so nice
又强又令人震惊
how can some thing be so new
这是很新的东西
yet so known but yet so new
又新又声名远扬
Oh one two three the time has gone
时间在悄然流逝
problematic things are done
问题已烟消云散
how can something be so groove
振奋人心的歌声
yet so warm but yet so groove
又欢快却又如此的温暖
try to find from the different side
尝试去寻找新的方向
get the choose where to look back
回望过去的抉择
resolve what others can't do for now
就现在，做到别人做不到的事
what the beautiful way to fix all wrong things
什么好方法可以修好全部的错误
evolve future generations of work teams
这是走向新时代的工作团队
but tell me why's that fear of yours
然而告诉我，你在害怕什么。
cause you know it is going to work
因为你知道，它将开始工作。
let's start from now stay tuned you're halfway through
现在，让我们开始期待，你已经成功一半了。
break it crash it take if farther
撞击它，毁灭它，让我们走的更远
making something even smarter
让它变得更聪明
do it start it make it happen
开始吧，努力吧，让他出现
stab in statements screaming louder
打破现实，大声喊：#bilibili https://b23.tv/BV1y4411P74E/p1
这是此视频下歌词的一个翻译。
还有我的评论：
回复 @LinR隐卫-v1Tuner :我从导出的 mid 里的音标序列还原的歌词，一开始想的不是 groovy, cool 而没怀疑直接是 cruel 。
想想作者创造一个新东西的时候，其实这个过程并不好受。 有发现的惊喜也有费解和绝望，这些都是一个创造者所会经历的事情，并非旁人看起来那么光辉或者轻松，我们所信仰的东西真的对自己又温暖又残酷。[撇嘴]
https://synthv.fandom.com/wiki/Sub:Eleanor_Forte/Demos/Something_New
Bilibili
【SynthV Editor Demo】Something New (Synthesizer V 范例项目)_哔哩哔哩 (゜-゜)つロ 干杯~-bilibili
https://synthesizerv.com/zh-cn/歌声合成器 Synthesizer V Editor 首代内置 Demo，由 Aku P作词作曲，使用 Eleanor Forte 英文声库演唱。(SynthV 广告曲emmmmm)第一代 Synthesizer V Editor 软件介绍：av38885840 / cv5533192下一代 Synthesizer V Studio
duangsuse::Echo
尝试翻译了一下，可能会有很多错误。how can something be so nice 这是很强的东西 yet so shocking yet so nice 又强又令人震惊 how can some thing be so new 这是很新的东西 yet so known but yet so new 又新又声名远扬 Oh one two three the time has gone 时间在悄然流逝 problematic things are done 问题已烟消云散 how can something…
这个曲子很平常， SynthV 的作者也没对它有进一步的解释，不过我真的感同身受。
我了解部分作者的经历，但我和他们真的不是一路人，但作为同样的探索者，我第一次就很喜欢这个歌词。
其中， #statement
Ohh, one two, three, the time has gone.
哦一、二、三，时光飞逝
Prob-le-ma-tic things un-done.
问题仍然没解决
How can some-thing be so cruel?
为何这如此残酷
Yet so warm but yet so cruel?
虽存温度，仍很残酷
SynthV 的作者 Kanru Hua 可以说是天才，小学就会拼各种电子器件了，而且开始编程以来 graphviz, latex, 统计学/模糊编程/数据编码 等对数学要求严格的子科都没有问题；我当然和他没有可比性。
但是，SynthV 对他也就相当于 ParserKt 对我，虽然它不能代表作者的技术巅峰，作者也确实是对它倾注了自己所能达到的顶峰。（别喷PKT目前没包装，我只是举个例子，而且以后你们会看到的）
用户在看应用的时候，往往是看到它比同类多什么特性，可其创造者在看的时候除了享受它好的方面，也会深刻地记住在还没有它的以前自己是怎么做的，为什么它会这样出现，以及为了它自己又付出了什么。
我们为成品倾注了那么多，在实现它的价值的同时也实现了自身的价值，但一个真正对自己的事用心的创造者是不会忘记自己付出了什么的，这些终究是难忘或感慨的历史。
与其说新事物是引领潮流，不如说它们在创造历史——每个新东西总是能改变些什么，而它们也并不是凭空产生的，其中有机缘巧合亦有数十载的不懈努力、有天才的灵感乍现亦有常人的勤能补拙，最终造就了它们，让过去成为历史，因为领域总有历史、总有因果先后，事物都有源头、都有最初的直觉，世界上本无没有『道理』的事情；能不能看到这些，我想是创造者和重复者最大的不同。
我明白那种焦躁头疼、无所适从的感觉，所以说我想到的是 "cruel" 而不是 cool 或 groove ；因为设计本来就是有时辛苦有时甜，但我们不会因为苦就不再做，像是自虐一样，有些人一碰上就无法自拔。
并不是因为他们能吃苦，或许只是因为他们更能感受到甜罢了。
1,2,3 时光飞逝，说的可能是 1s, 1h 这种时间，但对于比较复杂或系统性的问题，这 "1" 可能就是一天、一周，甚至一个月，时光飞逝，甚至在烦躁中三四十分钟就过去了，毫无进展，你们想象不到那样的感觉——单在应用层做一些完全能靠查资料、用复用库/框架、甚至复制粘贴的东西，是不常遭受这种痛苦的，因为你们总是有同行者和已曾完成的人。
从大体上看大家都在创造，在组织自己的逻辑；可有些人解决一个问题、有些人为更多解法服务，好比计算机编程应用与计算机科学。
而在架构的前沿孤独的前行者啊，或许荆棘会划破你的衣服，或许你会怀疑自己前行的目的和意义；你或许想放弃（甚至真的做了），但终有一天会重新拾掇、再次出发。
毕竟， 5 次技术架构的迭代才能构筑出一个好引擎， RUCE, -DNN, LLSM ，我们看到了三次，但这背后作者所付出的是无法想象的时间和精力。
只是正巧他关注了、他从新的角度发现了，当然也没有忘记回首自己来的地方。所以，他能找到这个绝妙的方法，去改进自己想改的“惯例”。
在旁人看来 "groove", "cool" 的东西，感觉正是因为始终记得它们和自己以前难看的样子，才会分外不一样吧。
对作者而言，追寻答案的过程其实和答案本身一样激动人心，并不是非得 "done", "groove", "easy", "warm" 才会觉得有意思，所谓花未全开月未全圆，满了、结束了，就无可修饰、不能锦上添花了，不叫完美，反而应该说是“盖棺定论”了，死了。
---
ParserKt 在封装上是很菜的，很大一部分是我的前端技能和项目构建管理能力不行，但它也是前前后后经历了 10 次、5 门语言的重写才有了现在的模样——还并不是最终完成，可以想象在这些看起来简单的模式、用法后我想了多少，对技术的用心是无法单纯用算法复杂或简单来评判的。
我了解部分作者的经历，但我和他们真的不是一路人，但作为同样的探索者，我第一次就很喜欢这个歌词。
How can some-thing be so nice?
为何这能如此好？
Yet so sho-cking, yet so nice.
既很强大又很好
How can some-thing be so new?
为何这能如此新？
Yet so known but yet so new?
很常见却[耳目]一新
Ohh, one two, three, the time has gone.
哦一、二、三，时光飞逝
Prob-le-ma-tic things un-done.
问题仍然没解决
How can some-thing be so cruel?
为何这如此残酷
Yet so warm but yet so cruel?
虽存温度，[仍很]残酷
Try to find from a different sight,
试着从[不同][角度]寻找
Get to choose where to look back,
选个地方回头看
Resolve what others can't do for now...
去解决，他人所不能及
What a beautiful way to fix all wrong things.
真是解决一切问题的妙法
Evolve future generations of work teams.
带来新一代工作组的进化
But tell me why's that fear of yours,
但告诉我[你在]怕什么？
'Cause you know it is going to work... (keep it up)
你明-白它-会起作用（继续做）
Let's start from now, stay tuned, you're half way through!
立刻开始，期盼，只剩一半！
Break it, crash it, take it farther
突破常规，更进一步
Making something even smarter.
做点更智能的事物
Do it, start it, make it happen,
开始做吧，让它存在
Stab in statements screaming louder.
在概念之中大声叫喊
How can something be so nice?
为何这能如此好？
Yet so shocking, yet so nice.
既很强大又很好
How can something be so new?
为何这能如此新？
Yet so known but yet...
虽很常见，但…
IT'S SOMETHING NEW
它是新的 其中， #statement
Ohh, one two, three, the time has gone.
哦一、二、三，时光飞逝
Prob-le-ma-tic things un-done.
问题仍然没解决
How can some-thing be so cruel?
为何这如此残酷
Yet so warm but yet so cruel?
虽存温度，仍很残酷
SynthV 的作者 Kanru Hua 可以说是天才，小学就会拼各种电子器件了，而且开始编程以来 graphviz, latex, 统计学/模糊编程/数据编码 等对数学要求严格的子科都没有问题；我当然和他没有可比性。
但是，SynthV 对他也就相当于 ParserKt 对我，虽然它不能代表作者的技术巅峰，作者也确实是对它倾注了自己所能达到的顶峰。（别喷PKT目前没包装，我只是举个例子，而且以后你们会看到的）
用户在看应用的时候，往往是看到它比同类多什么特性，可其创造者在看的时候除了享受它好的方面，也会深刻地记住在还没有它的以前自己是怎么做的，为什么它会这样出现，以及为了它自己又付出了什么。
我们为成品倾注了那么多，在实现它的价值的同时也实现了自身的价值，但一个真正对自己的事用心的创造者是不会忘记自己付出了什么的，这些终究是难忘或感慨的历史。
与其说新事物是引领潮流，不如说它们在创造历史——每个新东西总是能改变些什么，而它们也并不是凭空产生的，其中有机缘巧合亦有数十载的不懈努力、有天才的灵感乍现亦有常人的勤能补拙，最终造就了它们，让过去成为历史，因为领域总有历史、总有因果先后，事物都有源头、都有最初的直觉，世界上本无没有『道理』的事情；能不能看到这些，我想是创造者和重复者最大的不同。
我明白那种焦躁头疼、无所适从的感觉，所以说我想到的是 "cruel" 而不是 cool 或 groove ；因为设计本来就是有时辛苦有时甜，但我们不会因为苦就不再做，像是自虐一样，有些人一碰上就无法自拔。
并不是因为他们能吃苦，或许只是因为他们更能感受到甜罢了。
1,2,3 时光飞逝，说的可能是 1s, 1h 这种时间，但对于比较复杂或系统性的问题，这 "1" 可能就是一天、一周，甚至一个月，时光飞逝，甚至在烦躁中三四十分钟就过去了，毫无进展，你们想象不到那样的感觉——单在应用层做一些完全能靠查资料、用复用库/框架、甚至复制粘贴的东西，是不常遭受这种痛苦的，因为你们总是有同行者和已曾完成的人。
从大体上看大家都在创造，在组织自己的逻辑；可有些人解决一个问题、有些人为更多解法服务，好比计算机编程应用与计算机科学。
而在架构的前沿孤独的前行者啊，或许荆棘会划破你的衣服，或许你会怀疑自己前行的目的和意义；你或许想放弃（甚至真的做了），但终有一天会重新拾掇、再次出发。
毕竟， 5 次技术架构的迭代才能构筑出一个好引擎， RUCE, -DNN, LLSM ，我们看到了三次，但这背后作者所付出的是无法想象的时间和精力。
只是正巧他关注了、他从新的角度发现了，当然也没有忘记回首自己来的地方。所以，他能找到这个绝妙的方法，去改进自己想改的“惯例”。
Break it, crash it, take it farther
突破常规，更进一步
Making something even smarter.
做点更智能的事物
Do it, start it, make it happen,
开始做吧，让它存在
Stab in statements screaming louder.
在概念之中大声叫喊在旁人看来 "groove", "cool" 的东西，感觉正是因为始终记得它们和自己以前难看的样子，才会分外不一样吧。
对作者而言，追寻答案的过程其实和答案本身一样激动人心，并不是非得 "done", "groove", "easy", "warm" 才会觉得有意思，所谓花未全开月未全圆，满了、结束了，就无可修饰、不能锦上添花了，不叫完美，反而应该说是“盖棺定论”了，死了。
---
ParserKt 在封装上是很菜的，很大一部分是我的前端技能和项目构建管理能力不行，但它也是前前后后经历了 10 次、5 门语言的重写才有了现在的模样——还并不是最终完成，可以想象在这些看起来简单的模式、用法后我想了多少，对技术的用心是无法单纯用算法复杂或简单来评判的。
Forwarded from Solidot
AMD 协商收购 FPGA 制造商赛灵思
2020-10-09 19:48
彭博社等媒体报道，AMD 正就收购可编程芯片（FPGA）制造商赛灵思(Xilinx) 进行谈判，交易金额高达 300 亿美元。交易最早可能在下周达成，这将是继英伟达收购 ARM 之后半导体行业最新的一宗大额收购案。收购赛灵思能让 AMD 在数据中心领域挑战英特尔，并开辟新的市场如 5G。赛灵思和 AMD 都拒绝对这一交易置评。AMD 的 Ryzen 处理器挑战了英特尔在 x86 芯片市场的垄断地位，过去几年其市场占有率在不断提高。Steam 的统计显示，PC 玩家中 AMD 芯片的比例提高到了四分之一。
2020-10-09 19:48
彭博社等媒体报道，AMD 正就收购可编程芯片（FPGA）制造商赛灵思(Xilinx) 进行谈判，交易金额高达 300 亿美元。交易最早可能在下周达成，这将是继英伟达收购 ARM 之后半导体行业最新的一宗大额收购案。收购赛灵思能让 AMD 在数据中心领域挑战英特尔，并开辟新的市场如 5G。赛灵思和 AMD 都拒绝对这一交易置评。AMD 的 Ryzen 处理器挑战了英特尔在 x86 芯片市场的垄断地位，过去几年其市场占有率在不断提高。Steam 的统计显示，PC 玩家中 AMD 芯片的比例提高到了四分之一。
Forwarded from Solidot
计算机科学家在旅行商问题上取得突破
2020-10-10 15:23
当 Nathan Klein 开始读博时，他的两位导师提议共同研究理论计算机科学领域的一个著名难题。导师们认为，即使未能解决这个难题，在此过程中 Klein 将会学到很多东西。Klein 接受了，初生牛犊不怕虎，作为一年级的博士生，他并不知道会遇到多大的困难。Klein 和他在华盛顿大学的导师 Anna Karlin 和 Shayan Oveis Gharan 刚刚发表了一篇论文，报告了他们在困扰了计算机科学家近半个世纪的旅行商问题上取得的突破，找到了一种更好的方法去寻找近似解。
2020-10-10 15:23
当 Nathan Klein 开始读博时，他的两位导师提议共同研究理论计算机科学领域的一个著名难题。导师们认为，即使未能解决这个难题，在此过程中 Klein 将会学到很多东西。Klein 接受了，初生牛犊不怕虎，作为一年级的博士生，他并不知道会遇到多大的困难。Klein 和他在华盛顿大学的导师 Anna Karlin 和 Shayan Oveis Gharan 刚刚发表了一篇论文，报告了他们在困扰了计算机科学家近半个世纪的旅行商问题上取得的突破，找到了一种更好的方法去寻找近似解。
Forwarded from AlPlank (498633413)
Telegram
Sion's Channel
[Methods to prevent leaking website's origin server IP behind CDN]
As a beginner of the webmaster, you may know using CDN nodes to avoid leaking the original server's IP. Meanwhile, you would take some common measures, such as changing the domain hostname…
As a beginner of the webmaster, you may know using CDN nodes to avoid leaking the original server's IP. Meanwhile, you would take some common measures, such as changing the domain hostname…
Forwarded from Phonograph (Ralph 萌新喵)
Phonograph
在C语言里，你选择
#c #PLT 一般情况能用 condition 表达式还是不用常量 while+break/continue. （哪怕提前声名量或是用 do while ）
说要用的情况就是 main loop ，C 里没闭包就只能用函数指针，或者宏，不优雅不高效，只能选择 while(true) 。 当然是否
for(;;) 不喜欢，因为它本应是 for(init;cond;update) ，而 cond 在理论上省略默认 1 是不优雅的（这是语言设计上的不对）
原则上我是讨厌 1 替代 true 的，尽管对许多机器而言非0即真（不过说起来，所谓真假也就是控制流跳转与否而已）。
说要用的情况就是 main loop ，C 里没闭包就只能用函数指针，或者宏，不优雅不高效，只能选择 while(true) 。 当然是否
#define forever 也是看复用处有多少的。for(;;) 不喜欢，因为它本应是 for(init;cond;update) ，而 cond 在理论上省略默认 1 是不优雅的（这是语言设计上的不对）
原则上我是讨厌 1 替代 true 的，尽管对许多机器而言非0即真（不过说起来，所谓真假也就是控制流跳转与否而已）。
Forwarded from YSC 的频道
测试 HTTP Client 的 TLS 及 http/2 支持情况的几个网站:
https://www.howsmyssl.com/s/api.html (仅支持 TLS，能给出详细的信息)
https://cloudflare.com/cdn-cgi/trace (支持 TLS 和 http/2，只能给出支持的 TLS 版本，还有 IP 地址和 User-Agent)
https://http2.golang.org/ (仅支持 http/2)
https://www.howsmyssl.com/s/api.html (仅支持 TLS，能给出详细的信息)
https://cloudflare.com/cdn-cgi/trace (支持 TLS 和 http/2，只能给出支持的 TLS 版本，还有 IP 地址和 User-Agent)
https://http2.golang.org/ (仅支持 http/2)
#cs #PLT Expression Problem(Visitor Pattern, interpreter) 这个问题我也讲过 #zhihu https://zhuanlan.zhihu.com/p/163762783 ，你们可以比较一下。
知乎专栏
梗概Visitor Pattern
阅读这篇文章你应该理解小学数学，文中会用Java、Kotlin和Haskell三种编程语言，Haskell是附赠品不必理解。 一般来说函数式程序员对这个问题总结得也挺好，不过相信写的人本就少，写完后删了的人也挺多，这篇文章…
Forwarded from Solidot
旧代码和年长程序员难题
2020-10-13 15:29
今年初的新冠疫情带来的一个出人意料的结果是许多地方亟需 COBOL 程序员去维护历史悠久的旧代码。一个问题是陈旧软件陈旧代码的规模究竟有多大？以“Why Software Fails”一文著称的 Bob Charette 称，我们并不清楚这一问题的规模究竟有多大，我们所知道的是每年投入了数万亿美元去维护和运营这些系统，投入数千亿美元去进行现代化，而很多现代化项目都失败了。美国社会保障总署最近发布的报告承认他们也不清楚社会保障系统有多少是遗留的陈旧系统。建一条公路的费用可能远不及在这条公路的寿命期内的维护费用。在系统开发每投入 1 美元，那么在系统寿命期限内需要投入 8 到 10 美元去进行维护。一个软件系统的生命可能比设计者预想的要长得多。IT 预算的很大一部分是用于运营和维护而不是开发替代或进行现代化，这一比例越高，一个系统越不可能进行升级。
2020-10-13 15:29
今年初的新冠疫情带来的一个出人意料的结果是许多地方亟需 COBOL 程序员去维护历史悠久的旧代码。一个问题是陈旧软件陈旧代码的规模究竟有多大？以“Why Software Fails”一文著称的 Bob Charette 称，我们并不清楚这一问题的规模究竟有多大，我们所知道的是每年投入了数万亿美元去维护和运营这些系统，投入数千亿美元去进行现代化，而很多现代化项目都失败了。美国社会保障总署最近发布的报告承认他们也不清楚社会保障系统有多少是遗留的陈旧系统。建一条公路的费用可能远不及在这条公路的寿命期内的维护费用。在系统开发每投入 1 美元，那么在系统寿命期限内需要投入 8 到 10 美元去进行维护。一个软件系统的生命可能比设计者预想的要长得多。IT 预算的很大一部分是用于运营和维护而不是开发替代或进行现代化，这一比例越高，一个系统越不可能进行升级。
Solidot
旧代码和年长程序员难题 2020-10-13 15:29 今年初的新冠疫情带来的一个出人意料的结果是许多地方亟需 COBOL 程序员去维护历史悠久的旧代码。一个问题是陈旧软件陈旧代码的规模究竟有多大？以“Why Software Fails”一文著称的 Bob Charette 称，我们并不清楚这一问题的规模究竟有多大，我们所知道的是每年投入了数万亿美元去维护和运营这些系统，投入数千亿美元去进行现代化，而很多现代化项目都失败了。美国社会保障总署最近发布的报告承认他们也不清楚社会保障系统有多少是遗留的…
所以说，问题发现得越早，它所造成的麻烦就越小。看看这个语言、现在语言工具创作者的态度，带来了多少麻烦。 #PLT #cs #statement
还有，程序员要明白自己是怎么工作的，懂得如何减小机械化的工作，编译原理/元编程/代码生成 是最好的选择
定义式的程序设计完全不存在这种弱智问题，它本身是语言无关、平台无关的，纯编译期的东西，就像响应式的 Web 一样，何必操心程序在哪用呢。
如果你想设计迁移翻译器，也就比实现两个 parser + 1 decompiler 要容易一点点，真是何苦呢？写死了用不活，带来额外的麻烦。
基础程序结构、数据结构就那么多，若判对重复、组行表集合，编程最根本的区别在于范式和底层访问性，才不是什么语法什么封装，而主流的范式就是过程式，有些人明白怎么编程，却不重视怎么平衡费益、解决问题。
解决一个问题，不在未来给别人带来更多问题，这才是程序设计的道理，即便这样何尝容易实现过呢。
还有，程序员要明白自己是怎么工作的，懂得如何减小机械化的工作，编译原理/元编程/代码生成 是最好的选择
定义式的程序设计完全不存在这种弱智问题，它本身是语言无关、平台无关的，纯编译期的东西，就像响应式的 Web 一样，何必操心程序在哪用呢。
如果你想设计迁移翻译器，也就比实现两个 parser + 1 decompiler 要容易一点点，真是何苦呢？写死了用不活，带来额外的麻烦。
基础程序结构、数据结构就那么多，若判对重复、组行表集合，编程最根本的区别在于范式和底层访问性，才不是什么语法什么封装，而主流的范式就是过程式，有些人明白怎么编程，却不重视怎么平衡费益、解决问题。
解决一个问题，不在未来给别人带来更多问题，这才是程序设计的道理，即便这样何尝容易实现过呢。
#PLT 绝句 最近的变更：
决定移除『扩物』，从此简记法是「储例况标内抽象」
原因有二：
从编程惯用来看，会连续创建多个 receiver 类型不同的 ext fun/val ，扩物的写法有悖常理
从语言一致性来看， Kotlin 的 receiver/param1 互化带来的 fun(type) with receiver 与「扩物」不对仗（关于知识网的联系就换成所有 fun/val 都隐式于『我类型』好了）
而且即便标物和抽象物也都是『物』，可扩物实际上只是种蹩脚的编译元数据定义
决定将 抽象/开放/终定 变为 待定/再定/终定 ，『抽象性/覆写性』为『确定性』
对应 abstract/open/final
TODO() 则是 待写()
从兼容性上， open 也可视为可见性修饰符，语义匮乏，没必要移植到中文
现在，只有 储例况标内
expect/actual 仍 待例/实际
可见性： 公开 族内 私下 内部
覆写性： 开放 终定 抽象 实现
特殊：隐式 记法
内联 不联
待例 实际
晚成 尾递归 断续
决定移除『扩物』，从此简记法是「储例况标内抽象」
原因有二：
从编程惯用来看，会连续创建多个 receiver 类型不同的 ext fun/val ，扩物的写法有悖常理
从语言一致性来看， Kotlin 的 receiver/param1 互化带来的 fun(type) with receiver 与「扩物」不对仗（关于知识网的联系就换成所有 fun/val 都隐式于『我类型』好了）
而且即便标物和抽象物也都是『物』，可扩物实际上只是种蹩脚的编译元数据定义
决定将 抽象/开放/终定 变为 待定/再定/终定 ，『抽象性/覆写性』为『确定性』
对应 abstract/open/final
TODO() 则是 待写()
从兼容性上， open 也可视为可见性修饰符，语义匮乏，没必要移植到中文
现在，只有 储例况标内
expect/actual 仍 待例/实际
可见性： 公开 族内 私下 内部
覆写性： 开放 终定 抽象 实现
特殊：隐式 记法
内联 不联
待例 实际
晚成 尾递归 断续
duangsuse::Echo
#PLT 绝句 最近的变更： 决定移除『扩物』，从此简记法是「储例况标内抽象」 原因有二： 从编程惯用来看，会连续创建多个 receiver 类型不同的 ext fun/val ，扩物的写法有悖常理 从语言一致性来看， Kotlin 的 receiver/param1 互化带来的 fun(type) with receiver 与「扩物」不对仗（关于知识网的联系就换成所有 fun/val 都隐式于『我类型』好了） 而且即便标物和抽象物也都是『物』，可扩物实际上只是种蹩脚的编译元数据定义 决定将 抽象/开放/终定…
绝句的面向对象架构现在已经和 Java 面向对象，乃至 Kotlin 的正统 OOP 都有点差异了
visibility/可见性:
公开 族内 私下 内部
public protected private internal
rewritability/确定性:
待定 再定 终定 实现
abstract open final override
construct/构件:
包 类型别名 常量 类 物 例 造于 事 量/变
package typealias const-val interface class object constructor fun val/var
package typealias const class thing insta constructor fun val/var
affairs/杂件:
取者 置者 代者 恒事 性质推导
get set by
class kinds/类定义的种类:
储 例 况 标 内 待定
data enum sealed annotation inner abstract
multitarget/多平台:
待例 实际
expect actual
others/其它:
晚成 尾递归 断续 隐式 记法
lateinit tailrec suspend implicit notation
内联 不联
inline noinline
access/访问:
(o的n) (o去v) (o[k]) (k存于o)
(o.n) o.v() o[k] (k in o)
type RHS/类型:
属于 作成 试作
is as as?
visibility/可见性:
公开 族内 私下 内部
public protected private internal
rewritability/确定性:
待定 再定 终定 实现
abstract open final override
construct/构件:
包 类型别名 常量 类 物 例 造于 事 量/变
package typealias const-val interface class object constructor fun val/var
package typealias const class thing insta constructor fun val/var
affairs/杂件:
取者 置者 代者 恒事 性质推导
get set by
class kinds/类定义的种类:
储 例 况 标 内 待定
data enum sealed annotation inner abstract
multitarget/多平台:
待例 实际
expect actual
others/其它:
晚成 尾递归 断续 隐式 记法
lateinit tailrec suspend implicit notation
内联 不联
inline noinline
access/访问:
(o的n) (o去v) (o[k]) (k存于o)
(o.n) o.v() o[k] (k in o)
type RHS/类型:
属于 作成 试作
is as as?
duangsuse::Echo
绝句的面向对象架构现在已经和 Java 面向对象，乃至 Kotlin 的正统 OOP 都有点差异了 visibility/可见性: 公开 族内 私下 内部 public protected private internal rewritability/确定性: 待定 再定 终定 实现 abstract open final override construct/构件: 包 类型别名 常量 类 物 例 造于 事 量/变 package typealias const-val interface class…
所以大家可以看到，表达用的语言，对编程语言的模样是有影响的。 试问按英文设计能弄出 待定/再定/终定 的区别吗？恐怕很鸡肋，甚至不如 abstract/open/final
顺便，命名风格和参数顺序对结果可读性也会有影响，它们也会间接影响到 API 的设计。
顺便，命名风格和参数顺序对结果可读性也会有影响，它们也会间接影响到 API 的设计。
duangsuse::Echo
绝句的面向对象架构现在已经和 Java 面向对象，乃至 Kotlin 的正统 OOP 都有点差异了 visibility/可见性: 公开 族内 私下 内部 public protected private internal rewritability/确定性: 待定 再定 终定 实现 abstract open final override construct/构件: 包 类型别名 常量 类 物 例 造于 事 量/变 package typealias const-val interface class…
#dev #design 在这里谈下自己对 「待定/再定/终定」 新写法的看法吧。
加了这个以后我一直觉得很难受（一部分也是我在考虑无GC的『存储』子类如何实现），因为某种意义上这是在否定过去的设计“特性”——绝句在这方面之前和 Kotlin 不一样，我试着把『抽象性』隔离了出来（作为 抽象物 这个关键字），然后 open 和 final 保持不变（因为 abstract class 几乎是一个惯例，有理由为其分配关键字）
从用法上看， final 只在指定 open class 里不可再定的成员时才使用，频率最少；open 的频率在其次，另外如果要减轻
新名称也是符合绝句设计惯例的——待定/再定/终定 对毫无编程经验的人也容易理解（日常用语），并且一定程度隐含了底层方法解析确定性的语义。
可是现在又改回来了——
抽象物『标物处理器』为
待定的物『标物处理器』为
再定的物『活动』为
为了这三个“X定”的一致性，是不可能再弄『待定物』这样的关键字的，而目前就打回原形、和 Kotlin 一样，真的很不爽啊（最讨厌设计得和别人一样了，但我不得不承认这是最好的做法）。
加了这个以后我一直觉得很难受（一部分也是我在考虑无GC的『存储』子类如何实现），因为某种意义上这是在否定过去的设计“特性”——绝句在这方面之前和 Kotlin 不一样，我试着把『抽象性』隔离了出来（作为 抽象物 这个关键字），然后 open 和 final 保持不变（因为 abstract class 几乎是一个惯例，有理由为其分配关键字）
从用法上看， final 只在指定 open class 里不可再定的成员时才使用，频率最少；open 的频率在其次，另外如果要减轻
interface X { abstract val a:Int } 这种不优雅的有效语法对程序明确性的影响，我觉得不应该沿用老名称。新名称也是符合绝句设计惯例的——待定/再定/终定 对毫无编程经验的人也容易理解（日常用语），并且一定程度隐含了底层方法解析确定性的语义。
可是现在又改回来了——
抽象物『标物处理器』为
待定的物『标物处理器』为
再定的物『活动』为
为了这三个“X定”的一致性，是不可能再弄『待定物』这样的关键字的，而目前就打回原形、和 Kotlin 一样，真的很不爽啊（最讨厌设计得和别人一样了，但我不得不承认这是最好的做法）。