V2EX › InkStone 的所有回复 › 第 7 页 / 共 29 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 3 4 5 6 7 8 9 10 11 12 ... 29

❮

❯

143 天前

回复了 CapNemo 创建的主题 › 程序员 › 想知道各位平时编程时面对的主要约束，以及在选择语言和工具时主要看重的特性

@CapNemo 那是因为算法竞赛不让用三方库

能用三方库的情况下，C++的大整数库使用体验远胜 Java （谁会喜欢连运算符重载都没有的大整数库呢？）

143 天前

回复了 deplives 创建的主题 › 程序员 › javaer 是不是写啥都是一股 Java 味儿

@oamu 有些语法糖，有就是比没有好，没有什么讨论余地。JVM 上的其它兼容语言，Scala 、Groovy 、Kotlin ，都支持 property 语法糖。其它新一点的主流面向对象语言也基本都支持，连 Java 自己都要搞 Beans 标准，搞 Lombok ，都不是没有原因的。

Python 别的不敢说，在 OOP 这方面吊打 Java 肯定是没问题的——当然，因为能在 OOP 方面吊打 Java 的语言太多了，这倒也算不上什么优点。

143 天前

回复了 zhengfan2016 创建的主题 › React › 反思，我写的前端的 react 味是不是太重了

如果没有哪个地方需要以 BaseCard 作为通用去访问这两个组件，那不建议以 is-a 的语义做抽象。如果有的话，也优先使用 interface （我不熟悉 ts 的 interface 语义，不知道是不是跟 Java 一样），interface 用不了再考虑继承。

143 天前

回复了 deplives 创建的主题 › 程序员 › javaer 是不是写啥都是一股 Java 味儿

@oamu

C++：对，不好。Java 不就是学的这一套么
Go ，Rust：对，不好。Go 就不说了它缺的也不止这一个； Rust 这点没少被人吐槽，经常有人问“如何实现数据 mixin 而非只是接口 mixn”

143 天前

回复了 deplives 创建的主题 › 程序员 › javaer 是不是写啥都是一股 Java 味儿

@oamu public field 怎么会跟 property 一样呢？ property 是 OOP 的，它可以在编程时像一个 field 一样被使用，但支持封装内部实现细节和多态。public field 既不能封装细节，也不能实现多态。

Java 味最突出的地方就在这里：因为语言层对 OOP 的支持不好，所以必须搞一大堆开发约定，来在开发中模拟 OOP （此处的 OOP 还可以替换成 FP 以及其他各种范式——事实上 Java 对什么范式的支持都不好）

143 天前

回复了 deplives 创建的主题 › 程序员 › javaer 是不是写啥都是一股 Java 味儿

虽然整体上我赞同标题，但你贴的这个一点都不 Java 。

首先多参构造在 Java 里典型的做法是 Builder 模式，而不是全塞构造函数。其次就算是 Builder ，也没人会写 100 个参数的 Builder……肯定会拆成不同类型分级构造的。

另外你这里完全没有 getter/setter 相关的内容。

143 天前

回复了 jdz 创建的主题 › 程序员 › 除了 claude, 各位还另外主要使用哪个大模型

@jdz
我说的都是 API……免费的 API 效果太差了

我们有免费的 deepseek-r1 可以用，内部部署的没有数据安全问题，用起来没有负担。当然，即使是个人用，deepseek 也算是效果不错的 API 里比较便宜的一档了。

143 天前

回复了 jdz 创建的主题 › 程序员 › 除了 claude, 各位还另外主要使用哪个大模型

困难问题主用 claude ，一些零碎的、不太困难的问题用 deepseek-r1+联网，一些对不对都无所谓有个答案就行的，用豆包。

原因很简单，r1 便宜量大，豆包响应速度快。

144 天前

回复了 xtx 创建的主题 › 杭州 › 在上海开车习惯了，去杭州开的好别扭。

深圳没去过，上海的交通确实在我去过的地方里断档领先。

另外吐槽一下，虽然杭州的交通很糟糕，但杭州的交通秩序在全国来看还算是好的

145 天前

回复了 drymonfidelia 创建的主题 › 程序员 › 看到今天群里有人讨论微软用 Go 重写 TypeScript 编译器，为什么不是用他们自家的 C#？ C#在大部分 benchmark 项中性能都远超 Go， TypeScript 编译也不是在浏览器进行，不用考虑编译器体积

@lesismal

> 底层的问题
底层部分是原文内容。开发者特别强调了他需要 Go 的底层能力——事实上性能提升也多半来自于此。把工程从高抽象层次的实现改到 native 语言，天然就会获得巨大幅度的性能提升。

> 但是哪个其他语言的缺点少而且优点又像 Go 这么大呢？
Go 的优点在各种语言中并不算特别突出，缺点比 Go 少的语言更是数不胜数。

如果你非要我提一门这样的语言出来，那底层语言我提名 C ，几乎完美无缺的语言，它在整个编程体系重要到它的缺点都不再是缺点。

145 天前

@lesismal
你看你又在这里扯这些没边的了，讨论就实打实讨论具体的问题，不用说这些没用的。

难道你以为就你一个人写过十几门语言么？对能独当一面的开发者来说，这都是最基本的好吧。

145 天前

@lesismal
> 支持和好用是两码事
这就是为什么我说 Go 支持底层操作之类的只是特点而不是优点。

Go 的底层操作并算不上很好用，性能也有很大优化空间。我知道它是权衡利弊之后做成这样子，但在编译器这个领域，它在权衡中舍弃的那些东西还是挺重要的。

Go 的缺点大家都说过很多了我也懒得说了……现在不是别人没正视 Go 的优点，而是你没正视 Go 的缺点。

145 天前

@lesismal 事实上，里面提到的 Go 的优点就是一条：并发编程支持好。

其它的都只能说是“特点”。比如本身支持底层操作（底层语言不支持底层操作这像话吗？），有 GC ，编程范式和 tsc 原有的实现方式接近等等。

当然，真说起来，说 JS 和 Go 像确实也没那么贴近事实，更贴近事实的是：Go 和 tsc 里使用的那一部分 ts 语法子集（接近于带 typehint 、不怎么玩 prototype 等花活的 js ）很像。

你喜欢 Go 的心情我能理解，但自始至终你都没说出什么 Go 什么优点来，这实在有点难绷……

145 天前

@lesismal 事实上，我回帖的时候看错了帖子，我说的“主楼”就是你贴的这个链接。

所以我想应该是我需要建议你仔细看看隔壁帖子。它说的就是我总结的这个意思。

145 天前

@redbule 恕我直言，我看了三遍你的回复，感觉你想表达的意思是：tsc 用了什么写法，那其它的写法一定都不行？

这话你自己觉得说得通么？

145 天前

@redbule OOP 其实没啥问题，有问题的是 Java 这种对 OOP 支持不好，又非要求开发者用 OOP 的规范去写的语言。

145 天前

@lesismal 我想主楼已经说得很清楚了，选用 Go 不是因为 Go 多好，而是因为 Go 最像 Javascript 。

基于这个案例，你其实可以把“Go 是否是一门设计优秀的语言”这个问题近似转换成：“Javascript 是一门设计很优秀的语言吗？”

我想后者比前者的争议小多了。

145 天前

回复了 iflint 创建的主题 › 程序员 › 求问某宝上面的 Claude 3.7 中转 api 靠谱吗？

openrouter 各种 API 用了几十刀了，感觉还是比较稳的。就是 MCP 的支持没有 claude 官方好，只能用用 function calling

145 天前