对于 boolean 的属性，也就是类型是`bool`的变量、字段或属性，isXxx 没什么不好的，而且还能统一清晰的让人知道这个字段表达「 XXX 的状态」这个概念。

真正有病的是某些语言里 boolean 的 getter 非要叫 isXxx ，所以禁止 boolean 属性以 is 开头这件事。

你把它理解为 Self 类型的模拟就行了。感觉 Java 就喜欢制造一些很奇怪的术语，例如把好好的协变逆变叫成 PECS 。

之前写过一点 Swift 的感觉是如果只是满足于堆砌 UI 或者简单的应用那 Swift 还是蛮足够的。但如果要稍微往深了做的话，似乎 Swift 不太够，得上 OC 。

不过那之后我就溜了（

也许可以先试着把 Swift 弄熟悉吧。

@songray 虽然 var 那个确实有这个想法，但是其实某种程度上我还蛮喜欢 JS 的（ bushi

@mekingname 这个思路不错，感觉可以再考虑一个专门应对它的设计模式（

@koykoi 这个之前也有看过，甚至有做过一点贡献（ bushi 不过感觉 Dreamberd 比较偏向前端，和我的想法不太一样

@FalconD 认同

@kneo 听起来有点规则怪谈了

@DOLLOR 想起 PHP 那个 semicolon 了……

@FYFX 这个不错！不过感觉实际实现有点难度，很可能在实现之前自己人先晕了

@jianchang512 说到 try/catch ，我倒是想过一个只有 try/catch 来表达控制流，并且所有 if/while/for 都得用 try/catch 模拟的语法……

@soul11201 感觉这个思路是「做一件事，但做得马马虎虎」，刚好和 unix 哲学背道而驰

@spongebobsun 随着 JS 不停刷版本，其实 JS 似乎反而还越来越像个正常语言了……而且 JS 有许多灵活的东西我还是蛮喜欢的（叠个甲，我是静态强类型阵营的）

@llsquaer 不完全是，某种程度上我觉得 JS 的设计虽然有很多问题，但是其实已经算是蛮健全（？）的了。在低代码或者企业级技术栈里面有更多古神低语，当然 JS 的一些上古框架的很多设计也确实很难绷。

@xuld 其实我倒是有想做自己的语言，但是就像你说的，成熟的语言需要一整套生态和工具链，我眼下优先可能考虑更健全的设计吧，不过这个倒是后话了……问这个问题某种程度上算是吐槽（）

@jspatrick 可能因为我比较熟悉 JS （

@ayase252 这个似乎确实某种程度上算是个潘多拉魔盒了……感觉也确实是这个问题下的必选项（）

@ns09005264 还可以再加个 0 、void 和空字符串

@DiaoWang 想到了一个叫 BANCStar 的语言了（虽然跟你描述的不太一样，但感觉思路很像）

@8620 可以指一下路看看是什么课程嘛，感觉很有趣想 follow 一下，顺便也从比较高层的语言设计转向底层实现，近半年主要是自学 UW PL 和 Scala 的公开课，然后自己断断续续看书写自己语言搞各种东西，不过都离底层或者硬件实现感觉有点太远了（

@Binwalker +1 ，话说我给对象转码开小灶就是从 lambda 和递归上手的，感觉效果还不错，很多东西一开始讲通了后面再深入就方便很多了。

Excel ，ActualBudget ，或者自己写

没有办法做到，某种程度上说这是 Java 的一大缺陷了。

放心，以后也不会修，因为这个功能养活了许多设计模式。

一大波软粉在前来的路上。

（以及企业版也不好使，我都快给 Windows 自动更新搞破防了，然而软粉只会跟你不停复读说你不会用 Windows ）

主要也是我的使用场景里面重度依赖 WSL ，好几次更新完发现 WSL 和 IDEA 等工具出现各种离谱问题。。

感觉先把 Core Java 学好最重要吧。

明年我也加入这里 10 年了，希望到时候能有点什么可以回忆的东西吧

Go ，因为没有泛型，符合原汁原味的 OOP 思想。

DDD 和六边形那套东西，函数式编程的概念反而没什么难的

「小红书」和「有趣的计算机」这两个词居然可以在同一句话里出现吗。

扫了一眼基本上也都是些大企业老板、富哥富姐或者产品经理之类的，很好奇这些 title 跟「有趣的计算机」有什么联系？

要看彩虹屁我还不如去推特看马斯克喷人去。

年化 5%的方法，大概你标题里面已经给出来了。

头一回见到把类型、参数名和注释垂直对齐的格式，这种格式要是稍微改个参数名感觉要维护起来会很难受

能不返回 None 就不要返回 None

首先，这不叫防御性编程

@UncleCAT4 是指大四大五啦，法国的大学学制是五年的。


@roundRobin 主要也是看团队里面并没有把 PR 细化到这个地步，一般一个 issue 就是一个 PR ，如果大家的 commit 和 PR 都很细的话我肯定是跟着他们做的。GitHub 上的个人项目倒是不会做那么细就是……


@Contextualist 好建议，我倒是还没太熟悉 rebase 的用法，感谢提醒。


@tolbkni 注释我感觉问题在于后面改来改去的很容易就会丢掉上下文……


@GeruzoniAnsasu 示例这个确实不太好，不过一方面也有看团队里一个 PR 也就几个 commit ，我自然会倾向于避免上来就推几十个 commit 的巨型 PR ，所以也会有想要把 B 「虽然是不同的事情但在功能上相互联系的几件事组合在一起」的倾向，尤其是发了两次包含连续四五个 Refactor 的 PR 之后。


@Scarb 这个模版倒是不错，有时候我感觉我也有点像在往这方面靠。


@janus77 会的，会先看 git blame 找出 commit 的历史记录，问题是一般来说别人都是简单的一句话甚至没有提到他的代码意图，所以我才感觉如果有个 commit message 会清晰很多。