InkStone 最近的时间轴更新 InkStone 最近的时间轴更新 |
InkStoneV2EX 第 95741 号会员，加入于 2015-02-04 18:10:07 +08:00今日活跃度排名 799 |
InkStone 最近回复了
15 分钟前 回复了 zhengfan2016 创建的主题 › 程序员 › 反思，我写的前端的 react 味是不是太重了 |
如果没有哪个地方需要以 BaseCard 作为通用去访问这两个组件，那不建议以 is-a 的语义做抽象。如果有的话，也优先使用 interface （我不熟悉 ts 的 interface 语义，不知道是不是跟 Java 一样），interface 用不了再考虑继承。
34 分钟前 回复了 deplives 创建的主题 › 程序员 › javaer 是不是写啥都是一股 Java 味儿 |
@oamu
C++：对，不好。Java 不就是学的这一套么
Go ，Rust：对，不好。Go 就不说了它缺的也不止这一个； Rust 这点没少被人吐槽，经常有人问“如何实现数据 mixin 而非只是接口 mixn”
C++：对，不好。Java 不就是学的这一套么
Go ，Rust：对，不好。Go 就不说了它缺的也不止这一个； Rust 这点没少被人吐槽，经常有人问“如何实现数据 mixin 而非只是接口 mixn”
1 小时 41 分钟前 回复了 deplives 创建的主题 › 程序员 › javaer 是不是写啥都是一股 Java 味儿 |
@oamu public field 怎么会跟 property 一样呢？ property 是 OOP 的，它可以在编程时像一个 field 一样被使用，但支持封装内部实现细节和多态。public field 既不能封装细节，也不能实现多态。
Java 味最突出的地方就在这里：因为语言层对 OOP 的支持不好，所以必须搞一大堆开发约定，来在开发中模拟 OOP （此处的 OOP 还可以替换成 FP 以及其他各种范式——事实上 Java 对什么范式的支持都不好）
Java 味最突出的地方就在这里：因为语言层对 OOP 的支持不好，所以必须搞一大堆开发约定，来在开发中模拟 OOP （此处的 OOP 还可以替换成 FP 以及其他各种范式——事实上 Java 对什么范式的支持都不好）
4 小时 59 分钟前 回复了 deplives 创建的主题 › 程序员 › javaer 是不是写啥都是一股 Java 味儿 |
虽然整体上我赞同标题，但你贴的这个一点都不 Java 。
首先多参构造在 Java 里典型的做法是 Builder 模式，而不是全塞构造函数。其次就算是 Builder ，也没人会写 100 个参数的 Builder……肯定会拆成不同类型分级构造的。
另外你这里完全没有 getter/setter 相关的内容。
首先多参构造在 Java 里典型的做法是 Builder 模式，而不是全塞构造函数。其次就算是 Builder ，也没人会写 100 个参数的 Builder……肯定会拆成不同类型分级构造的。
另外你这里完全没有 getter/setter 相关的内容。
5 小时 4 分钟前 回复了 jdz 创建的主题 › 程序员 › 除了 claude, 各位还另外主要使用哪个大模型 |
@jdz
我说的都是 API……免费的 API 效果太差了
我们有免费的 deepseek-r1 可以用，内部部署的没有数据安全问题，用起来没有负担。当然，即使是个人用，deepseek 也算是效果不错的 API 里比较便宜的一档了。
我说的都是 API……免费的 API 效果太差了
我们有免费的 deepseek-r1 可以用，内部部署的没有数据安全问题，用起来没有负担。当然，即使是个人用，deepseek 也算是效果不错的 API 里比较便宜的一档了。
5 小时 13 分钟前 回复了 jdz 创建的主题 › 程序员 › 除了 claude, 各位还另外主要使用哪个大模型 |
困难问题主用 claude ，一些零碎的、不太困难的问题用 deepseek-r1+联网，一些对不对都无所谓有个答案就行的，用豆包。
原因很简单，r1 便宜量大，豆包响应速度快。
原因很简单，r1 便宜量大，豆包响应速度快。
1 天前 回复了 xtx 创建的主题 › 杭州 › 在上海开车习惯了，去杭州开的好别扭。 |
深圳没去过，上海的交通确实在我去过的地方里断档领先。
另外吐槽一下，虽然杭州的交通很糟糕，但杭州的交通秩序在全国来看还算是好的
另外吐槽一下，虽然杭州的交通很糟糕，但杭州的交通秩序在全国来看还算是好的
1 天前 回复了 drymonfidelia 创建的主题 › 程序员 › 看到今天群里有人讨论微软用 Go 重写 TypeScript 编译器，为什么不是用他们自家的 C#？ C#在大部分 benchmark 项中性能都远超 Go， TypeScript 编译也不是在浏览器进行，不用考虑编译器体积 |
@lesismal
> 底层的问题
底层部分是原文内容。开发者特别强调了他需要 Go 的底层能力——事实上性能提升也多半来自于此。把工程从高抽象层次的实现改到 native 语言，天然就会获得巨大幅度的性能提升。
> 但是哪个其他语言的缺点少而且优点又像 Go 这么大呢？
Go 的优点在各种语言中并不算特别突出，缺点比 Go 少的语言更是数不胜数。
如果你非要我提一门这样的语言出来，那底层语言我提名 C ，几乎完美无缺的语言，它在整个编程体系重要到它的缺点都不再是缺点。
> 底层的问题
底层部分是原文内容。开发者特别强调了他需要 Go 的底层能力——事实上性能提升也多半来自于此。把工程从高抽象层次的实现改到 native 语言，天然就会获得巨大幅度的性能提升。
> 但是哪个其他语言的缺点少而且优点又像 Go 这么大呢？
Go 的优点在各种语言中并不算特别突出，缺点比 Go 少的语言更是数不胜数。
如果你非要我提一门这样的语言出来，那底层语言我提名 C ，几乎完美无缺的语言，它在整个编程体系重要到它的缺点都不再是缺点。
1 天前 回复了 drymonfidelia 创建的主题 › 程序员 › 看到今天群里有人讨论微软用 Go 重写 TypeScript 编译器，为什么不是用他们自家的 C#？ C#在大部分 benchmark 项中性能都远超 Go， TypeScript 编译也不是在浏览器进行，不用考虑编译器体积 |
1 天前 回复了 drymonfidelia 创建的主题 › 程序员 › 看到今天群里有人讨论微软用 Go 重写 TypeScript 编译器，为什么不是用他们自家的 C#？ C#在大部分 benchmark 项中性能都远超 Go， TypeScript 编译也不是在浏览器进行，不用考虑编译器体积 |
@lesismal
> 支持和好用是两码事
这就是为什么我说 Go 支持底层操作之类的只是特点而不是优点。
Go 的底层操作并算不上很好用，性能也有很大优化空间。我知道它是权衡利弊之后做成这样子，但在编译器这个领域，它在权衡中舍弃的那些东西还是挺重要的。
Go 的缺点大家都说过很多了我也懒得说了……现在不是别人没正视 Go 的优点，而是你没正视 Go 的缺点。
> 支持和好用是两码事
这就是为什么我说 Go 支持底层操作之类的只是特点而不是优点。
Go 的底层操作并算不上很好用，性能也有很大优化空间。我知道它是权衡利弊之后做成这样子，但在编译器这个领域，它在权衡中舍弃的那些东西还是挺重要的。
Go 的缺点大家都说过很多了我也懒得说了……现在不是别人没正视 Go 的优点，而是你没正视 Go 的缺点。
Select Language