xuld 最近的时间轴更新 xuld 最近的时间轴更新
xuld.net/
| 我在全职开发新编程语言，寻找对语言设计有想法的同学 程序员 • xuld • 2024-03-11 14:06:06 PM • 最后回复来自 qsgy123456 | 129 |
xuld 最近回复了
账号+密码+开机密码都没有，是真的忘记了吗？能同时忘记这三个东西的人大概率不会用手机把
方法是有的，属于灰色产业，一般人也不会告诉你
方法是有的，属于灰色产业，一般人也不会告诉你
11 小时 51 分钟前 回复了 muchan92 创建的主题 › 程序员 › 一种省时省力的编程方式 |
既然你的方法省时又省力，为啥你自己开源的两个仓库的代码还是一坨 vue 的代码
11 小时 57 分钟前 回复了 vagranth 创建的主题 › 奇思妙想 › 现在还有人需要“翻译 API 服务”吗？ |
如果是卖 api ，那就只能卖给程序员。
如果你说你前几天写了一个自己用，意思是：写几天就搞定了。
那请问程序员为什么不自己花几天时间搞定，而要买你的东西。
这就好比让钢琴家花钱听别人弹钢琴，你觉得可能有人付费吗
如果你说你前几天写了一个自己用，意思是：写几天就搞定了。
那请问程序员为什么不自己花几天时间搞定，而要买你的东西。
这就好比让钢琴家花钱听别人弹钢琴，你觉得可能有人付费吗
12 天前 回复了 GotKiCry 创建的主题 › 程序员 › 好奇 Java 味是什么味 |
@yooomu 有好处不代表就要到处用。
药有没有好处？你天天吃吗？
javaer 总是用“这样才专业，这样能避免 XXXX 问题，这就是 java 生态”这样的方式回答问题
确实，这样能避免 XXXX 问题，但问题是过去、现在、未来都不会出现 XXXX 问题。
或者，如果 XXXX 问题真的出现了，再改代码也来得及
药有没有好处？你天天吃吗？
javaer 总是用“这样才专业，这样能避免 XXXX 问题，这就是 java 生态”这样的方式回答问题
确实，这样能避免 XXXX 问题，但问题是过去、现在、未来都不会出现 XXXX 问题。
或者，如果 XXXX 问题真的出现了，再改代码也来得及
13 天前 回复了 GotKiCry 创建的主题 › 程序员 › 好奇 Java 味是什么味 |
@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;
}
}
举个例子，下面的代码，有 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;
}
}
13 天前 回复了 CapNemo 创建的主题 › 程序员 › 想知道各位平时编程时面对的主要约束，以及在选择语言和工具时主要看重的特性 |
一个人喜欢做什么工作，和实际做什么工作，往往是不同的。
事实上，多数程序员对语言和工具是没有选择权的，因此他们的喜好其实毫无意义。
假如你有选择权，基本上你会选择最熟悉的，而不会去客观比较各家的优缺点。
即使你看到你最熟悉的语言和工具有若干的缺点，你也会选择无视。
而决定你最熟悉哪个工具，事实上是看你在刚工作阶段，接触到谁。
以上这些，其实和所谓的“生态”、“特性”、“易用性”等毫无关系。
事实上，多数程序员对语言和工具是没有选择权的，因此他们的喜好其实毫无意义。
假如你有选择权，基本上你会选择最熟悉的，而不会去客观比较各家的优缺点。
即使你看到你最熟悉的语言和工具有若干的缺点，你也会选择无视。
而决定你最熟悉哪个工具，事实上是看你在刚工作阶段，接触到谁。
以上这些，其实和所谓的“生态”、“特性”、“易用性”等毫无关系。
27 天前 回复了 wangyzj 创建的主题 › 程序员 › 为什么现在 AI 场景落地专门盯着代码辅助干？ |
AI 生成人类语言有两个致命缺陷：
1. 生成的结果可能完全离题（这其实不能怪 AI ，而是大部分人连需求都说不清楚）。
2. 生成的结果可能隐藏错误，需要人工校验（这时很多人会想还不如自己写）。
而编程语言作为自然语言的子集，天然克服了以上两个缺陷：
1. 编程语言语法简单太多，离题的可能性大幅下降。
2. 生成的结果对不对直接运行一下就行，不需要人工看代码校验（真正享受到 AI 的快感）。
因此用户对生成编程语言的 AI 产品的满意度肯定会高于生成自然语言的 AI 产品。
从商业角度，先拿编程语言做抓手是一个非常好的选择，因为用户更容易买单，更容易验证商业路线。
1. 生成的结果可能完全离题（这其实不能怪 AI ，而是大部分人连需求都说不清楚）。
2. 生成的结果可能隐藏错误，需要人工校验（这时很多人会想还不如自己写）。
而编程语言作为自然语言的子集，天然克服了以上两个缺陷：
1. 编程语言语法简单太多，离题的可能性大幅下降。
2. 生成的结果对不对直接运行一下就行，不需要人工看代码校验（真正享受到 AI 的快感）。
因此用户对生成编程语言的 AI 产品的满意度肯定会高于生成自然语言的 AI 产品。
从商业角度，先拿编程语言做抓手是一个非常好的选择，因为用户更容易买单，更容易验证商业路线。
32 天前 回复了 szyp 创建的主题 › 程序员 › 前端后端的各位，接口请求数据的时候，你们更喜欢哪种方式 |
不用看评论也知道。
后端：接口要分的越细越好，前端你来组装。
前端：接口要越少越好，只要前端要展示的你都要一次性下发。
阿里：前端同学、后端同学，你们表吵了，这事让中台同学来。
后端：接口要分的越细越好，前端你来组装。
前端：接口要越少越好，只要前端要展示的你都要一次性下发。
阿里：前端同学、后端同学，你们表吵了，这事让中台同学来。
47 天前 回复了 zhouyin 创建的主题 › Java › Java 为什么能给 char 类型赋值中文字符 |
“一个 char 由两个字节组成 但一个 utf8 汉字由三个字节组成”，这句话本身没有问题，但代码里的 char 变量和这句话里的 char 不是一回事.。
字符的本质就是一个整数，比如“我”的编码是 25105 ，几乎所有程序在运行时都会直接存储 25105 。
编译器同理，无论源码里面是什么，用什么编码，最后都会统一解析出 25105 这个数值。
java 的 char 类型本质是一个 16 位整数。char a = '我'; 本质等价于 short a = 25105 。显然没有问题。
所以这个问题其实和“Unicode”、“UTF-8”没有任何关系、更不要去扯什么文件编码，那只会越扯越糊涂。
字符的本质就是一个整数，比如“我”的编码是 25105 ，几乎所有程序在运行时都会直接存储 25105 。
编译器同理，无论源码里面是什么，用什么编码，最后都会统一解析出 25105 这个数值。
java 的 char 类型本质是一个 16 位整数。char a = '我'; 本质等价于 short a = 25105 。显然没有问题。
所以这个问题其实和“Unicode”、“UTF-8”没有任何关系、更不要去扯什么文件编码，那只会越扯越糊涂。
Select Language