你们看看我又双写了多少个字... 都是干货吧？尤其是上面 Haskell 和 Java 的，我作为 Java 开发者一直是知其然（howTo）不知其所以然（why），现在想必都非常清楚了

Java 里没有损失的类型转换貌似都可以是 implicit（隐式）的，而有损失的则必须是显式（explicit）的

Java 的 primitive （aka. valueType 但不一定是真的值类型，我不清楚他们到底是 pass-by-quantity 传值调用还是 pass-by-reference 传引用调用也不清楚是分配 allocated 在栈（Java Stack）上还是在堆（Java Heap）上）按位长度排其实有些「不分上下」的类型，所以我们按「精度」排是 byte(8) short(16) int(32) long(64) float(32) double(64) （都是数值型，额外还有个叫 char 的 utf-16 （Unicode）字符是 16 位）（其实嘛，boolean 和 void 也算，但 void 不算正式的类型）

现代的电子计算机架构，32 位 IEEE754 浮点和 64 位的其实 overhead（开销）基本都一样，所以默认基本都是 f64(double)

一般一个 byte 被叫做一个「字节(8)」，两个被称为一个「半字(16)」，四个被称为一个「字(32)」，八个被称为一个「双字(64)」（括号：二进制位长度）

将一个类（e.g. Object）的对象 cast 到它的子类（e.g. String）是不安全的。所以需要显式转型，在那之前最好还 <reified T>.cast(Object obj) （删除，其实是 T Class<T>.cast(Object obj)）方法 check 一下，抛出异常就不要再 runtime cast，很多人包括之前的我不知道如何 不 supress explicit 类型转换的 IDEA inspection 而修复问题，其实你应该显式检查能否强制转型。这样看来其实很多人都并不了解 OOP 动态类型系统呢。都不知道「why」你要显式地把一个对象显式转换为它当前类型的子类

实际上你只能把一个对象在运行时转换到它实际的类型，不能随便转换，否则运行时就会抛出异常。很多人分不清编译期和运行期类型检查的联系，不过我也分不清就算了...

现代电子计算机本来就是用一大堆二进制数位（bits）堆起了你的数据，而类型系统所做的就是负责「解释」这些数据和「检查」你的代码是否「类型安全」，即满足类型检查的「约束条件」，比如不能拿 String 去调用 System.exit(int) 那样会引发未定义行为 UB（Undefined Beavior）

如果真的是我太蠢了一直不理解那 Haskell 的一点资料也是有价值的... 大概吧 😶

所以说啊成天写了那么多字在自己的频道上，如果哪天 Telegram 爆炸了，王八蛋 leader durov 跑路了，然后我的数据写了这么多个月的东西全部爆炸 lost 了我都可以进抢救室了... 还是备份一下吧 #telegram #emmm #life #tech

所以说能自己开发 web 应用也是幸福嘛... 本来可以往 Stiack Note 上记的然后利用机器人同步更新 2333

Telegram 这就叫企业级应用程序...

虽然不得不说这已经是幸运，因为 QQ 完全不允许我们创建频道而且即使是 VIP 也不给永久保存的
而微信我不知道给不给永久保存 #tencent #China #Low

我觉得这人（就这篇文章的各种例子而言）有点 low... 😶

有时候感觉知其然并且知其所以然是一种幸福，在别人都只看到表象的时候你能看到本质，所以你不会被各种清奇的问题迷惑也不会被花里胡哨的技巧蒙蔽双眼，总是选择最合适的，而这是只知道 how to 所不能做到的

看到这篇文章突然感觉 Ruby 之类掺了函数式理念的 OOP 真是对工业界帮助好大啊... 区区一个 block 表达能力和自然性（符合直觉、容易理解）吊炸天
别说现在 Enumerable 的集合处理方法了... 接受一个 lambda、block 或者之类的代码块 "Invokable"，从此写码不求人... 太自然了

Java 这种稳如老狗并且老到不行而且从来不加新特性的语言都在添加这种语法和 API，业界主流了。我大多范式（multi-paradigm）威武！

博客园首页发现一篇奇怪的文章，然后发现这个人还真是脑洞清奇。所以说，奇怪的问题只因为奇怪的人用奇怪的方法产生出来

js.es5 map循环一大坑：循环遍历竟然出现逗号！
https://www.cnblogs.com/soyxiaobi/p/9898762.html

