@iBug

感谢 。已添加，见 https://github.com/RubyMetric/chsrc/issues/64

https://github.com/RubyMetric/rbenv-cn

建议用数据说话

试试 https://gitee.com/RubyMetric/rbenv-cn

另外，中标麒麟是啥时候的产品，现在还在开发吗？似乎现在他们主推银河麒麟啊。

编程语言比自然语言要好学的多，因为现在主流编程语言全都基于英语。

自然语言远比编程语言要复杂得多。德语和英语同属日耳曼语族，因此学习起来困难并不是那么多。但是你如果要学习其他自然语言，比如巴斯克语，威尔士语，藏语等等，你就会发现异常困难。

@kevinyu 所以说它失败啊，压根没啥人用这个，很多人都不眼熟

我觉得 ruby 的名字已经决定了 logo，

1. 用一个朴素的，图如其名的红宝石，就像代码一样，具有优秀的可读性 —— 建立起了直接的关联，而不需刻意解释 —— 看到红宝石就知道是 ruby
2. 刻意的拟人/动物化，实际上会形成拜物教
3. 程序就像一块普通的石头，需要程序员细细雕琢打磨成红宝石，这个隐喻比动物要好得多
4. 不是所有人都喜欢同一种动物，比如我对 Python 的蛇就无感，有的人就很喜欢，众口难调，不如非生物
5. 动物化图标有的比较成功，有的很失败。成功的比如 Perl，Go，让人印象深刻；很糟糕的也有，比如 Java，Kotlin. 还有的比较中规中矩，比如 PHP 的大象。

补充一下：咱们似乎把 logo 和吉祥物搞混了。。。上面说的大部分都是语言的吉祥物。不妨把二者结合讨论吧

PS：我之前的头像是一个骆驼，就是因为我学习的第一门语言其实是 Perl

看看 Shopify 对 Ruby logo 的想象力

另外，我有一个想尝试的，但是不知道如何下手。

就是 前端去 JS 化: https://ruby-china.org/topics/43451

用 Ruby 做 GUI 程序

这个应该是咱们社区可以瞄准的一个方向，现在 https://github.com/AndyObtiva/glimmer 项目已经发展的很不错了。咱们以后很多程序，完全可以用 Ruby 的 GUI 来做，electron 那种东西，我压根不会碰。

比如 https://github.com/zim-desktop-wiki/zim-desktop-wiki 这种项目，其实完全可以用 Ruby 来做。

另外，ruby-gtk 这个绑定做的非常好，持续在更新，大家可以试着用一下，尽管能搜到的资料不是很多（而且有些比较老），但是基本上稍微修改都能跑。

@Mark24 你写的那个 vistual_call 我觉得也可以尝试 GUI 化，比生成那个图看起来更清晰。

puts 实现在 C 语言里，rb_f_puts，solargraph应该只能跳转到 Ruby 代码

@zw963 好像用 Crystal 用的特别多，能否来介绍一下 ？

试试

1. https://gitee.com/RubyMetric/chsrc
2. https://github.com/RubyMetric/chsrc

目前只预编译了几个平台，其他平台下只要有gcc或clang以及make就可以编译了，没有其他依赖。

我在西安，但是在写 C 和 Makefile，一些算法用 Ruby 快速实现和验证，然后再改成 C

已在邮件中回复。

从表面上看，这个是今年 3 月份已经修复的一个问题。请运行 rbenv update cn 更新 rbenv。

另外，你可以尝试使用 bundle exec xxx 等其他命令，看看其他命令是不是也会出现这个问题。

@mizuhashi 过了几天再看这个帖子，觉得自己有部分话言重了，言语中的确夹杂了一些间接攻击的言论。向你表示歉意，我已删去部分比较不妥的评论。

至于 python 的某些部分亲和不亲和，纯属是不同的看法，我没有必要上升到对你技术层面的质疑。

再次向你表示歉意，以及因破坏了社区友好的讨论氛围向社区各位朋友致歉。

组织代码当然要用 def，Python 有完全靠lambda组织代码完全不用 def 的项目？

https://github.com/dry-rb/dry-schema

scheme做的比python好多了。完全不是 AI 领域选择 py 的理由。再者我已经强调，核心的计算操作都是 Fortran，C++，C，Assembly 完成。一个 wrapper 无法体现与数学的亲和。

就算不说scheme，haskell的表达比python要”亲和数学“的多的多，流畅的多，而且完全开源，时间上也满足。

自始自终，我没有说ruby 是银弹，我表达的观点是python 可以干的，ruby 完全可以干。AI 选择 python 的最初原因不是技术原因，而是历史、巧合、机遇原因。

