因为好像实在是没时间了，而且貌似已经就要收尾了（虽然我还是很不高兴，因为做的不够多）
所以我不得不放弃了使用 EOT 的做法（就是倾向一个正常程序来用，不然得手动kill它），即便其实 Scanner 架构还真没啥不好的…… 除了第一次peek的情况我无法看明白之外。
所以我不得不放弃了使用 EOT 的做法（就是倾向一个正常程序来用，不然得手动kill它），即便其实 Scanner 架构还真没啥不好的…… 除了第一次peek的情况我无法看明白之外。
Forwarded from duangsuse Throws
#life #Telegram 为了方便大家认识我，我把名字里的一些东西移动到 bio 里
这句话的源头是冰封哥 @ice1000 的『菜是原罪』
后来我发现，我不应该尝试跟在他的后面怎么样，每个人都有自己的风格，何况冰封哥不喜欢菜鸡跟在后面的。
Telegram bio的空间很宝贵，我暂时不想在那里放格言，那就简单放一个自己的领域介绍吧。
现在的 first name （名）是 duangsuse，没有 last name（姓）
Technical unfamiliar is origin sin 这句话的源头是冰封哥 @ice1000 的『菜是原罪』
后来我发现，我不应该尝试跟在他的后面怎么样，每个人都有自己的风格，何况冰封哥不喜欢菜鸡跟在后面的。
Telegram bio的空间很宝贵，我暂时不想在那里放格言，那就简单放一个自己的领域介绍吧。
/'dʊɔːŋ sjuːz/; [PLD, FPλ]; @dsuse@dsuses 日常讨论笔记文档代码 17yo CC-BY 现在的 first name （名）是 duangsuse，没有 last name（姓）
Forwarded from dnaugsuz
所以说在设计语言的时候，有些东西是要好好斟酌的。Python 的 slice 区间切片语法其实没什么，我开始也会对自己 Kotlin 里的 (read-only)Slice 抽象写上
但现在我改了，换成了
operator fun get(indices: IntRange): Slice<T> 但现在我改了，换成了
fun slice...。不是因为我嫌它太短，而是它短出了问题，语义上不够优雅。 就像我开始很奇怪 Kotlin 和 Java 为什么允许 integer literal 能够写上默认的正号一样，因为去掉会使得它看起来、感觉起来很奇怪、不对称。Forwarded from dnaugsuz
《Kotlin极简教程》的陈光剑开始会说『明明很多东西(plus, minus, ...)都是一般约定的 operator 名字，为什么还要再加 modifier "
想想Python3现在的元方法，可以说真是能让人看瞎眼了。Python3真是把『元方法』这个概念发挥到了极致，发挥到了邪恶化的地步。
如果说Lua的 __gc, __newindex 什么的还稍微有点规范可言（都是在相当「精炼」的运算语义扩展上），Python3 的已经是玩过火了，它的元方法是什么都有，而且和Kotlin的
operator" 啊』想想Python3现在的元方法，可以说真是能让人看瞎眼了。Python3真是把『元方法』这个概念发挥到了极致，发挥到了邪恶化的地步。
如果说Lua的 __gc, __newindex 什么的还稍微有点规范可言（都是在相当「精炼」的运算语义扩展上），Python3 的已经是玩过火了，它的元方法是什么都有，而且和Kotlin的
operator fun 重载完全不在一个级别。真不知道Van君如果哪天重写Python3，是否能把元方法的规范默写下来。
dnaugsuz
《Kotlin极简教程》的陈光剑开始会说『明明很多东西(plus, minus, ...)都是一般约定的 operator 名字，为什么还要再加 modifier "operator" 啊』 想想Python3现在的元方法，可以说真是能让人看瞎眼了。Python3真是把『元方法』这个概念发挥到了极致，发挥到了邪恶化的地步。 如果说Lua的 __gc, __newindex 什么的还稍微有点规范可言（都是在相当「精炼」的运算语义扩展上），Python3 的已经是玩过火了，它的元方法是什么都有，而且和Kotlin的…
我这里想比较偏激的说，一切不能被它们的创造者默写、可视化下来的设计，都是冗余或者不规范的设计。 #statement
如果说你经常使用类似的设计但从没觉得不对劲，那是因为你从来没完全重写过你的代码，所以感受不到他们的奇怪。
如果说你经常使用类似的设计但从没觉得不对劲，那是因为你从来没完全重写过你的代码，所以感受不到他们的奇怪。
Forwarded from dnaugsuz
所以Python害得定位差不多的Ruby受到迫害用户量减少，真是劣币驱逐良币。
还好在更规范的JVM平台上这是不可能的，虽然很多开发者依然按照习惯继续使用辣鸡到10才有 local variable inference 的Jawa，Kotlin依然已经（虽然是借助Google之手）在许多开发圈里火了起来，是Kotlin驱逐屑Jawa，至少比Python应用的情况好。
还好在更规范的JVM平台上这是不可能的，虽然很多开发者依然按照习惯继续使用辣鸡到10才有 local variable inference 的Jawa，Kotlin依然已经（虽然是借助Google之手）在许多开发圈里火了起来，是Kotlin驱逐屑Jawa，至少比Python应用的情况好。
dnaugsuz
所以Python害得定位差不多的Ruby受到迫害用户量减少，真是劣币驱逐良币。 还好在更规范的JVM平台上这是不可能的，虽然很多开发者依然按照习惯继续使用辣鸡到10才有 local variable inference 的Jawa，Kotlin依然已经（虽然是借助Google之手）在许多开发圈里火了起来，是Kotlin驱逐屑Jawa，至少比Python应用的情况好。
Java 1.3 是 Plain Old Java，那时候整个语言面向对象结构基本已经确立了。Java很早都有APT(Annotation Processing Tool)了。
1.4 加入了
Java 5 是引入了 Generics, Autoboxing, enum 等，虽然 stdlib 的很多集合类依然是非泛型版本的，反观Kotlin现在全都是泛型版本的（而且还有 in/out 生产消费默写的安全泛型型变），辣鸡Jawa！
Java 6 是
Java 7 加入了 Diamond 语法糖项目、ARM、multi catch，这个改动也引入了 Union type，并集类型，虽然我很奇怪为什么不是 Intersection type，交集类型。难道
Java 8 加入了 lambda 和 Type annotation
Java 9 支持语言内建 Modules、
Java 10 才支持 local variable type inference
Java 11 居然又新增 local variable syntax for lambda parameters (JEP 323)，原因是语言一致性(uniformity)和支持对 lambda parameter 使用 local variable 的 annotation，难道不应该是一个大版本里面的吗？
Java 12 了才有 switch expression，估计是抄Kotlin的，谁叫它更新慢。（当然这也不能全怪 Oracle 和 Java 开发团队，毕竟他们有很多基于 Java 程序设计语言的框架比如 Swing, AWT, JavaEE 基础要维护，还要维护 HotSpot VM，但是从语言上来看，Kotlin绝对完爆Jawa。Kotlin是专心做语言）
#Java #PL
1.4 加入了
assert，当然Kotlin里就是 assert 函数，当然Java里可没这么方便（Kotlin语言内部函数），真是的。Java 5 是引入了 Generics, Autoboxing, enum 等，虽然 stdlib 的很多集合类依然是非泛型版本的，反观Kotlin现在全都是泛型版本的（而且还有 in/out 生产消费默写的安全泛型型变），辣鸡Jawa！
Java 6 是
@Override 注解支持在 interface 里用Java 7 加入了 Diamond 语法糖项目、ARM、multi catch，这个改动也引入了 Union type，并集类型，虽然我很奇怪为什么不是 Intersection type，交集类型。难道
catch(A|B x) { x.methodOnA(); x.methodOnB(); } 能够编译？Java 8 加入了 lambda 和 Type annotation
Java 9 支持语言内建 Modules、
private methods in interface Java 10 才支持 local variable type inference
Java 11 居然又新增 local variable syntax for lambda parameters (JEP 323)，原因是语言一致性(uniformity)和支持对 lambda parameter 使用 local variable 的 annotation，难道不应该是一个大版本里面的吗？
Java 12 了才有 switch expression，估计是抄Kotlin的，谁叫它更新慢。（当然这也不能全怪 Oracle 和 Java 开发团队，毕竟他们有很多基于 Java 程序设计语言的框架比如 Swing, AWT, JavaEE 基础要维护，还要维护 HotSpot VM，但是从语言上来看，Kotlin绝对完爆Jawa。Kotlin是专心做语言）
#Java #PL
#Qzone #Java #Server
https://user.qzone.qq.com/3323659619/mood/63051bc6f8f3055e05da0300.1
iseki:
Spring …它真的不香… Vert.x 香（x
duangsuse:
同意，Sp 有点冗了，虽然我也没拿它写过什么（但是就框架上感觉过大）
Vertx 对异步任务和 events 抽象还不赖，我记得它的 CompositeFuture.all，记得它的 core, ext, web 子模块和 Router, HttpServer, Router#route 以及 Verticle, MainVerticle 的扩展。
但是 Spring 相比 Vertx 的确是有点令人费解了，甚至还默认上什么『诊断』组件，代码质量下去了，什么自动化其实都是废的。
Kotlin 的 Ktor 不知道 iseki 君有木有玩过，估计也不赖，何况还有 Kotlin HTML Builder DSL 加持，我估计都这样了也写不出烂项目来，不愧是 Kotlin 呢。Write once in one language, run anywhere on all platform.
iseki:
其实我觉得Vert.x搭配上Kotlin的coroutine就非常的舒服了，前提是别不小心把context搞乱就好…
https://user.qzone.qq.com/3323659619/mood/63051bc6f8f3055e05da0300.1
iseki:
Spring …它真的不香… Vert.x 香（x
duangsuse:
同意，Sp 有点冗了，虽然我也没拿它写过什么（但是就框架上感觉过大）
Vertx 对异步任务和 events 抽象还不赖，我记得它的 CompositeFuture.all，记得它的 core, ext, web 子模块和 Router, HttpServer, Router#route 以及 Verticle, MainVerticle 的扩展。
但是 Spring 相比 Vertx 的确是有点令人费解了，甚至还默认上什么『诊断』组件，代码质量下去了，什么自动化其实都是废的。
Kotlin 的 Ktor 不知道 iseki 君有木有玩过，估计也不赖，何况还有 Kotlin HTML Builder DSL 加持，我估计都这样了也写不出烂项目来，不愧是 Kotlin 呢。Write once in one language, run anywhere on all platform.
iseki:
其实我觉得Vert.x搭配上Kotlin的coroutine就非常的舒服了，前提是别不小心把context搞乱就好…
#Kotlin Write once in one language, run anywhere on all platform.
编程就应该是这样，语言表达无关、平台无关，什么『专有』…… 都弱暴了！ M$ 之前那么宠 C# 和 .NET，最后还是只能给它官方开源跨平台了呵，不是想弄成Windows专有的技术么。
编程就应该是这样，语言表达无关、平台无关，什么『专有』…… 都弱暴了！ M$ 之前那么宠 C# 和 .NET，最后还是只能给它官方开源跨平台了呵，不是想弄成Windows专有的技术么。
#dev #PL #statement 今天好不容易天晴了，那就随便谈谈程序设计上的一些知识吧。
说的是『表述式(imperative)编程』和『定义式(declarative)编程』，它们是编程范式(programming paradigm)中区别最明显的两种。
偶尔，表述式也被称为『命令式』，定义式也被称为『声明式』。
如果让表述式的程序员写一段『把大象塞进冰箱』的代码，其中利用外部抽象『打开、塞进、关上』，他们会这么写：
如果让定义式的程序员写呢？
比如，《亲爱的大象》 会如何？
如果我们的
（这里假设我们使用的是有自动内存管理，而无须指针弱引用啥子的语言）
那么具体修改完的代码我就不贴了，因为实在有点长，但是我们肯定能预见到，表述式的程序员直接复制粘贴以上代码，而定义式的程序员又会定义出新的子程序(subroutine, sub-procedure)
其实一句话可以总结这两种编程风格（我本周的文章也会说到）
*『表述式越写越复杂，定义式越写越简单。』*
这里我们能够看出他们最大的区别，就是表述式的程序员喜欢「直白地」表达程序，而定义式的程序员喜欢抽提（抽象、提取）重复的程序逻辑，所以哪怕是我们要求再加音乐播放的功能、再要求塞大象进冰箱的子程序可能失败，都不会使得代码冗杂难看，不会进入所谓的『嵌套地狱』。
同样地，他们会努力地提升代码的可读性，也只有用定义式的思路编程，你才能设计出解决回调(callback)嵌套地狱的Promise异步任务抽象，而表述式的程序员则只会抱怨它难看，而不知道或者懒得去想到，其实有改进方法的。
你是表述式的程序员还是定义式的程序员呢？相信许多人会觉得表述式和定义式不分高低。（其实我上面说的『表述式』『定义式』也不是准确定义，而是说它们的使用者经常的编程风格，从某种意义上就是它们的『编程风格』）
不过，我个人觉得，不管是C、VisualBasic这样的『表述式编程语言』还是Scheme、Haskell这样的『定义式编程语言』，都不要忘记经常重新检查自己的代码，尽可能自然，而不是「简单」地描述你的程序。
要记得，真正的少写代码是使得它更好看、更少冗余，而不是在起名字上花费心思，最后弄得大家都看不懂，这也是Kotlin实际上的编程风格。
这不是智商低的表现，相反它是清清楚楚地认识到了自己和别人的智商、精力有限，抱持对软件和其他有兴趣查看源代码的人的善意，而对代码的质量格外地珍惜。
虽然『代码』实现只是软件里很小的一部分，在信息技术里也不是最关键的问题，我真心希望大家以后编程的时候，都要注意呦。
其实这里我也可以再顺便扩展地说到面向对象范式的内容的，也可以关于『编程是什么』这个问题说点观点，可是好像属于跑题内容……
浩哥也说过这个话题
说的是『表述式(imperative)编程』和『定义式(declarative)编程』，它们是编程范式(programming paradigm)中区别最明显的两种。
偶尔，表述式也被称为『命令式』，定义式也被称为『声明式』。
如果让表述式的程序员写一段『把大象塞进冰箱』的代码，其中利用外部抽象『打开、塞进、关上』，他们会这么写：
事 入口() 为当然 *程序=数据结构+算法* ，我这里没有提到关于冰箱、大象的数据结构抽象建模方式，不过我也没有（为了简化讲解目的）过分实际到连
打开(冰箱的门)
塞进(冰箱的里面、大象)
关闭(冰箱的门)
打开(物体) 都没提出来，只有 打开冰箱门() 的程度。如果让定义式的程序员写呢？
事 入口() 为想想看，如果我们又要求在塞完大象后，放一首歌
塞进里面(冰箱、大象)
事 塞进里面(容器：物体、此物：物体) 为
打开(容器)；塞进(容器的里面、此物)；关闭(容器)
如果我们的
塞进(物体、物体) 编程接口，可能（基于异常系统或是分情况的数据结构地）失败会怎么样？失败了第一是不能放那首歌，第二是不能异常退出整个程序。（这里假设我们使用的是有自动内存管理，而无须指针弱引用啥子的语言）
量 歌者：播放器 = 播放器()我们讨论的问题比较抽象，但利用编程语言提供的表达式、程序和数据对象定义、基本控制结构组织这样的程序，就是我们的日常工作。
歌者去加载(文件("大象大象.wav"))
歌者的位置 = 0
歌者去歌唱()
那么具体修改完的代码我就不贴了，因为实在有点长，但是我们肯定能预见到，表述式的程序员直接复制粘贴以上代码，而定义式的程序员又会定义出新的子程序(subroutine, sub-procedure)
事 播放音乐文件(路径：文) 。其实一句话可以总结这两种编程风格（我本周的文章也会说到）
*『表述式越写越复杂，定义式越写越简单。』*
这里我们能够看出他们最大的区别，就是表述式的程序员喜欢「直白地」表达程序，而定义式的程序员喜欢抽提（抽象、提取）重复的程序逻辑，所以哪怕是我们要求再加音乐播放的功能、再要求塞大象进冰箱的子程序可能失败，都不会使得代码冗杂难看，不会进入所谓的『嵌套地狱』。
同样地，他们会努力地提升代码的可读性，也只有用定义式的思路编程，你才能设计出解决回调(callback)嵌套地狱的Promise异步任务抽象，而表述式的程序员则只会抱怨它难看，而不知道或者懒得去想到，其实有改进方法的。
你是表述式的程序员还是定义式的程序员呢？相信许多人会觉得表述式和定义式不分高低。（其实我上面说的『表述式』『定义式』也不是准确定义，而是说它们的使用者经常的编程风格，从某种意义上就是它们的『编程风格』）
不过，我个人觉得，不管是C、VisualBasic这样的『表述式编程语言』还是Scheme、Haskell这样的『定义式编程语言』，都不要忘记经常重新检查自己的代码，尽可能自然，而不是「简单」地描述你的程序。
要记得，真正的少写代码是使得它更好看、更少冗余，而不是在起名字上花费心思，最后弄得大家都看不懂，这也是Kotlin实际上的编程风格。
这不是智商低的表现，相反它是清清楚楚地认识到了自己和别人的智商、精力有限，抱持对软件和其他有兴趣查看源代码的人的善意，而对代码的质量格外地珍惜。
虽然『代码』实现只是软件里很小的一部分，在信息技术里也不是最关键的问题，我真心希望大家以后编程的时候，都要注意呦。
其实这里我也可以再顺便扩展地说到面向对象范式的内容的，也可以关于『编程是什么』这个问题说点观点，可是好像属于跑题内容……
浩哥也说过这个话题
酷 壳 - CoolShell
函数式编程 | 酷 壳 - CoolShell
函数式编程是个很有意思的东西，这篇文章总结了一些函数式编程的优点，并用一些代码用非函数式的和函数式的代码向大家介绍了什么是函数式编程。希望这篇文章对大家能系统地了解什么是函数式编程有用。当然，函数式编程也不是万能药，只是一种编程范式。
#project Binarie 的（字节序上）『莫名其妙的问题』已经被确认为泛抽象数据结构（机器数的 shl shr and）编程失误，顺序没搞明白，pop_right 了 byte 导致
E2im-2 基于标准输入输出流协议的一个细节（准确的说，是我『面向调试编程』导致的…… 很羞愧），多输出了换行符的问题将在明天修正。
integralToBytes 的输出顺序是反的 0123 -> 3210。E2im-2 基于标准输入输出流协议的一个细节（准确的说，是我『面向调试编程』导致的…… 很羞愧），多输出了换行符的问题将在明天修正。
Telegram
duangsuse::Echo
比如说这里咱们有四个字符，『恭喜发财』~
import org.duangsuse.dokuss.struct.*
class 恭喜发财: ArrayLike(4) {
val a: Char by index(0)
val b: Char by index(1)
val c: Char by index(2)
val d: Char by index(3)
}
咱来读取一下这个结构试试。
val 恭喜发财Doku = Seq(::恭喜发财, char16, char16, char16…
import org.duangsuse.dokuss.struct.*
class 恭喜发财: ArrayLike(4) {
val a: Char by index(0)
val b: Char by index(1)
val c: Char by index(2)
val d: Char by index(3)
}
咱来读取一下这个结构试试。
val 恭喜发财Doku = Seq(::恭喜发财, char16, char16, char16…
Forwarded from dnaugsuz
lazy 到不会，其实是 lazy 里面所依赖的那些值偶尔还没初始化，我以为可以的。比如：
val a: Int by lazy { b + depA }
val depA get() = a + 1
val b = 0
此时 depA 依赖还没初始化的 a，就是 null 了，我没想到 lazy initializer 里不能递归的……Forwarded from dnaugsuz
Kotlin 的代码质量不是盖的，怎么可能在 Lazy delegate 的实现上出现低级错误。
Forwarded from dnaugsuz
那不是文言啊，那是现代文。每次我去学校的时候偶尔会有机会设计一下，目前也就完善了两次（第二次还没发上网）
最近我有 Kotlin Multiplatform 二进制序列化组合子库 Binarie 和解析组合子库 ParserKt 要写，暂时没时间实现它
因为绝句程序设计语言依赖很多上下文相关的语法（主要是实现『布局』语义特性的，比如逗号表示法、「为」文法，那是必须的。）
所以我绝对不能使用一些比较老式的解析器实现方式，比如ANTLR来实现它。
也只能慢慢看喽，何时有了 ParserKt，我打算先弄个 prototype(原型) 翻译到Kotlin。至于 1.0 的语言特性我得先实现另外一门「脚本语言」再考虑。
如果你感兴趣可以来看看之前的一些设计笔记，不算太严谨。
最近我有 Kotlin Multiplatform 二进制序列化组合子库 Binarie 和解析组合子库 ParserKt 要写，暂时没时间实现它
因为绝句程序设计语言依赖很多上下文相关的语法（主要是实现『布局』语义特性的，比如逗号表示法、「为」文法，那是必须的。）
所以我绝对不能使用一些比较老式的解析器实现方式，比如ANTLR来实现它。
也只能慢慢看喽，何时有了 ParserKt，我打算先弄个 prototype(原型) 翻译到Kotlin。至于 1.0 的语言特性我得先实现另外一门「脚本语言」再考虑。
如果你感兴趣可以来看看之前的一些设计笔记，不算太严谨。
Telegram
duangsuse::Echo
运算符：
前、后 (dec/inc)
+（加）、-（减）、*（乘）、/（除）、%（取余）
-~（取负）
大(>)、小(<)
不大(<=)、不小(>=) — 这一行括号里的表示法仅参考用
汉语里就不要用小于号、小于等于了。
取负的 -~ 只是注释，绝句不存在前缀记法，只有前缀算符
&（且） |（或） !~（取非）
（异） — 只有真假类型有
绝句的且或非逻辑都是短路计算的，也就是说 假 & 不可能, 真 | 不可能
我相信，既然绝句已经改了这么多了，不会有人觉得让 (&) 官复原职很奇怪
第一眼看…
前、后 (dec/inc)
+（加）、-（减）、*（乘）、/（除）、%（取余）
-~（取负）
大(>)、小(<)
不大(<=)、不小(>=) — 这一行括号里的表示法仅参考用
汉语里就不要用小于号、小于等于了。
取负的 -~ 只是注释，绝句不存在前缀记法，只有前缀算符
&（且） |（或） !~（取非）
（异） — 只有真假类型有
绝句的且或非逻辑都是短路计算的，也就是说 假 & 不可能, 真 | 不可能
我相信，既然绝句已经改了这么多了，不会有人觉得让 (&) 官复原职很奇怪
第一眼看…