... 说起来，我就现在也还是不了解机器学习类算法，大概还需要很多时间吧...

这里：

那 NLP 就不是这种情况喽，看 HanLP 它说它用了 Markov 链，这也是一种机器学习预测算法

谈到 Markov 链，发明 Synthesizer V （一个信号处理的三语种拼接 + 人工神经网络歌声合成软件）的大佬华侃如曾经高中的时候有讲过


https://github.com/Sleepwalking/hmm-workshop

...

噢找到了在这里，
Sleepwalking/SHIRO/master/readme.md#hsmm-primer

篇幅比较短，作者在原来的知识上也做了大幅度的精简，我还暂时没有时间看，你有时间的话可以学学，推荐。

.... 其实虽然大家开始在 coolapk 的时候都玩梗比较欢乐啊，但是目前我看到最能玩梗的就是你了，Rachel 基本不活动了（其实 LIF 的频道维护也下降了），然后，果然还是有人就有纷争么...

你肯定是知道江学的 🐸，而且也经常看到你膜。不可能看不出来我是在玩梗，除非你开始就对我持有负面的态度，比如说倾向于认为我很喜欢表现、尽空谈不实践、缺乏拿得出手的作品。

怎么就那么像当时我遇到冰封哥的时候，我一直觉得他的态度有点不友好、有点高高在上，虽然我的确有把自己放到最低因为我见识过他的实力水平。（当然他是真·大牛，游戏引擎都写过，不能说是不擅长在任何领域编程的人）
而其实呢，只不过是他经常在某些群聊谈我那时侯半懂不懂的领域而已，即便我只把自己当是菜鸡，都产生了一点负面情绪。
半懂不懂和自己完全不想涉足的技术领域，在听到一个自己不确信的人谈论的感觉时候是不一样的。前者你会觉得对方很不友好，即便说的信息可能是真的、后者你根本不在乎，甚至会无脑膜。

其实我也和你是一样的，开始我眼里的你就是和 drakeet 没什么区别（当然这个评价对你和对 drakeet 都是不公平的）的单靠工程经验和死肝代码取胜的工程者，
但是实际上你们的能力开始都是在我之上（我开始真的是什么都没法懂，尤其是一大堆名字和接口模式）；现在我也得用力去赶才能稍微追上一点，大概这就是所谓的同辈压力吧。

https://github.com/pan93412/JavaTranslator/blob/master/src/main/java/tw/pan93412/JavaTranslator/Model/PropertiesConverter.java#L72

代码里可不要买萌哦

—

总的来说还可以

Converter 你可以定义一个接口把共有操作抽象出来，这样会比较好一点。

interface Changeable { static int maxChangeCount(); }

接口方法也可以是静态的，当然一般是定义接口实例的方法。


—

命名上，我建议你命名的简单一点。

比如说这里

public TranslatableObject mergeObject(TranslatableObject ref)

叫 public TranslationDict mergeWith(TranslationDict other) 就可以了

其实你觉得有必要的话，按照优先顺序从几个 Map<K, V> 里挑 KVSet 合并也可以抽提出来，有必要的话。

<K, V> Map<K, V> mixMaps(final Map<K, V> maps...) {
final Map<K, V> result = new Map<>();
return mixMaps((Object[]) maps, result);
}
<K, V> Map<K, V> mixMaps(final Map<K, V> maps..., Map<? super K, ? super V> destination) {
for (Map<> dict : maps)
for (K key : dict.keySet())
if (destination.contains(key)) continue;
else destination.put(key, dict.get(key));
}... 总感觉虽然抽提出来了，但是好没用的样子。


https://github.com/pan93412/JavaTranslator/blob/master/src/main/java/tw/pan93412/JavaTranslator/View/I18n.java#L17

你也可以叫 tr, getText 什么的，不过 i18n 这个名字很不错
另外它不应该声明抛出 NPE，用 @NonNull 注解吧。

然后这个类你没写架构器....

#tasks 接下来这个地方会放一些暑假打算去做的事情 🤔

我留下了太多稿子... 看来会有做不完的事情了

上个暑假了，我花了一个星期的时间去整理，把这类东西加以注释发到频道上来，可是看起来，好像还是按照优先级归类排着做好呢。

解决了科学上网问题，需要在修好的笔记本电脑上弄个 ArchLinux 并且安装合适的软件。

啊，刚才才发现你说了这句话…… 😟
好同意啊，我刚刚的消息里也是这个观点，能写成表达式的为什么要弄个函数？能用内部 DSL 的为什么要弄个 XXEL？

……或许是为每一个主语是集合的命题定义逆命题太麻烦了，比如 list.all {...} 是不是得定义一个 list.notAll : List<T>.((T) -> Boolean) -> Boolean -- (exists (not . f)) 呢？此外你还能在 Collection<*> 里找到一大堆输出和接收命题方法(single, exist, filter, find, partition, takeWhile, …)，是不是都要支持 not……
不过 !in, !is 这两个关键字倒是存在的
标准库的简洁（这里指的是最终输出组件包的简洁性，代码简洁性可以用 codegen 工具）和用户的需求有时候不能两全，其实有这种方法也未尝不可，不过利用名字上的区别的话…… 可能有点鸡勒了

Ruby 是直接搞了个 unless... 完美解决了所有这类问题

……当然这其实一点都不完美，对于我们这类母语不是英语的家伙，这种语法对初学者是相当疑惑的，尤其是知道 if 和 unless 肯定是则一而选的分支逻辑的时候，我当时看到 if unless 并存的子程序是想死的心都有了！

我个人觉得，既然 (p as Boolean).not() 一下就可以了，多写个 ! 也不是件难事

我之前也在 Python 里写了一个支持命题的函数组合库，有一个 notp(q) 函数能够直接定义 notNone = notp(emptyq) 如果这类检查常用，利用多态和 method extension + infix 也未必不是办法

a 对了，说起来我之前为了一个 Spring 的项目 context path 绑定写过一门 DSL，既然大佬写这类程序，为何不也设计一个专门的 DSL 来定义接口？Swagger 实在太难看了，前端写东西果然就是只会用 existing 的 markup language……

我觉得我们应该感谢他们是 JavaScript 风格的程序员，不是 Java 风格的，我可懒得为了一点 boilerplate 去写 XML 这种更大更危险的 boilerplate。 😵

别人说 Mongo 是面向文档的数据库，我感觉和 RDBMS 有多大差别么…… 😓
反而还更莫名其妙一些，起了一大堆新名字

其实这种数据处理的话，就是 Kotlin 的 collection method extension 大概也能完成吧…… 名词一大堆一样

我很讨厌 Spring 在弄那个 url mapping 的时候很多 boilerplate

我见过不少人说自己对代码有洁癖，但我对任何代码真的是看不得一点重复……
一有重复我就忍不住想解出模板、一见到瞎写的控制流我就想把代码挂出来瞎喷一遍……

一般来说我对自己不理解的算法、模型（比如关系数据模型的 1:1, 1:N 什么的）都会写 N 遍，往往是写第二三遍的时候我会开始能够把代码缩短成原来的 3/4，如果原来的代码非常冗杂的话可能是 1/2，甚至是 1/10

所以我想……

为什么一个应用程序，里面居然能够放这么多重复的名字？

我看到的时候，立刻就浑身发毛，或许这真是我多虑了
但我真的是觉得那些程序本来就不应该是这个样子罢了…… 我是一个重复的词都不想见到

同意……
其实我原来也就是想发点不能编译的代码

我觉得 Kotlin 的 enum class 真是太好用了，如果你不想写专门的辅助类，它可以做到很奇特的效果

而且可以辅助你进行更远的设计