最奇怪的是他写了这种代码，好吧是 array.map 不是类似 Ruby 里的 Array#map! 所以优化后可以说是基本等价于 forEach 的

/********* ES6 **********/
//一行代码可以省略return
array.map( item => console.log(item))   
=>
array.map( item => {
    return console.log(item)
})

//多行代码需要{}
array.map( item => {
    //do someting  花括号一般是处理某些逻辑
})

//返回组件
array.mao( item => (
    <div>{item}</div>   //这种比较常出现在react的jsx
))

现在 OOP 把 PP（面向数据结构 aka. 指令式） 和 FP（函数式） 都给吞了... 就差一个逻辑式了？啊啊啊（其实还有很多）（但大的「范」只有这几个...）

我跟你们总结一下他是在讲什么：
+ 如何使用 String Iterable<String>.join(seprator: String) ...

如果你不知道这怎么用，我教你怎么用：

['apple', 'orange', 'pear'].join(" vs. ") //=> "apple vs. orange vs. pear "

如果你是开发者并且发现 pear 后面多了一个空格，我告诉你怎么去除，除非是性能敏感否则这样写已经很好了

['a', 'b', 'c'].join(" vs. ").trimRight() //=> "a vs. b vs. c"

如果你好奇它（Array.prototype.join，限于 Array of String）是怎么实现的，我给你一个实现

function joinString(strs, seprator = '') {
  let buf = [];
  strs.forEach(s => { buf.push(s); buf.push(seprator); });
  return buf.join('');
}

如果你不止想在集合项之间使用连接（contact）操作，你可以使用 reduce



['a', 'b', 'c'].reduce(console.log)

没错，就是这一个姿势点，他居然能写一页... 而且前端还没做好... 而且例子举得居然不是最简用例... 而且废话贼多，我当时还以为他是讲 ES6 里数组的空位 [1,,3] 问题呢（实际上虽然这个是反智的，但 forEach 和 for let 没有这个问题...）

如今的前端啊... too young... sometimes naive 🐸... 算了，因为我的确有点失望，这位前端小哥教的例子到底是最佳实践呢还是半懂不懂的技巧滥用代码呢...

现在看来其实也没有什么好奇怪的呢... 毕竟尤其是中国，开发者水平差异是巨大。而再重灾区一点的就是 web 前端... 因为他们真的是可以做到干一辈子前端当一辈子码农的 — 你可能看不到他们的技术较 n 年前有什么变化 — 可能都是差不多的，或者说他们对自己代码的「理解层次」根本不会有变化，都只知其一不知其二。

然后我回忆当时 @drakeet 删频道的时候我真的很惊讶啊，他闭源项目和博客也就算了因为数据没有丢失，但如果他没有备份而频道数据丢失了呢... 那自己这么多年积攒的广播都没有了... 他不会珍惜这些东西吗...

duangsuse 不会 coroutine 呢... 其实我接触 #lua 也是很早之前（十几个月）的事情了，但当时 coro 对我来说只不过是技术名词而已。现在好像也是... 我只知道 Fiber 这种 coro...

#Threading in #Kotlin 的 coroutine 「Green Threads 绿色线程」 concept

C# FCL 线程池... QueueUserWorkItem...

正是因为知道的多，所以才知道自己的无知

真正有知识的人的成长过程，与麦穗的成长过程一样：

麦穗空的时候，麦子长得很快，麦穗骄傲地高高昂起；

但当麦穗成熟饱满时，它们开始谦虚地垂下麦芒。

正是因为能透过问题的表象看到本质、透过宏观看到微观，能站在比别人低、比别人靠近本质的地方观察，才能做到「知其变」，才能在技术更新越来越快，各色语法糖变化、语言特性换上新包装的时代里坚守自己永恒不变的真知「守其恒」

正是因为懂得多，看得细致、能够透过一行行 C# 代码看到生成的 IL、看到 JIT 编译出的机器代码，才可以发现底层以微粒子形式存在的数据竞争风险和值类型装箱操作的隐患，而不是等到程序已经公开部署、安全漏洞已经被大量利用才迟迟修复

只有肯沉下心来学习知识，才有可能从理解 -> 使用 -> 创造一步步走上去，只有有了更高层次的视角 才能解决别人“不能解决”“无从寻觅”的问题