[pavlov]

> "Whimsical inventiveness is the one thing that keeps me enjoying the art of programming."

A personality difference then. Reading clever code does nothing for me. I'm much happier digging around hulking layered codebases that may look ugly but do something valuable for the user.

I agree that the cuteness of a programming language is just a matter of taste and habit. I'm not going to pretend my criticism was anything deeper than an expression of why I personally dislike having to work in Ruby.

[thekingofh]

I think there's more to it. Ruby, to me at least, seems objectively more difficult to understand intuitively when scanning the code. Maybe it's just a superficial lack of knowledge on my part, but my brain makes base assumptions on how code should work, and whenever something magical happens, it's cool, but slows down the cognitive understanding enough that it seems to me to be a net negative. There's a crossover point where verbosness becomes too much to grok as well. Maybe spending more time in the language raises the bar enough to then become massively more productive. I'm assuming this is the case with Ruby, but I've not given it enough time to make that determination. Python, on the other hand, is immediately understandable to me, and I can jump in and be productive with no previous experience in the language and just an open webpage to the documentation. To each their own, but this is a continuing question for me. The perfect example I think is Perl 6. To me, when I look at everything they're doing in Perl 6, it really does look like the next generation in languages. It's got so many good ideas and insanely helpful constructs. However I'm not so sure if the ability to do things cleverly is a benefit. I look back at Python and see how simple it is and how productive I can be in it immediately and ask myself.. what's the catch. I'd like to use these complex languages for fun's sake, but the alternative is very, very, intuitive.

[blattimwind]

> Ruby, to me at least, seems objectively more difficult to understand intuitively when scanning the code.

Reading Ruby code always reminds me a bit of trying to understand how xmonad configs work.

E.g. the Sequel example:

    require 'sequel'

Nitpick: IMHO import-operators should operate on names not strings, because they essentially are equivalent to "foo := $magic".

    DB = Sequel.sqlite # memory database, requires sqlite3

Why isn't this a function call? How would I pass options, e.g. the file name here? Why is it Sequel. here, but "sequel" above? Does "require" dump a bunch of unspecified names in my namespace?

    DB.create_table :items do
      primary_key :id
      String :name
      Float :price
    end

What kind of construct is this? Where do all these names ("primary_key", "String", "Float") come from? They were never imported. Is this like ":name => foo" but because that doesn't nest we now have ":name do ... end" for nesting dictionaries?

    items = DB[:items] # Create a dataset

?

    # Populate the table
    items.insert(:name => 'abc', :price => rand * 100)
    items.insert(:name => 'def', :price => rand * 100)
    items.insert(:name => 'ghi', :price => rand * 100)

I guess ":name => foo" is some sort of keyword argument.

    # Print out the number of records
    puts "Item count: #{items.count}"

    # Print out the average price
    puts "The average price is: #{items.avg(:price)}"

If ":name => foo" is some sort of keyword argument, then what value has "price" here?

[pkd]

I think this is just the usual lack of familiarity that you'll encounter with any language that has any non-C-like syntax.

The do...end bits are "blocks" and are the most powerful feature in Ruby, not just because of what they do but also because how they do it. Similarly for other comments.

When I first looked at Rust code it looked weird to me too but once you are familiar with the language a little bit it makes sense. The only thing special about Ruby here is that it allows you to be very terse.

[aaronbrethorst]

Reading clever code does nothing for me. I'm much happier digging around hulking layered codebases that may look ugly but do something valuable for the user.

I don't think these need to be at odds with each other. Just because code is useful doesn't mean it needs to be hard to read.

[vidarh]

What made me switch to Ruby was after I as an experiment rewrote a queuing middleware server that was about 5k lines in C, into about 500 lines of Ruby that had more functionality. It was slower, sure, but it drove CPU load from 1% to 10% of a single core before we hit disk IO limits, so it just didn't matter. What did matter was the improved maintainability of simplifying the codebase that much..

The point being that often the "hulking layered codebase" doesn't need to be.