我已拉黑你，因为我现在意识到，不是楼主的问题在引战，反而是你这种不讲逻辑的评论在引战。

不，我坚定地捍卫你 在社区可以发表 Python 优于 Ruby 结论的权力，同时我也坚定地批判你 通过个人喜好原因直接推导出普适性结论 的思路。

是你在输出错误的观点，我就着你的论点逐个辩驳，你却不愿正面回答，反而用饭圈化这种字样来回应我。

你有没有看到这个帖子分类在 新手问题？你的错误言论也许导致另一个程序员放弃对 Ruby 的尝试，你的 python 在某些方面就是优秀 这种言论脱口而出，而不加任何具体例子才是 python 崇拜论的典型思维，试图以简单的 Python 优秀，所以 AI 选择 Python 来逃避。

不 at 你是因为无意冒犯。

以 thoughtbot 文章为例，

pay_tax = -> sal { sal * (1-0.4) }
subtract_benefit = -> sal { sal - 100 }

# compose
subtract_benefit_then_pay_tax = -> sal { pay_tax[subtract_benefit[sal]] }

subtract_benefit_then_pay_tax[10_000]

你可能忘了还有更自然的 []。这个 issue 根本不是一个 AI领域选择py而非ruby 的根本性原因。

@ironboxer Ruby 是在 1995 年才公开发布，而同年，numpy 项目的前身启动。这也印证了我说的，搞这个的人，压根就没用过 Ruby，也不可能在此时有机会使用 Ruby。Ruby 直到 2000 年以后才开始进入西方，这时numpy的一套生态系统已经开始完善。

归纳一下：Stroustrup 的研究基于simula是由于地理隔离，接触不到smalltalk，那么可以说 numpy 的研究基于python是由于时间 + 地理隔离，接触不到ruby.

说一种很没有意义的假设：如果是在 2005 年那些搞数学库的人去选择一个语言，他们也可能会选择 ruby，那时，就叫做numrb了。

我的以下言论可能略显无礼，但是为了防止 Rumor Creep 我必须要对上述几个错误论述做出严厉的反驳，以免持续误人子弟以及潜移默化的对看到这个帖子的人进行洗脑。

一种问题仅有一种解决方案的优势论：纯属胡说八道

每次谈到 Python 比 Ruby 的优势，就会有人搬出这套言论，看都看烦了，相当老套无理的观点。

上述错误言论：一种问题只有一种解决方案，更利于多人交流沟通。

1. 南橘北枳。.size 和 .length 互为alias 是公认的好设计。难道必须只用 size 吗？这是 包容性设计，Ruby 真正的为程序员减轻了负担。

2. 一题多解，是绝对客观普遍的现象，是自然界体现出来的一种随处可见的模式

   按 Matz 的话讲，Ruby 是一种自然的编程语言，当然应当体现出这种自然的模式。

   1. 不同的人有不同的思维模式，受制于天性（基因、性别等），受制于风俗惯例（如东西方文化的差异），本身就可以按照不同的风格做事。如果强迫所有人使用同样的解决方案，就如同要求所有人喝可口可乐，如同强迫所有人说国际语，这是极端的技术专思制维。而 Ruby 的设计，却可以接纳不同程序员不同的做事风格，这才可以吸引并接纳各种程序员。
   2. 在传统的 C 程序中，有大量程序使用位运算技巧替代乘/除/模，本质上都是同一个问题，为何刻意用不同方式？一个问题之所以存在不同的解决方案有时完全不是风格问题，而是针对某些客观条件、约束而采取的更佳的手段。一个排序为什么要有那么多算法，如果强迫大家只能使用一种排序算法，才是技术的悲哀！

   如果你说 Ruby 中一个事情有多种技巧，大多数时候是你根本不知道两种技巧产生的副作用有何不同！

Python 更接近数学思维

上述错误言论 1：python 是多範式語言，ruby 是 oo 語言，天生沒有函數，對數學的親和力差

上述错误言论 2：不得不承认，python 在某些方面就是优秀，python 更接近数学思维

Python 不是 OO 语言？Ruby 不是多范式语言？要所谓地完全地接近数学思维，怎么不用mathematica，matlab？

这种论点毫无根据。Python 作为一个 Wrapper，真正实现矩阵计算、数值计算等的是通过 Fortran，C++ 这种的语言干出来的，如果按你们的观点，那也是 Fortran 和 C++ 体现了数学思维，而不是 Python！

np.linalg.eig(E) 求矩阵特征值、向量：这个操作使用 Python，程序员自己需要写什么深不可测，玄之又玄 的数学运算过程了？体现出 Python 的亲和力了吗？

