Interactive protocol (Tunnel)
{a} means (repeat a); (a b c) means (sequence of a b c); (a|b|c) means (a or b or c); a!t means (ensure t unread before read a)
'+', '-' for each file input, '.' normal; '!' (error code) fail
'?' for each file input, 't' immutable flag set; 'f' immutable flag unset; '!' (error code) fail
{a} means (repeat a); (a b c) means (sequence of a b c); (a|b|c) means (a or b or c); a!t means (ensure t unread before read a)
newline '\n'Feedback protocol
Ws {' '|newline}
Tunnel {Operation newline}
Operation Action Count Ws Files
Action '+'|'-'|'?'
Count {digit}
digit [0-9]
Files {Path ws!newline}
Path (Escape|anyChar) until ws
Escape '\\' anyChar
'+', '-' for each file input, '.' normal; '!' (error code) fail
'?' for each file input, 't' immutable flag set; 'f' immutable flag unset; '!' (error code) fail
本来字符级别处理的类 Scanner 的算法我之前写过不止一次，只有写 C++ 的时候老出问题，还无尽循环导致分配太多内存，我估计肯定是某处数据流没移动，可是检查过却都是对的
其实 count 根本就是一个冗余设计…… 但是也不是没道理的，毕竟本来就应该有确定大小，我写的时候随便了点动态大小了
duangsuse::Echo
这样能够做到吗？
我在脑子里模拟然后确认了一下，除了 onHandle 外解析部分应该是完好可以使用的。
因为好像实在是没时间了，而且貌似已经就要收尾了（虽然我还是很不高兴，因为做的不够多）
所以我不得不放弃了使用 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搞乱就好…