Learning Rails isn't easy easy. Once you get the hang of it, it's comfortable, but it takes some time and there's a moderate learning curve to really internalize everything that's going on. You also have to learn how to use major gems, including their syntax. The Ruby language itself is pretty nice, though.
The article focuses a lot on testing frameworks in Rails, which I haven't yet used myself, so maybe that's why I haven't been so confused.
> I basically had to go back and reread the entire tutorial and had to deduce what was actually going on. I eventually figured it out, but by that time I had spent a LOT of time on it.
Magic takes time to get used to, but it's nice once you grok the main idea. Being more explicit might make the code more immediately understandable, but once you understand what's going on, the magic acts as a mental shorthand to summarize the process and leave out the boilerplate. That's how I see things, anyway.
I'd say Rails is easy to use (once you know it), but not that easy to learn.
It's better to learn to rails first without writing tests. It's difficult learn rails and do TDD at the same time. It's even best to avoid cucumber entirely.
In the past I've had plenty of discussions on HN about how awful and unintuitive Ruby's syntax is [1] [2].
I've always been at a loss as to why anyone would bother learning Ruby when Python is a hundred times easier to understand and basically does the same things.
Ruby DSLs can be incredibly concise and expressive. There is a lot of meaning behind the ~7 lines of actual code that the author is complaining about, so yes, it will be difficult to immediately understand.
The abstraction-of-abstractions Ruby provides is different than any other language that my limited experience includes, so I understand why it's a turn-off to some people. I think the article, though, is also describing (more or less) what many people love about Ruby.
I'd be interested to know what "less magical" things the author went on to pick up within less than a week to become more productive. CakePHP, Yii, Symfony 2? It seems a little bit too convenient to leave this part out.
I've tried a number of different frameworks, but despite having the same experience with Hartl's book, Rails has been the easiest for me all round. The amount of resources available to learn and find support are unparalleled.
What use somebody's thoughts are about the first time they read a piece of code 'without any context' is beyond me.
As a Ruby/RoR noob and Python/JS slightly-better-than-noob, I felt a flicker of recognition reading this. One of my bigger WTF? moments going through that Hartl book recently (which I enjoyed and found very helpful) was, to adapt the author's example (excuse the half remembered syntax)
let(:burger) { Burger.new }
expect(burger.sauce).to .....
Where'd the bloody colon go? I said let(:burger), not let(burger). What happened to my burger? I'm most comfortable with Python, I should say, but I still think that's rather confusing wherever you come from. When I let something represent an object, I expect it to be that something, not a slightly different something. (Beginner-level tutorials on Ruby/Rails, generally, tend to glide neatly over what symbols are - which doesn't help, although it's perfectly googlable.)
Generally with these Ruby DSLs I have the problem that it's 'read-only code': the more they try to look like natural language, the more fiddly it is to write. is it "should not_have" or "should_not have"? I don't know, and nothing I know about the natural English it's supposed to resemble will tell me where the underscore goes, or what bit of the overall statement should be in parentheses. It's far less intuitive than just writing run-of-the-mill code. I suppose it's fine, once you're used to it. And I count myself among those who pine for a Python RSpec, so whatever.
7 comments
[ 2.8 ms ] story [ 22.8 ms ] threadThe article focuses a lot on testing frameworks in Rails, which I haven't yet used myself, so maybe that's why I haven't been so confused.
> I basically had to go back and reread the entire tutorial and had to deduce what was actually going on. I eventually figured it out, but by that time I had spent a LOT of time on it.
Magic takes time to get used to, but it's nice once you grok the main idea. Being more explicit might make the code more immediately understandable, but once you understand what's going on, the magic acts as a mental shorthand to summarize the process and leave out the boilerplate. That's how I see things, anyway.
I'd say Rails is easy to use (once you know it), but not that easy to learn.
I've always been at a loss as to why anyone would bother learning Ruby when Python is a hundred times easier to understand and basically does the same things.
[1] https://news.ycombinator.com/item?id=5159024
[2] https://news.ycombinator.com/item?id=5872899
I've tried a number of different frameworks, but despite having the same experience with Hartl's book, Rails has been the easiest for me all round. The amount of resources available to learn and find support are unparalleled.
What use somebody's thoughts are about the first time they read a piece of code 'without any context' is beyond me.
let(:burger) { Burger.new }
expect(burger.sauce).to .....
Where'd the bloody colon go? I said let(:burger), not let(burger). What happened to my burger? I'm most comfortable with Python, I should say, but I still think that's rather confusing wherever you come from. When I let something represent an object, I expect it to be that something, not a slightly different something. (Beginner-level tutorials on Ruby/Rails, generally, tend to glide neatly over what symbols are - which doesn't help, although it's perfectly googlable.)
Generally with these Ruby DSLs I have the problem that it's 'read-only code': the more they try to look like natural language, the more fiddly it is to write. is it "should not_have" or "should_not have"? I don't know, and nothing I know about the natural English it's supposed to resemble will tell me where the underscore goes, or what bit of the overall statement should be in parentheses. It's far less intuitive than just writing run-of-the-mill code. I suppose it's fine, once you're used to it. And I count myself among those who pine for a Python RSpec, so whatever.