本末倒置：你在 Linux 上用 Python 写了一个操作 socket 的程序，成功运行！骄傲的告诉大家，Python 更接近 Unix 哲学——因为万物皆文件！Yay！

ruby 内置方法多余，根本不需要

1. 请举例具体哪个方法或哪个库是多余的？Python 的标准库中没有吗？
2. 到底是你自己不需要，还是大家都不需要？你代表了全社区吗？
3. C++ 第一个标准后的数十年，有多少人想要各种 feature 进入 stdlib 都进不来。直到 C++11 以后才开始一次性大批量引入。stdlib 丰富多样才是一个生机勃勃的社区语言应有的样子。

Obeservation

我认为可以划分两类基本人群来观察：

1. 本身不研究 AI 的人

   在 10~20 年前，大多数人应该都没了解过 AI。Web 成就了 Ruby，但是 Web 领域足够大，足够消耗一个人十年最青春的光阴，导致没有精力涉足 AI。

2. 研究 AI 出身的人

   这些人是领域知识的源头。他们的选择决定了该领域未来的走向。我怀疑最初选择 Python 来进行 AI 工作研究的人，压根都没有听说过或用过 Ruby，就像 Bjarne Stroustrup 身处欧洲，所以只知道同是源自欧洲的 simula，对大洋另一岸的 smalltalk 毫不知情，所以创造出了 C++ —— 死气沉沉的对象模型。

   除非让下一波技术人主动使用 Ruby，否则下一个浪潮依旧属于其它语言。所以，宣传很重要，各位不要再 偷偷摸摸 的用 Ruby 了，必须要让未来的从事各个领域技术方向的人在学生时期都能够了解、尝试 Ruby。如果其中的一两个人成为某类技术的领头人时，才有可能适当的用上 Ruby。

Solution

历史已经不可改变，唯有押注未来：即上述的，培育将 Ruby 用于其它领域的人才。而这第一步，就是增加 Ruby 的 Exposure（曝光度） 和 Accessbility（可及性、易及性）. 社区的基础设施：本论坛，gems.ruby-china.com 镜像源，各种翻译资料，还有我维护的 rbenv for Windows，rbenv-cn 都是在刻意增加 Accessbility.

这两天，我将 https://rubyinstaller.cn/ 迁移到了国内服务器（接收捐赠，请访问站点首页右下角），就是因为有人反馈 GitHub Pages 访问太慢（PC 上慢的不行，手机上根本打不开）。我不想给别人造成一种 怎么这么慢，怪不得大家说Ruby慢 的刻板印象。

def next
  # 加一个self，避免index被识别为局部变量 
  self.index += 1

  # 或者这样，右边的index会被识别为 index()
  self.index = index + 1
  fib_pro(index)
end

这个原因在于，把index =中的index放到=左边时，会直接识别为局部变量，而不会识别为方法调用。这是 Ruby“不用声明变量即可使用”导致的结果。

感谢您细致的解释

我觉得恰恰是因为你说的 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 诟病。

Snippet 2 甚至不是语法糖，而是 Ruby 常规语法。这种常规的代码都与程序员的直觉不符，是让我觉得相当吃惊的。

观点 2： Ruby3 部分语法设计不合理。Ruby 语法已经不再那么优雅，甚至部分特性有些糟糕，违反了最小惊讶原则。现代语言几乎都很方便，Ruby 仅靠语法吸引用户的能力在下降。

支持此观点，请点赞此楼

观点 1： Ruby3 语法方便、合理。Ruby 语法依然优雅，其语法的一致性、最小惊讶原则依然成立。在众多现代语言中，仍然能靠语法吸引用户。

支持此观点，请点赞此楼

反馈一下：这四五天访问 ruby-china.org 得关 ladder。

pyenv 就是从 rbenv 复刻（fork）过来的，所以同样也采取了编译的方法来安装。

实际上，如果需要这种多版本控制，一般都会采用自己编译的方式。因为，较新版本的 Ruby/Python 构建往往不会存在于任何 Linux 发行版包管理器之中，即使 Arch Linux 的打包者也没那么快能跟上（而且还经常打包的有问题）。有的时候，我们还会有回到某个旧的版本的需求，以查看是否在特定的语言版本中，代码存在问题。而这些旧版本，上游也并不会提供。

所以最好的方式，还是通过用户自己的环境直接编译源代码，这样便能够以最快速度获得最新的 Ruby/Python. 通过 rbenv/pyenv 用户可以从过去的任何版本一致跟踪到最新版本，灵活度很高。

注：现在 Windows 上使用的 pyenv-win 是从 rbenv-win 复刻（fork）出来的。后者 rbenv-win 是用 vb 写的。Ruby 界的很多东西都被重复利用给其他生态了。