这是一个创建于 1907 天前的主题，其中的信息可能已经有所发展或是发生改变。
用大家都熟悉的规则设计语法多好,为什么非要高一些乱七八糟的语法.
 |
201
yixiang 2019-10-10 13:22:37 +08:00
转投 rust 解君愁
|
 |
202
ArtIsPatrick 2019-10-10 13:43:00 +08:00 via iPhone
因为你学的语言还太少，比 go 语法奇葩的多了去了
|
 |
203
ruyuejun 2019-10-10 13:48:30 +08:00
在茫茫多的编程语言中，Go 的语法规范不能算是奇葩，中规中矩而已。而且现在已经有太多语言，太多稀奇古怪的约定，与其如此，不如定死，就不让你 { 换行写，觉得挺好的。
|
 |
204
cholerae 2019-10-10 13:59:01 +08:00
大部分人黑 Go，都真的很 naive。
就以这个楼里不止一层人提到的 Go 的变量声明是把类型放后面这个点为例，我随便一想就能想出来 Pascal 的变量声明也是把类型放后面的。意思是只要跟 C/C++/Java 不一样就是反人类？ Pascal 也是反人类的了？少见多怪。 |
 |
205
T3RRY 2019-10-10 14:07:00 +08:00
我觉得挺好呀
|
 |
207
jin7 2019-10-10 14:19:05 +08:00
过一段时间就习惯了.
|
 |
208
whoami9894 2019-10-10 14:54:51 +08:00 via Android  1
写了一年多，客观说说我的感受吧
1. 无泛型，不过 GO2 马上就出了 2. 包管理 go mod + goproxy 已经能满足需求了 3. 错误处理很傻 4. 类型太严格，别名互转，类型转布尔 5. 语法太单调，写着不 cool （笑，有模式匹配之类的就好了 6. 首字母代表访问权限 7. import unused package，编译的时候自己帮我删掉不就好了，好在有 goimport |
 |
209
vlrog 2019-10-10 15:05:25 +08:00
习惯成自然,甚至还会觉得有一点美
|
 |
210
dhairoot OP @ArtIsPatrick 那些奇葩的语言也没多少应用了呀
|
 |
211
stabc 2019-10-10 15:12:04 +08:00
|
 |
214
ostholz 2019-10-10 15:17:57 +08:00
转投 Swift, Crystal, Kotlin 解君愁
|
|
215
dhairoot OP @whoami9894
再补充几点,字符处理.不统一为 Unicode 底层 go tour 里面这句话也很无语: "值为 nil 的接口值 即便接口内的具体值为 nil，方法仍然会被 nil 接收者调用。 在一些语言中，这会触发一个空指针异常，但在 Go 中通常会写一些方法来优雅地处理它" 然后他的处理方式: func (t *T) M() { if t == nil { fmt.Println("<nil>") return } fmt.Println(t.S) } 依然是判断,否则还是报错.我就不懂这个优越性在哪里 |
 |
216
ChristopherWu 2019-10-10 15:26:42 +08:00
|
|
217
dhairoot OP @whoami9894 还有 gohelper 认为的协程别的语言中也都有对应的实现.Go 的 GC 算法也都是 Java 玩剩下的.
|
|
218
dhairoot OP @ChristopherWu 这种让我诧异的"优越点"在 Go 里面还有很多.
|
 |
219
araraloren 2019-10-10 15:30:06 +08:00
@cholerae 个人觉得后置无所谓，我觉得最大的问题在于没有分隔符，故意搞的不一样。。
|
 |
220
9684xtpa 2019-10-10 15:32:31 +08:00 2
java 五年，转 Go 一个多月，我来说一下我的看法
首先呢，Go 确实有它的优势，上手成本低，没有 java 那么复杂 然后我说一些我的看法 1.go 的包管理，确实一坨屎 2.go 真的不好做封装，尼玛一个 redis 的读写，工具代码都得自己再手写，没法友好的封装使用，比如 java 一个 Util 直接搞定，哪还需要 json.marshal 和 json.unmarshal 3.go 的反射机制，怎么说呢，确实因为包管理的原因，导致了反射根本不友好，说真的无法想象手写 sql，解析，提取，遍历，别和我提 gorm，单接口每秒 2w 多的 QPS 的项目，都不敢用这种的，原因是他们觉得 go 的反射性能不好 4.真的觉得，我一个简单项目，在一个封装很不错的框架上，竟然还有一堆配置的代码要写，不能直接使用一些简单配置解决 这也只是我这种初了解 Go 的人提出的一些看法，可能里面也有错的，欢迎大家指正 |
 |
222
luopengfei14 2019-10-10 16:03:40 +08:00
@ArtIsPatrick 是的，当初学 swift 时，感觉恶心的一逼，后来习惯了，也就这样，感觉这些花哨的语言过分追求简略
|
|
223
9684xtpa 2019-10-10 16:07:02 +08:00 1
@9684xtpa #220
另外还有一点，最重要的一点，特么的，所有的异常都得自己捕获和处理，一个简单的功能，得写 N 多个 if _,err = xxxxxxxxx(); err != nil { log.error() } 我相信未来哪天 GO 应该会在异常处理方面做的更好，但是至少不是现在。 |
 |
224
janxin 2019-10-10 16:22:02 +08:00
@wangxiaoaer @zhuangzhuang1988 突然看到这里，这个都是可以通过工具自动完成的，所以没遇到过这个问题...具体了解一下 goimports 这个工具，或者使用 gopls。如果是 VSCode 记得打开"source.organizeImports": true，JB 家 IDE 太贵，没用过不知道怎么设置，应该也是可以的
|
 |
225
liuguang 2019-10-10 16:32:44 +08:00
我也用了 go 语言一段时间，有一些地方挺恶心的：
- if err != nil - 没有泛型 - 没有面向对象的继承，有时候会很麻烦 - 不同包里的类型不能互相引用，只能一个引用另一个。 |
|
226
janxin 2019-10-10 16:38:59 +08:00
@liuguang 前面 3 个确实问题挺大的，第 4 个不能互相饮用的语言太多了，只能说跟很多语言一样。1、2 倒不是完全不能忍受，毕竟要是想要 1 也是有 panic/recover 方案。
说实话在没有泛型问题上的解决方案都是需要多写 /生成代码，这个就很蛋疼。没泛型要么你就写一个 generator 去解决问题，要么加反射，反射又比较麻烦，就很蛋疼... 泛型真的很有必要，interface 方案解决部分问题也不不能解决全部或者解决起来很麻烦。 |
 |
227
wangxiaoaer 2019-10-10 16:52:24 +08:00 1
@janxin #224 IDEA 家的工具的确是可以自动引入 /删除的，但这不就相当于无故创造一个问题再解决吗？
|
|
228
janxin 2019-10-10 18:16:07 +08:00
@wangxiaoaer 这个我觉得🈶️解决方案就不算是问题了，而且附带也有减少编译后程序体积的好处。这个就跟 Java 靠 IDE 生成 getter/setter 这个问题就不算问题一样
|
 |
229
parv 2019-10-10 19:03:51 +08:00 via Android
py 就很奇葩 用缩进当段落
|
 |
230
SwagXin 2019-10-10 20:39:50 +08:00
学进去你就爱上了它
|
 |
231
cmdOptionKana 2019-10-10 20:55:58 +08:00 5
Go 的主要创造者之一是 Ken Thompson，今年 76 岁了，创造 Go 的时候他也超过了 60 岁。
你知道 Unix 吗，就是他设计和实现了第一版 Unix 操作系统。此外，他还参与过正则表达式和 UTF-8 编码的设计。曾经获得过图灵奖。 就是这样一位老人家，这么老派的、从计算机原始时代走过来的老人，他在创造 Go 的时候还那么大胆地采用了很多不符合主流审美的设计，那么凶狠地大刀阔斧砍功能，大道至简，Go 有它明显的缺点也有它特殊的魅力，而你们吐槽它的每一个细节，其背后都是一种选择，有失，有得，有的放矢。 在座各位谁敢说自己达到了 Ken Thompson 十分之一的功力？我不知道你们哪来的勇气吐槽他的设计，不脸红吗？ |
 |
233
YYYeung 2019-10-10 21:09:17 +08:00
转 Swift 的，一样有 `guard let`, `if let` 咧，还有 `??`
|
 |
234
hakono 2019-10-10 21:24:49 +08:00
说真的，吐槽的都不到点上，类型后置，大括号换行什么的，说白了不过只是个适应的问题
大部分人都是类型前置语言入门的，而如果换成一个完全没接触过编程的人还觉得你一语言变量要分 int float double 实在是太恶心了呢 Go 其实一些定死的语法和风格挺好的，目的就是限制死想搞骚操作，骚语法习惯的人。 说真的我是那种觉得为了个大括号该不该换行，变量之间空几个空格这类问题吵半天的人太傻比了，Go 这样直接定死挺好的 |
 |
235
FrankHB 2019-10-10 21:33:23 +08:00 1
@cmdOptionKana 洗别的随便，偏偏要在 PL 常识上撞枪口……
跟一个连什么叫 nominal typing 这种基本概念都没有就对 type system 大言不惭的外行也能合作语言当得意作品的老人家的功力？ 要不看在他当年没管把 vector 叫 array 那么疯的份上，早当他算民科了…… |
|
236
FrankHB 2019-10-10 21:49:55 +08:00 1
@ruyuejun @hakono 不巧，大括号问题就是显然的蠢。要钦定说风格统一就得写死换行这个未必说得通的逻辑也就算了，非得选择逼人一起犯二不找打？
大括号换行党的常见主要理由是，{ 和 } 对齐能提升人解析代码的视觉上的效率，这绝大程度是和经验以及习惯无关的客观优势。 反过来呢，不换行党又是什么理由？节约垂直空间？别侮辱智商了，要节约行数你为啥不钦定 } 也不换行？嫌弃写成 }}}}}} 像 Lisp 一样丢人不够有个性？ 那咋不干脆把{}去掉呢（反正 free form 的优越性都已经不要了）？（又没脸 Py 了是吧。） ……嘛，动机上诛心，可能理由看着还是不够有说服力？那再看看效果——比如如果用户误用了{前换行，会怎么处理，强制你写对？不巧，golang 的 spec 里用的类似是 js 的插入 ; 的屑方案……于是像 switch 后的 { 要手贱换行，效果就比某些人想要的统一风格呵呵得十万八千里了。 |
|
237
cmdOptionKana 2019-10-10 22:00:28 +08:00
@FrankHB 你敢说发明 Unix 的人是差不多民科，获得图灵奖并且发明了 C 语言前身 B 语言以及目前全球流行的 Go 语言的人 PL 知识不如你，我还能说什么？张口就来。
|
 |
238
mornlight 2019-10-10 22:27:17 +08:00 1
@cmdOptionKana #231 Go 有自己的语言哲学，里面很多设计是综合考虑了之前其他语言各种问题的妥协结果。
语法 100%的向后兼容性，超高执行效率，直接编译成可执行二进制，统一的代码风格，这些在实际工程里都有重要意义。语言有自己的适用场景，没必须要多说。拉低到「这么设计是特地标新立异」的层次之后已经属于无效讨论了。 |
|
239
FrankHB 2019-10-10 22:28:55 +08:00 1
@cmdOptionKana 你都不敢去找被黑的史实在哪，都好意思提资历？何况搞 UNIX 在 PL 山头上还真是民科啊……当年不要瞎吹无名师和万行码那坨，直接把 C 和 shell 这种半生不遂的可移植 DSL 整像样了，现在哪用得着重复发明那么多一个不比一个烂的鸡肋？
另外讲道理，PL 虽然差不多算是个现在还没怎么成型的学科，但但凡现在有点存在感的理论源头，辈分可是比图灵高的（最直接的像图灵的导师一辈）；图灵自己这方面没多大建树，后来的相关议题也被人跑题岔到递归论上去了，根本对现在几个主流阵营都没影响。拿图灵奖在 PL 这方面体现存在感的当然不是没有（像 Scott、Liskov ），但如果要计较对当前设计直接能参照的影响，那么历史上几乎全是偏工程的非主流成就（某种意义上最纯粹的也就是 Hoare 拿的，可惜对主流设计影响过于间接； Milner 搞的是一坨方法论到现在还没验证怎么全的偏门 DSL ； Nygaard 和 Naur 是时泪而且有一部分就是实现上的工作； EWD 和 JB 啥的设计在长远角度看更不入流；各种程度上凭开创性设计最该拿的 McCarthy 是因为别的理由获奖的；而 Thompson 和 DMR 拿奖是因为 UNIX ），能说明啥呢？ 至于我黑的，一是 Rob Pike，具体内容是所谓 on Go interfaces 洗 golang 的设计，不懂装懂的外行问题在 LtU 就有我就不废话了；二是 DMR，把 Ken Thompson 搞的好好的 vector 愣是整成了半残 array 而让不少后来人各种凌乱。你看不懂说的啥就算了，张口就来？也是有胆色了。 |
|
240
FrankHB 2019-10-10 23:08:13 +08:00
哦 Rob Pike 那篇记错了，直接看 http://lambda-the-ultimate.org/node/4554。
虽然 on interfaces 那个回复也多少暴露出不清楚 structural typing 了。 |
|
241
hakono 2019-10-11 00:42:03 +08:00 via iPhone
@FrankHB
`说真的我是那种觉得为了个大括号该不该换行，变量之间空几个空格这类问题吵半天的人太傻比了` 看到我这句话了吗？说的就是你这类人哦。 为了个代码风格问题争浪费时间争半天，就像到底 c 下面指针应该 int *ptr 还是 int* ptr 都能浪费一堆时间吵半天一样（就像你上面打的那么多字一样） 你们开心就好 Go 直接不多给你 BB 一些地方给你限制死了，让你们这种动不动搞咸甜战争少了在这方面浪费时间的可能性，我觉得挺好 |
 |
242
blless 2019-10-11 02:20:10 +08:00 via Android
if err !=nil 我觉得挺好，强行要求他们必须处理 error 效果比乱用 throw raise try catch 之类好多了，处理完 error 程序基本不会崩
|
|
243
FrankHB 2019-10-11 02:33:41 +08:00
@hakono 还好意思定义什么叫“吵”了，啧啧。
没看到这就是单方面对自以为是的智障理解的挞伐碾压么？ 我也没说限制死就不对，但麻烦往把事情整清楚的方向限制行么？还有，明明限制得很半吊子，不要装作限制得很成功好么？ 为什么 C 下面指针应该 int *ptr 还是 int* ptr 都能浪费一堆时间吵半天？这个问题正好经了： https://github.com/FrankHB/pl-docs/blob/master/zh-CN/about-syntax.md#%E5%85%B3%E4%BA%8E%E5%8E%86%E5%8F%B2%E9%81%97%E7%95%99%E9%97%AE%E9%A2%98%E7%9A%84%E4%BE%8B%E5%AD%90 对这类只要有点知识基础，不用思考多少时间就能得到理应一边倒的答案的简单问题，居然还要反复纠结大方向——说到底无非是因为蠢：看不出蠢设计烂在哪里一目了然的蠢，无法理解应该采取什么应对而擅自逃避的蠢，没搞清来龙去脉胡乱选取了不切实际的方案自以为是认为解决了的蠢。 至于为啥需要这么多字解释？你可以认为，这是因为中文对付基础缺失而理解能力低下的用户还是比较吃力的，不得不这样罗嗦讲清楚前因后果，才能弥补先前的无知导致的沟通障碍。要是反过来认为这也能造成麻烦，那大概是一开始就没搞清楚说的问题是什么。 |
 |
244
lincanbin 2019-10-11 02:34:46 +08:00 via Android
不能因为语法不一样就觉得恶心啊，要求同存异。
如果语法一样，那干嘛还设计新语言？ |
|
245
FrankHB 2019-10-11 02:50:51 +08:00 1
@lincanbin 觉得恶心是要有理由的，不只是不一样。
另外，语法相对语义是次要的。语法完全长得一样的，语义上有点看上去不起眼的差别，在使用体验上都可以彻头彻尾的不同的语言——比如变量默认通过引用共享和变量默认保持独立（前者通常依赖 GC ）。设计新语言可以完全套用已有语言的语法而不需要标新立异。相对地，要和现有语言的语义不同的特性，足以成为设计新语言的理由。 （题外话，有的语言设计者认为自己的语言特性设计得足够和现有设计的语言显著不同，因此故意发明风格怪异的语法规则以示足够的区分；历史经验表明，这很可能是妄自尊大且效果不彰的。） |
 |
246
ppphp 2019-10-11 03:57:16 +08:00
历史经验表明，go 语言已经垄断 devops 届了，正在逐渐占领 api 后端。好语言无非是写得快跑得快，完善的运行时，语法简单符合直觉，比指针应该放在哪里重要多了。编程不懂 PL 概念真的蠢吗，那为什么世界上最聪明的人在用在做的深度学习框架还要把库写成 python 呢，随便哪个语言都比 Python 更符合数学原理哦。
|
 |
247
nnnToTnnn 2019-10-11 08:46:34 +08:00
觉得 Go 不好用就换个语言，又没有人让你用。
|
 |
248
ericls 2019-10-11 09:04:55 +08:00 via iPhone
同问 怎么克服穷 太奇怪了 为什么明明有人很有钱 为什么不给我
|
 |
249
mengzhuo 2019-10-11 09:12:30 +08:00 via iPhone
世上只有两种语言，被骂的，没人用的
|
 |
250
soeur 2019-10-11 09:18:19 +08:00 via Android
我觉得 go 语法是最舒服的。(rust 欢迎你)
|
 |
251
chai2010 2019-10-11 09:20:59 +08:00
类型前置好，比如`int* p, q;`多完美
|
 |
252
oIMOo 2019-10-11 09:31:04 +08:00
PARI/GP 了解一下 （想哭）
|
 |
253
fy1993 2019-10-11 09:35:01 +08:00
学下 scala ？
|
 |
254
Kaiv2 2019-10-11 09:35:55 +08:00
自从学了下 go，发现他就是我想要的语言
|
 |
255
buckbuckgo 2019-10-11 09:50:36 +08:00
|
 |
256
ylsc633 2019-10-11 09:53:06 +08:00
刚开始确实有点不习惯.
但大多都是 主观习惯了其他语言的规范后导致的! 然后内心开始崩溃.. 比如我从 php 转 go 的时候, 一个 json 就把我玩懵逼了... 语言应该有大的共性, 但也应该有不同的特点.. 如果千篇一律,那干嘛还重复造轮子.. 反正自从我知道了从 php 转 go 开始时那种不习惯, 我也就接受了 从 jQuery 到学习 vue, react 等 不习惯! 与其说语言.还是很多人都用的语言.. 还不如冷静下来,想想如果非用不可的话, 自己要怎么好好学吧... |
|
257
buckbuckgo 2019-10-11 10:10:39 +08:00
关于变量类型后置的争论可以看看这里: 链接发不了了，我上面发过的链接（不小心发的，怎么这么难用啊。。。）
这个答案下面整理了 Go、Kotlin、Scale、Ceylon 等语言（作者）对 前置或后置 的解释，我跟 Ceylon 的作者看法一致 |
 |
258
dinjufen 2019-10-11 10:23:46 +08:00
别争了，Go 主程支持香港，大家用 C++和 Python 吧
|
|
259
yixiang 2019-10-11 10:25:11 +08:00
@logeable 当然是说着玩的。各个语言有各自的坑。都黑 go 没泛型，可是有泛型的 rust 一个泛型声明可以写两行，看着也头疼。单纯个人也不喜欢 go 的语法，且喜欢 rust 的语法。
|
|
261
ChristopherWu 2019-10-11 10:40:42 +08:00
@FrankHB #245 大佬，我想跟你学 PL，黑尽天下吹 go 者
|
 |
262
dany813 2019-10-11 10:46:18 +08:00
我感觉 objc 语法更奇葩
|
 |
263
DefoliationM 2019-10-11 11:16:09 +08:00 via Android
go 还恶心?你是没写过 c/c++?
|
|
264
dhairoot OP @cmdOptionKana 设计者牛逼,不代表我就没有资格评价.一个食客不能评价顶级大厨做的饭好不好吃吗.
|
|
266
FrankHB 2019-10-11 11:35:06 +08:00
@ppphp PL 不一定是直接拿来编程的。其它的用法至少包括定制语言实现，以及拿来 spec 去 derive 新的语言。
虽然直接拿来写代码的用户最多，但这些人的作用也更容易被其他用户写的代码取代。语言发展得越久，这部分解决方案越成熟，这样的用户就越来越不重要。例如，内建的元编程普遍代替用户使用外部脚本编码的能力要求，仅仅是为了生成代码而掌握脚本的开发者在市场上的重要性越来越低，只会这样的技能竞争的开发者就会逐渐被市场淘汰。 而不想被语言牵着鼻子走的开发者，多少必须了解语言在用来编码以外的实用意义，其中对大多数人最明显和差不多最容易的就是评估对选型的影响，而这和理解设计非常相关。 一个好语言，实用上应该是容易满足需求的语言，这并非能通过直觉就能判定，而需要选型分析作为基础。 除此之外，所谓写得快，（只要设计得不要故意找茬）更多是语言面向的问题域决定的，解决不同问题的语言之间没多大可比性。然而不论一门语言原本面向的是什么问题域，上升到公共的通用领域，就要求语言必须容易被定制。越是通用的高级语言，这些用途的界限就越不明显，也要求越强的抽象能力和设计的一致性。 评价这样用的语言是不是够用（先不说好），要求用户需要有熟练理解不同语言设计和实现的经验，这对大部分只是满足写得快跑得快的用户来讲是非常高的门槛。对 PL 理论的理解可以降低这个门槛，因为现在已经很难彻底设计出的新的好用的机制，而基本上所谓的新语言都是堆砌已有的设计而已，这些设计很大程度上是 PL 理论中已知的（尽管理论基础仍然非常不全面）。 在这个背景下，开发者理解的所谓对语言的直觉是分档次的。有的开发者只能粗糙地认识到某个具体语言的代码写起来容易不容易（而且没写过不被坑还不知道），另一些开发者能在不写具体代码的时候光凭阅读语言的 spec 就能看出某一类语言在项目中有什么坑，高下立判。 至于实际项目为什么用看起来蠢的语言？无非是妥协。不说培养直觉的问题，光是阅读 spec 就需要投入时间，这比直接暴力试错慢得多了。只要使用的语言不是没有可用的实现（而得自己糊一个），这样的收益并不明显。对只需要用一种或者少数几种 DSL 就能大致满足需要的领域，效率显然太低了。 但这反过来也就说明，这样的领域还有更重要的本领域内部的业务问题没解决清楚，没发展能到利用通用的可编程性和自动化普遍地提升该领域问题的解决效率而已；对口味不挑的非专家，随便一个不要太反人类的语言就能基本糊弄过去了。 另外你看来有个显然的误区，认为解决问题的难度和“聪明”有关系。而从可用性来讲，大多数搞数学的还真在这方面明显不够聪明； Python 这样已经被实现出来的语言再烂也比大多数数学家平时使用的语言像样。 |
 |
267
mougua 2019-10-11 11:56:04 +08:00
语法还好，就是轮子有点少。
墙也是一个问题，不是说解决不了，而是不方便。 |
|
268
FrankHB 2019-10-11 12:03:28 +08:00 1
@buckbuckgo 我是很不理解为什么这个问题会有不成熟的理解和争论。你给的链接大体上也仍然只是说，这是习惯问题。这不算错，但是不全面。
从语法分析的角度看，如果语法严格地设计成上下文无关文法，后置和前置是对偶的，至少对最常见的几类 parser 的构造来讲不会有根本上的困难性的差异。 这个意义上，理解成习惯差异基本是准确的。 然而这里说的实际并不是前置和后置问题。关键在于，C-like 的声明符，根本上是中缀的（还不严格地上下文无关），所以导致很多对这类语言学艺不精的用户的理解问题。误以为这种设计属于类型标记的“前置”，也算是副作用之一。相关问题我在另一个回复有提过，重复一遍： github.com/FrankHB/pl-docs/blob/master/zh-CN/about-syntax.md#%E5%85%B3%E4%BA%8E%E5%8E%86%E5%8F%B2%E9%81%97%E7%95%99%E9%97%AE%E9%A2%98%E7%9A%84%E4%BE%8B%E5%AD%90 就语法设计的目的来说，无论是后置还是真正意义的类型前置的语法，都比这种夹杂中缀的设计好得多，不说简化 spec 和 parser 需要的测试用例，至少不会那么容易因为歧义恶心到人类读者。 除此之外，在语言教学上，很多人一开始就是从 C-like 语言入门而不熟悉，导致先入为主的偏见。这是这种不彻底的习惯来源的一个解释。 不过我个人很不喜欢这种编程入门姿势。须知，类型标注乃至类型本身对语言不是都个别语言设计者赏赐的嗟来之食，而是语言设计实践中后验地构造上去的。缺乏这种自然的认知可能也是形成奇葩的习惯的重要理由。 我主张更自然的做法是先拿一种不要求 explicit typing 的语言入门，一边考虑清楚为什么应该需要有类型，然后再纠结 类型标注应该怎么放的哲学问题——这要求不能太早地拿 manifest typing 的语言影响世界观以便能有效地避免误会，同时也便于之后理解如何一般地从无到有地设计类型系统。这也是我为什么建议 SICP 第一版（使用经典的 latent typing 的语言）而抵制用 C 这样的语言入门学编程的原因之一。 |
 |
269
ibcker 2019-10-11 12:56:04 +08:00
ruby 大法好
|
|
270
ppphp 2019-10-11 13:35:51 +08:00
现在谁还没用过十门八门语言的，叽里咕噜讲一堆你们不好我才好，真的非常幼稚。。。
|
 |
271
zunceng 2019-10-11 14:37:23 +08:00
|
 |
272
no1xsyzy 2019-10-11 14:49:32 +08:00
@cholerae Pascal 有个 “:”，Typescript 和 Python 都类似这个语法
对我来说，最不能忍的是竟然是 c str, a, b int 这样写，下面无论哪个不比它好？ c str, a int, b int c: str, a, b: int c str, a b int c str; a, b int |
|
275
dhairoot OP 最近看了一遍 Go tour,然后在看<用 Go 实现 Web 开发> 其中一句话笑死我了
截图: https://imgchr.com/i/Ki8NKe 另外想问为啥 go 的标准库的源码那么多没有必要的缩写,省两三个字符有什么价值.程序的可读性不是更重要吗 |
 |
278
yb2313 123 天前
五年以后, 我还是觉得恶心, rust 和 ts 和 c#都写过, 就 go 的让人觉得恶心
|
Select Language