#CS #Python

我这里想比较偏激的说，一切不能被它们的创造者默写、可视化下来的设计，都是冗余或者不规范的设计。 #statement

如果说你经常使用类似的设计但从没觉得不对劲，那是因为你从来没完全重写过你的代码，所以感受不到他们的奇怪。

Java 1.3 是 Plain Old Java，那时候整个语言面向对象结构基本已经确立了。Java很早都有APT(Annotation Processing Tool)了。
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搞乱就好…

#Kotlin Write once in one language, run anywhere on all platform.
编程就应该是这样，语言表达无关、平台无关，什么『专有』…… 都弱暴了！ M$ 之前那么宠 C# 和 .NET，最后还是只能给它官方开源跨平台了呵，不是想弄成Windows专有的技术么。

#dev #PL #statement 今天好不容易天晴了，那就随便谈谈程序设计上的一些知识吧。

说的是『表述式(imperative)编程』和『定义式(declarative)编程』，它们是编程范式(programming paradigm)中区别最明显的两种。
偶尔，表述式也被称为『命令式』，定义式也被称为『声明式』。

如果让表述式的程序员写一段『把大象塞进冰箱』的代码，其中利用外部抽象『打开、塞进、关上』，他们会这么写：

事 入口() 为
  打开(冰箱的门)
  塞进(冰箱的里面、大象)
  关闭(冰箱的门)

当然 *程序=数据结构+算法* ，我这里没有提到关于冰箱、大象的数据结构抽象建模方式，不过我也没有（为了简化讲解目的）过分实际到连 打开(物体) 都没提出来，只有 打开冰箱门() 的程度。

如果让定义式的程序员写呢？

事 入口() 为
  塞进里面(冰箱、大象)
事 塞进里面(容器：物体、此物：物体) 为
  打开(容器)；塞进(容器的里面、此物)；关闭(容器)

想想看，如果我们又要求在塞完大象后，放一首歌 比如，《亲爱的大象》 会如何？
如果我们的 塞进(物体、物体) 编程接口，可能（基于异常系统或是分情况的数据结构地）失败会怎么样？失败了第一是不能放那首歌，第二是不能异常退出整个程序。

（这里假设我们使用的是有自动内存管理，而无须指针弱引用啥子的语言）

量 歌者：播放器 = 播放器()
歌者去加载(文件("大象大象.wav"))
歌者的位置 = 0
歌者去歌唱()

我们讨论的问题比较抽象，但利用编程语言提供的表达式、程序和数据对象定义、基本控制结构组织这样的程序，就是我们的日常工作。

那么具体修改完的代码我就不贴了，因为实在有点长，但是我们肯定能预见到，表述式的程序员直接复制粘贴以上代码，而定义式的程序员又会定义出新的子程序(subroutine, sub-procedure) 事 播放音乐文件(路径：文) 。

其实一句话可以总结这两种编程风格（我本周的文章也会说到）
*『表述式越写越复杂，定义式越写越简单。』*

这里我们能够看出他们最大的区别，就是表述式的程序员喜欢「直白地」表达程序，而定义式的程序员喜欢抽提（抽象、提取）重复的程序逻辑，所以哪怕是我们要求再加音乐播放的功能、再要求塞大象进冰箱的子程序可能失败，都不会使得代码冗杂难看，不会进入所谓的『嵌套地狱』。

同样地，他们会努力地提升代码的可读性，也只有用定义式的思路编程，你才能设计出解决回调(callback)嵌套地狱的Promise异步任务抽象，而表述式的程序员则只会抱怨它难看，而不知道或者懒得去想到，其实有改进方法的。

你是表述式的程序员还是定义式的程序员呢？相信许多人会觉得表述式和定义式不分高低。（其实我上面说的『表述式』『定义式』也不是准确定义，而是说它们的使用者经常的编程风格，从某种意义上就是它们的『编程风格』）
不过，我个人觉得，不管是C、VisualBasic这样的『表述式编程语言』还是Scheme、Haskell这样的『定义式编程语言』，都不要忘记经常重新检查自己的代码，尽可能自然，而不是「简单」地描述你的程序。

要记得，真正的少写代码是使得它更好看、更少冗余，而不是在起名字上花费心思，最后弄得大家都看不懂，这也是Kotlin实际上的编程风格。

这不是智商低的表现，相反它是清清楚楚地认识到了自己和别人的智商、精力有限，抱持对软件和其他有兴趣查看源代码的人的善意，而对代码的质量格外地珍惜。
虽然『代码』实现只是软件里很小的一部分，在信息技术里也不是最关键的问题，我真心希望大家以后编程的时候，都要注意呦。

其实这里我也可以再顺便扩展地说到面向对象范式的内容的，也可以关于『编程是什么』这个问题说点观点，可是好像属于跑题内容……


浩哥也说过这个话题

#project Binarie 的（字节序上）『莫名其妙的问题』已经被确认为泛抽象数据结构（机器数的 shl shr and）编程失误，顺序没搞明白，pop_right 了 byte 导致 integralToBytes 的输出顺序是反的 0123 -> 3210。
E2im-2 基于标准输入输出流协议的一个细节（准确的说，是我『面向调试编程』导致的…… 很羞愧），多输出了换行符的问题将在明天修正。

#PL 绝句考虑了一下是不是要区分“”双引单引‘’的注释/文档，后来我觉得，单引号是文档更好。
因为它显得更有『语言结构表达特质』一些。