• 迈向 Ruby 3 at 2024年01月08日
  • Rails 从入门到入门 at 2024年01月03日

    建议用数据说话

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

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

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

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

  • 建议 ruby 换吉祥物 at 2023年12月05日

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

  • 建议 ruby 换吉祥物 at 2023年12月05日

    我觉得 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_putssolargraph应该只能跳转到 Ruby 代码

  • @zw963 好像用 Crystal 用的特别多,能否来介绍一下 😁

  • 试试

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

    目前只预编译了几个平台,其他平台下只要有gccclang以及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 无法体现与数学的亲和

    就算不说schemehaskell的表达比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 不是多范式语言?要所谓地完全地接近数学思维,怎么不用mathematicamatlab

    这种论点毫无根据。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 Windowsrbenv-cn 都是在刻意增加 Accessbility.

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

  • attr_accessor 问题探讨 at 2023年03月18日
    def next
      # 加一个self,避免index被识别为局部变量 
      self.index += 1
    
      # 或者这样,右边的index会被识别为 index()
      self.index = index + 1
      fib_pro(index)
    end
    

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

  • null at 2023年03月16日

    感谢您细致的解释👍

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

  • null at 2023年03月16日

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

  • null at 2023年03月16日

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

    支持此观点,请点赞此楼

  • null at 2023年03月16日

    观点 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 界的很多东西都被重复利用给其他生态了。