Hacker News Reader

Comment by jack_riminton | Hacker News Reader

This is how we learned Ruby at bootcamp. The problem was that once we got to the more complex Rails parts, the instructors didn't have the time to fully explain it so it was explained as "Magic, don't worry about it too much" which was extremely frustrating

View on HN

I believe we should really dial down the usage of the word "magic". There are some parts of Rails that feel "magical" as in "surprisingly easy to use" or "very convenient", but it's nothing like "magic that nobody understands". You can always read the actual implementation in your IDE, and Rails code is nice and readable with comments and examples. It's just as easy or difficult to reason about as other complex codebases. I don't remember myself ever hitting a wall and still not understanding what's going on two hours later.

I am with you on this. What's magical in Rails? It imports classes for you by name based on their file path, "resources" routes to one of seven methods, templates are expected to be in a directory and named based on controller name and action, it defines methods on models for you based on the column names in the database, it runs files you you put in the initializers directory. All of this stuff is convenient, gets rid of boilerplate, and isn't hard to understand.

I've been a Rails developer for half a decade now, and I wish I had the time to list all the occasions where I've just about thrown my MacBook out of the window trying to do something that Rails wasn't specifically built to do, or been shot in the foot by ActiveRecord trying to be too smart for its own good. Solving autoloading problems is always a favourite too.

I enjoy using Rails, but sometimes it's a pain in the ass, and usually because it tries to be too clever to reduce the amount of boiler platey code you need to write. In terms of code management, I'd much rather have explicit dependencies. Less `belongs_to :thing`, and more `belongs_to :thing, foreign_key: 'thing_id', klass: Thing`. Makes refactoring and code navigation so much easier.

Also, pre-Rails 5, the defaults for DB migrations and relations were trash.

Of course it no longer seems magical when you understand the implementation. The issue is understanding the application without working your way up from the inner bowels of Rails source.

Things auto running and importing themselves seems magical because no other mainstream language does that

> You can always read the actual implementation in your IDE

Doesn't Rail's use of metaprogramming mean that often there isn't a simple static implementation of a method in the source code that you can go and find?

Yes, but it just implies that you cannot rely on grepping the source code. You know the relevant "method_missing" implementation is somewhere, and you can make an educated guess as where to look for it.

I think I’m pretty well informed about Ruby metaprogramming but I still really struggle to read through the magic sometimes. I can appreciate it’s somewhat impenetrable to beginners.

Yes and it makes moving through any non-trivial rails codebase a total drag.

Yea, but the documentation of said metaprogramming is generally quite comprehensive (with some exceptions).

In fairness they've been moving away from a lot of those methods. For example the whole find_by_<attr_name> dynamic methods have been replaced with find_by(attr_name: value).

And while you can't find the method code itself, for example the generated code to access a has_many relationship, you can pretty easily find the meta programming that will generate it by following the class method name.

Agreed, rather than magic we should call it what it really is: a massive amount of introspection on the name of things creating implicit interfaces that reach across layers of the application resulting in some of the nastiest, brittlest, most highly coupled code you will ever write.

Sounds like dark magic.

same with Django

As a huge Rails fan... I wish I could refute this. ;-)

When I get a chance, I try to dig into the "magic" parts of the tools I'm using.

I've wrote a bit on this on my blog in the context of creating a (nano) web framework similar to Rails [1] and a (nano) http client library similar to requests [2].

I find this to help assure me that if I have to go one layer deep in abstraction I'd still be able to learn how it works.

[1] https://mhasbini.com/blog/lets-build-a-web-framework.html

[2] https://mhasbini.com/blog/lets-build-an-http-client.html

Realistically you generally won't have time to fully understand how most things work though.

I know, and accepting that frustration is part of becoming a developer, but there are others schools such as Lambda where you do go into more depth because its 9 months instead of 3

That's why I abandoned RoR early..

Reply on news.ycombinator.com