Ruby 【投票统计】Ruby3 的部分语法对我来说已经不再优雅
Snippet 1
def get_user_profile(client)
client.get_json("/current_user") => { id: }
client.get_json("/profile", { id: }) => { nick:, bio: }
return { id:, nick:, bio: }
end
如果您不能一眼看懂这段代码，可以去搜索一下，试着独立解决。如果图省事，请直接看本文末尾的提示。
我个人觉得一旦强迫自己接受这个语法，会写起来非常简单（我可没说读起来）。但是对于还没明白这个语法的人以及新人，这简直就是灾难。Ruby3 似乎尝试去简化代码有点过头了，{x: } 对我来说真的就像是在右边缺少了什么东西，怎么看都很别扭。我不希望眼睁睁看着 Ruby 成为一个对新人来说 Perl 一般的语言。
使用=>符号以及in关键字，作为模式匹配，我个人也觉得比较奇葩。向右赋值的观念和传统的左值区别较大，会让程序员一时找不到变量。
Snippet 2
p a: 2, b: 3
# {:a=>2, :b=>3}
p {a: 2, b: 3}
# 语法错误
关于函数参数中传递 Hash，社区似乎几年前纠正过一次行为，我已经无心了解之前的状态。我只知道，现在Ruby 3.2中，我完全不能理解第一种写法为什么会传一个 Hash 进去，而第二种写法，显式写一个 Hash literal 却直接被识别为语法错误。并且，上述第一种写法，明显与关键字参数的用法冲突了，假如不是p，而是另一个程序员写的函数 func，试问 func a: 2, b:3 到底是什么含义？
以上仅代表个人观点，请理性讨论。似乎论坛没有投票功能，我在 1 楼和 2 楼统计一下：您是否觉得 Ruby3 语法优雅/合理。邀请您参与投票，以统计社区广泛且真实的看法。
Snippet1 提示：
=>用于模式匹配，=>右边的{x: }写法是模式匹配的一部分来进行赋值。而最后面的 return 语句中的{x: }不是模式匹配而是缩略写法。
观点 1： Ruby3 语法方便、合理。Ruby 语法依然优雅，其语法的一致性、最小惊讶原则依然成立。在众多现代语言中，仍然能靠语法吸引用户。
支持此观点，请点赞此楼
观点 2： Ruby3 部分语法设计不合理。Ruby 语法已经不再那么优雅，甚至部分特性有些糟糕，违反了最小惊讶原则。现代语言几乎都很方便，Ruby 仅靠语法吸引用户的能力在下降。
支持此观点，请点赞此楼
语法糖不管能再好，都不能忘了代码是写给人看的。优雅的前提：保证性能的前提下，尽量追求可读、可维护、可调式。 当然，如果公司的一个技术团队对于语法的理解有一个“共识”基础，那么在这个“共识基础上”尽量的去优化，无可厚非。
有的人喜欢把代码写的短、怪、难，来体现自己的技术。 This is the table 这句话加再多的定语、状语、宾补，它也只表达一个意思。它够简单了、占内存够少了、非常可读了。 又何必用一个不是所有人都懂的 meme 图来“优雅化”它呢
ruby 语法太灵活，导致加新语法容易冲突。然后就这样了…。具体到上面的语法情况：
- 右赋值是一种新的语法形式，感觉还好，多一种表达方式。相对右赋值，我觉得 regex 捕获赋值更看不懂，但一样是 ruby 语法一部分
- hash 缩略写法，这个应该是从 js 那边抄过来的，写起来的确方便。但是 js 不需要后面：，会更好看一点。ruby 是语法冲突的妥协产物
- 最后的调用，
p a: 2, b: 3，后面传的是 keyword 参数，被 p 按 hash 收集了（ruby3 的 keywod 参数明确和传值的 positional 参数区分开了，避免了相关参数的歧义）。加｛｝那个则是和 block 语法冲突了。需要加（）避免歧义
总的来说，ruby 的特点是多种方式做一件事，充分信任程序员，激发程序员创造力，快乐编程。语法方面的最小惊讶原则，更多体现在熟悉了语言前提下的规则一致性，正交性，而不是可读性（比如上面模式匹配和 hash 简写法就是一致的。问题 3 造成歧义那个的确是 badcase，语法太过灵活还要一致不冲突挺难的）。 可读性和优雅虽然也是 ruby 的特点，但不是靠语言保证的，而是靠激发程序员的创造力，鼓励程序员多尝试，找到优雅的表达方式，是靠程序员和社区规范来保证的。语言本身只是不要成为表达的障碍。
316786359
回复
感谢您细致的解释
我觉得恰恰是因为你说的 p( {a: 2, b: 3} ) 必须加括号来解决冲突，才导致接纳了 p a: 2, b: 3 这样在函数参数中传递 Hash 字面值的写法，似乎这也是唯一的方式。
而对于语法的一致性来说，我认为 func a: 2, b: 3 怎么讲都应该理解为关键字参数，万万不能当作 Hash. 因为，作为一个代码的阅读者，不应该对这里的函数调用情况感到迷惑，不需要知道到底是 def func(arg) 还是 def func(a:, b:)。我觉得这个点，虽然是不得已而为之，但永远会被 Rubyist 诟病。
ccmywish
回复
我认为 func a: 2, b: 3 怎么讲都应该理解为关键字参数，万万不能当作 Hash
这个取决于你 func 函数定义，如果你参数定义为 keywords，那他就理解为 kewords，否则就是 Hash。我觉得这个没什么歧义。
- Ruby 3.2 的模式匹配其实很强大，但是不怎么直观，需要熟练掌握了才敢使用，感觉很容易写出 bug
- 右赋值表达式最大的败笔在于使用了
=>这个操作符，这个本来是 Hash 里使用，表示 key value 的意思，不知道为什么又用在这个地方，表达了完全不一样的意思。
numbcoder
回复
一开始没考虑这些特性，现在再想加进去，就不得不重复利用已有的运算符，导致看起来不协调、用起来不方便。
这种做法，的确在步 Perl 的后尘，看看 Perl5 后加的 OOP 语法有多难看就知道了。
其实这也说明，语言是有生命周期的，总会有后起之秀更加适应新的时代，进而逐渐取代老的语言。
因为新语言在设计的时候没有历史包袱，当时的业界需要什么、流行什么，它就做什么，不需要瞻前顾后、畏手畏脚。
新手确实没看懂第一个，按模式匹配想了下，还算可以理解，如果懂这个语法写起来是很方便，也很符合意识流向 不爽的地方在于模式匹配的作用域直接是语句所在作用域了...主要还是右赋值的原因，反过来写就不会纠结
说明方法省去括号的情况下，大括号解析成块的优先级高呗。因为散列文字当成一个参数传过去的时候可以省略大括号，没有歧义就直接解析成传参。 因为设计者觉得块比文字更重要
作为一个隔壁的 Elixirist 表示这种语法很 Ruby（能减则减），但清晰度不敢恭维。我现在更看重清晰，因为代码大部分时候是用来读的。
Elixir 版本的例子，匹配都在左边。并且能明确的看到过程中的变量绑定：
def get_user_profile(client) do
%{id: id} = client.get_json("/current_user")
%{nick: nick, bio: bio} = client.get_json("/profile", %{id: id})
%{id: id, nick: nick, bio: bio}
end
个人感觉，如果觉得 pattern 里 %{id: id} 十分繁琐，大可学 JS 弄成 { id } 。Ruby 里面这种语法应该没有歧义。
