V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  reus  ›  全部回复第 178 页 / 共 348 页
回复总数  6941
1 ... 174  175  176  177  178  179  180  181  182  183 ... 348  
2019-07-28 14:29:44 +08:00
回复了 liulaomo 创建的主题 Go 编程语言 一个感觉可读性比官方范型草案要高的提案
2019-07-28 13:55:42 +08:00
回复了 liulaomo 创建的主题 Go 编程语言 一个感觉可读性比官方范型草案要高的提案
用 function body 做泛型约束,就已经谈不上“可读性”了,新的 contract 提案和旧的比较,最大的不同就是泛型约束的语法不再用 function body。
2019-07-28 13:48:50 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@liulaomo 那是对“ go 生态”的驱动,我前面说的其实是对“ go 语言”本身的驱动。我挺讨厌拿“社区”来绑架官方对语言的设计的人,自己一时不适应,甚至根本未完全理解一个设计,就提出反对
2019-07-28 13:45:23 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@liulaomo 绝大部分都是水平不够,社区从来没有人能提出像这个泛型提案这种篇幅的完整设计。但就算设计好了,甚至实现了,像 dep,问题解决得不好,也同样会被官方否决。社区能参与的,也就对官方设计提提建议,或者 vendor 这种改动小的。
2019-07-28 13:19:09 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@ruimz 我点进这个主题,本来也是想有技术上的讨论,谁知道看到一些菜鸡在那里拿些鸡毛蒜皮就说什么“这么菜”,“蛇精病”,实在忍受不了这些为黑而黑的人。
2019-07-28 13:16:45 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@congeec go 有 google go, gcc go, llvm go, tiny go, gopherjs 等等实现,规范和实现不绑定
2019-07-28 13:15:10 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@ruimz 我不知道你在说什么,“ go 是社区驱动的语言”,我认为是伪命题,语言设计,除了 go team 的人,有谁参与过? go module 更是直接否定社区的 dep。try 也不是社区“驱动”,而是社区“阻止”,毫无建设性的反对。
2019-07-28 13:11:40 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@trait lookahead 从来都不是问题,问题在于时间复杂度,现在 go 语法用 lalr(1) 就能解析,O(n)就能解析,引入带歧义的语法,可能连 parser generator 都不能用了,像 C++ 一样。甚至需要引入 typename 这种纯粹是为了消除歧义的东西。

go 粉自然有傻逼,尤其是那些做培训的,本身水平就低,又整天喊“学不动”,尬吹什么大道至简。
go 黑的傻逼,不比这些 go 粉少,一看到和自己学过的东西有一点点不同,张嘴就是 ugly,为黑而黑。你跟他说技术原因,根本理解不了,根本就懒得去理解,整天想的就是怎么“黑”。
2019-07-28 12:37:05 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@stephen9357 “看不惯”不是什么理性的理由,不是什么技术上的理由,纯粹是一个人学习能力低下,适应能力低下的表现。不用 <> 是有技术上的理由的,你不能用非理性非技术的理由,去反驳一个技术性的理由。

我是觉得“社区驱动”本来就是非常搞笑的事情,你社区驱动过什么了?
2019-07-28 12:32:20 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@jhdxr parser 当然不能受累,编译快本来就是 go 的目标之一。别的语言不在乎编译速度,只是取舍不同,我可没有说过取舍不同就是傻叉,是你自己脑补的,别泼脏水啊。我可不是因为想吹 go 才这样说,纯粹是觉得有人傻逼,忍不住要吐槽啊。

所有 ML 系语言都是用 (),scala 用 [],D 用 (),Haskell 也没有 <>,为啥非得为了照顾一些连基本的学习能力都没有的人,而选择一种会带来歧义和降低编译速度的语法?

当然,如果 go team 能发现一种算法,让 <> 不需要 unbounded lookahead,我也能接受。本来就是个鸡毛蒜皮的事情,就只有菜鸡才纠结语法问题。go 连类型位置都和 C++ / java 不一样了,适应不了的人,何苦要用。
2019-07-28 12:22:38 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@pisc go 这个提案的泛型参数并不能 currying,如果泛型需要 A, B, C 三个类型,那特化时就必须一起传入,并不能 currying。所以你的说法不成立。
骗子公司,又违法,有什么好留恋的

最好曝光并举报,这种老板,该杀头
2019-07-28 02:32:08 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@GM 难道把 () 改成 <>,就降低了复杂性?泛型就是以类型作为参数,既然是参数,那放在括号里,有什么问题? T(int) 就是以 int 为参数,特化出一个新的类型。
2019-07-28 02:24:16 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@sillyousu 他可能没写过 parser 吧,根本不知道 unbounded lookahead 代表什么。


@trait 敢说提案作者菜,看来你比 Ian Lance Taylor 还牛逼?
2019-07-28 02:13:51 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@lynskylate go team 不是开发者一部分?整个编译器都是 go 写的,好不好用,他们自己不会判断啊?就你聪明。
2019-07-28 02:12:54 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@xfriday 并不能,interface 是一个类型,例如 []io.Reader,在运行期,元素可以是任意实现了 io.Reader 的类型。但假如是 []T,那元素只能是特化了的那个类型。interface 是用于运行期动态分发的。
2019-07-28 02:10:30 +08:00
回复了 dbskcnc 创建的主题 Go 编程语言 go 泛型出炉,看起来还是不错的
@trait 你可以了解一下为什么 C++会引入 typename 这个东西,你真以为<>是“对用户 simple ”?
1 ... 174  175  176  177  178  179  180  181  182  183 ... 348  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1031 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 46ms · UTC 22:28 · PVG 06:28 · LAX 15:28 · JFK 18:28
Developed with CodeLauncher
♥ Do have faith in what you're doing.