xuld

@yooomu 有好处不代表就要到处用。

药有没有好处？你天天吃吗？

javaer 总是用“这样才专业，这样能避免 XXXX 问题，这就是 java 生态”这样的方式回答问题

确实，这样能避免 XXXX 问题，但问题是过去、现在、未来都不会出现 XXXX 问题。
或者，如果 XXXX 问题真的出现了，再改代码也来得及

@yooomu "楼上说的 getter setter ，只不过加上了语法糖，看起来没那么一坨"，这句是不对的，

举个例子，下面的代码，有 java 味的人看了浑身不自在：

class A {
public int a = 0;
}

一定要写成这样，才舒服：

class A {
private int a = 0;
public int getA() {
return a;
}
public void setA(int a) {
this.a = a;
}
}

一个人喜欢做什么工作，和实际做什么工作，往往是不同的。
事实上，多数程序员对语言和工具是没有选择权的，因此他们的喜好其实毫无意义。

假如你有选择权，基本上你会选择最熟悉的，而不会去客观比较各家的优缺点。
即使你看到你最熟悉的语言和工具有若干的缺点，你也会选择无视。

而决定你最熟悉哪个工具，事实上是看你在刚工作阶段，接触到谁。
以上这些，其实和所谓的“生态”、“特性”、“易用性”等毫无关系。

AI 生成人类语言有两个致命缺陷：
1. 生成的结果可能完全离题（这其实不能怪 AI ，而是大部分人连需求都说不清楚）。
2. 生成的结果可能隐藏错误，需要人工校验（这时很多人会想还不如自己写）。

而编程语言作为自然语言的子集，天然克服了以上两个缺陷：
1. 编程语言语法简单太多，离题的可能性大幅下降。
2. 生成的结果对不对直接运行一下就行，不需要人工看代码校验（真正享受到 AI 的快感）。

因此用户对生成编程语言的 AI 产品的满意度肯定会高于生成自然语言的 AI 产品。

从商业角度，先拿编程语言做抓手是一个非常好的选择，因为用户更容易买单，更容易验证商业路线。

不用看评论也知道。
后端：接口要分的越细越好，前端你来组装。
前端：接口要越少越好，只要前端要展示的你都要一次性下发。
阿里：前端同学、后端同学，你们表吵了，这事让中台同学来。

“一个 char 由两个字节组成 但一个 utf8 汉字由三个字节组成”，这句话本身没有问题，但代码里的 char 变量和这句话里的 char 不是一回事.。

字符的本质就是一个整数，比如“我”的编码是 25105 ，几乎所有程序在运行时都会直接存储 25105 。

编译器同理，无论源码里面是什么，用什么编码，最后都会统一解析出 25105 这个数值。

java 的 char 类型本质是一个 16 位整数。char a = '我'; 本质等价于 short a = 25105 。显然没有问题。

所以这个问题其实和“Unicode”、“UTF-8”没有任何关系、更不要去扯什么文件编码，那只会越扯越糊涂。

小白：我想学做饭
大师：用电饭煲啊，先去网上看看电饭煲的广告，给你推荐个下单地址，然后买过来，使用做饭功能，就可以做饭了

有没有可能直接用 tsc 编译一下就变成 js 了--类型啥的，是你说不要的