I have now hit my first "wow" moment with Rails, where I actually understood why it has the following it does. It has raised some questions for me about the pedagogy of Rails, but that is not the language's fault; it is a question for the community.
Rails is fast. Mind-blowingly fast. From my cursory looks at the framework, it is immediately apparent that this was designed from the ground up to give me everything I'm going to inevitably want in a basic web application. And yet, for some reason, it isn't immediately sold that way. It's instead sold with stuff like...
"I'm not even joking when I say this, but I think some of the resources out there make it intentionally hard for non-technical people to start learning."
The above line was from a class on Rails - not a Ruby class, but a Rails class. The class was designed so that you could have no coding experience whatsoever and build an MVP, and it advertises itself as such. I think learning to code, even at the lowest level of difficulty, is a fantastic exercise to pursue. But, like most things, when something is easy to do, it is also easy to watch it go awry.
As I've said before, most of my programming experience has been with Python and webapp2, with a bit of Django thrown in as well. With webapp2, you are close to the request itself (your application requires a webapp2 RequestHandler, which makes you write the responses to GET and POST requests manually). There is no way to automate database models, so you have to hand-code that as well. That is sloooooooow, but you learn the ins and outs of a web application because eventually you'll have to dig through the requests and responses to figure out what's going on. Requests are ugly - I get that - but someone has to deal with them. And for a long time, I was dealing with them manually.
So you can imagine my joy the first time I hit rails generate scaffold. I'm going through my tutorial, and it tells me to punch this command in. It then takes me through all the files this thing has modified, and I almost leaped in the air. This Python developer just watched hours upon hours of repetitive code, abstracted away in a single command. Everything I knew I was going to have to do eventually was suddenly all perfectly prepared for me. I was exceptionally excited.
I would be curious to know how developers who have started with Ruby on Rails have adapted to other languages, because scaffold is such a powerful tool that I'd be nervous to give it to an inexperienced programmer trying to learn code. Building an MVP or hacking something together is one thing, but actually learning to be a versatile programmer is something else entirely. In one fell swoop, you've abstracted away a lot of information about how the sausage of web applications is made. You've completely skipped over that.
And yes, I am aware that this occurs in Python as well. I am guilty of writing a lot of poorly constructed programs because I should have considered the code optimization I would have learned in dealing with C. But still, learning Python has enabled me to make this jump to Ruby without too many headaches. I wonder if it would be the same going the other way.
Thoughts? Anyone who has jumped from Ruby to Python, Java, C, Haskell, etc. out there? What were your issues when making the switch?
I've been thinking for a while that there are two very different kinds of abstractions in computing. One kind hides away complexity so that you don't have to think about it—or even know about it or understand it. These kinds of abstractions need to not "leak" very often, but they're very important. The OSI model comes to mind as an example.
The other kind of abstraction, though, is for shorthand. This kind is actually harmful, or at least dangerous, if you don't have a solid understanding of the mechanics behind it. An example might be IDE's.
Many of the abstractions in Rails are just shorthand. They keep you from having to do repetitive work. They're designed for the expert first, not the newbie. Anything in there for the newbie was added on for marketing reasons, more or less, but it will probably never get in the way of the target use case—which is for the competent developer.
I'm not saying we shouldn't throw new devs right into the deep end of Rails. There's going to be pain getting up to speed, of course, but that's the case for all paths.
But if we mistake the purpose of these abstractions as being anything other than shorthand to avoid repetition, our discussion will end up going in wearisome circles.