There is some truth to this. However, if you define a "better language" as one which is more consistent and predictable and less buggy, that implies less time t

There is some truth to this. However, if you define a "better language" as one which is more consistent and predictable and less buggy, that implies less time to master. One thing I love about Ruby is how many methods suggest one another. For example, Enumerable collections, like arrays, have an `any?` method. It takes a test function and returns true if any of the items pass that test. [1, 2, 3, 4, 5].any? {|i| i > 4 } # true Ok, you just learned `any?`. Now, you can replace `any?` in the above with 1) `all?` - do all elements pass? 2) `one?` - does exactly one pass? 3) `none?` - do none pass? If you can remember one of those, chances are you can remember others. And if not, `myarray.methods` will remind you. That same array has a `max` method and a `min`, a `max_by` and a `min_by`. It has a `select` to get all matching items and a `reject` to get all non-matching items. Knowing one helps you remember another.[1] The key is consistency. It speeds up the learning process and makes you refer to the documentation less often. That's the advantage of choosing a good language. It reduces the very pain that the OP is worried about. ========== [1] (But wait, there's more! Any class you create, if you define `each` and `include Enumerable`, gets all these methods for free!)