What's wrong with "magic"?

Question

I'm trying to decide whether to use a Rails or a Django guru to create a web app for me. I've been recommended to use Django because it uses less "magic". From my perspective however, the "magic" of Rails seems like a good thing since it could make development more concise for my contractor resulting in fewer billable hours at my expense. I understand the advantage of Django might be greater fine-grained control but how will I know if I need this control? Is there an inherent problem with "magic"?

Answer 1

The primary problem occurs when you don't understand the magic. This can lead to anything from applications that are badly neutered all the way to sporadic, fatal crashes.

Answer 2

When using magic... to ensure understanding of one piece of the system you must understand the whole thing. Since it's difficult to determine if no magic is affecting the piece you're examining.

It's like reading a story and having the author leave out relevant plot twists, because they're repetitive.

Shazam

Answer 3

Magic often really means "using embedded assumptions to optimize performance or syntax". Of course, in well-documented code those assumptions are mentioned as explicit constraints.

Sometimes magic is wonderful, since it really cuts down on what you have to write or dramatically improves speed. But you can violate those assumptions in countless ways, and either run into unexpected errors, or worse, have unnoticeable bugs.

Answer 4

The problem with the "magic" is that it hides a lot of things from you, and IMO makes it harder to track down problems or know what to do/optimize once you start thinking "outside the box" and end up in a "dead magic zone" (i.e. part where the magic doesn't help you).

IMO this is the major problem with Ruby on Rails (and don't get me wrong, I really like Ruby on Rails); it's far too easy to get started with it, and then once you run into a snag where Rails doesn't do the work for you, or where Rails' conventions don't fit... you're pretty much screwed unless you're a Ruby guru because you can't rely on the magic anymore and because it abstracted everything from you, you have no clue how to do it the "hard way"

Answer 5

Magic obfuscates functionality. It creates behaviors implicitly instead of explicitly, such that the programmer has no need to understand how the behavior works, and more importantly, how they might go about changing it.

When a coder has a complete grasp of the code base they are working with, "magic" can be a big productivity gain. But when working with a third-party system like a web framework, which has a high degree of complexity, it may take much longer to gain that level of expertise.

Now, to the matter of who you should hire to do the job: if you are concerned about the long term ability of other programmers to understand your contractors' code, it may make sense to go with Django (it is certainly my preference). However, there are many, many Rails experts out there who can maintain your website well into the future.

The choice should come down to who among the contractors you are evaluating, a) have a proven track record, and b) you trust. A good developer will do well on either Rails or Django.

Answer 6

Well, consider a couple bits of Rails "magic": when you write a controller class, its methods have access to certain variables and certain other classes. But these variables and classes were neither defined nor imported by anything in the file of Ruby code you're looking at; Rails has done a lot of work behind the scenes to ensure they'll just be there automatically. And when you return something from a controller method, Rails makes sure the result is passed along to the appropriate template; you don't have to write any code to tell it which template to use, where to find it, etc., etc.

In other words, it's as if these things happen by "magic"; you don't have to lift a finger, they just happen for you.

By contrast, when you write a Django view, you have to import or define anything you plan to use, and you have to tell it, explicitly, which template to use and what values the template should be able to access.

Rails' developers are of the opinion that this sort of "magic" is a good thing because it makes it easier to quickly get something working, and doesn't bore you with lots of details unless you want to reach in and start overriding things.

Django's developers are of the opinion that this sort of "magic" is a bad thing because doesn't really save all that much time (a few import statements isn't a big deal in the grand scheme of things), and has the effect of hiding what's really going on, making it harder to work out how to override stuff, or harder to debug if something goes wrong.

Both of these are, of course, valid stances to take, and generally it seems that people just naturally gravitate to one or the other; those who like the "magic" congregate around Rails or frameworks which try to emulate it, those who don't congregate around Django or frameworks which try to emulate it (and, in a broader sense, these stances are somewhat stereotypical of Ruby and Python developers; Ruby developers tend to like doing things one way, Python developers tend to like doing things another way).

In the long run, it probably doesn't make a huge difference for the factor you say you're concerned with -- billable hours -- so let your developer choose whatever he or she is most comfortable with, since that's more likely to get useful results for you.

Answer 7

Magic is great until something breaks. Then, you've got to figure out how all those tricks work.

For more, do read Joel Spolsky's Law of Leaky Abtractions

Answer 8

Talking about magic, I believe Rails, Django and most, if not all frameworks are doing some kind of magic. The way they abstract things, wrap up low level services in APIs, integrate routes and controllers etc, are kind of magic for people who know little behind. I admit Rails has more magic and people can get lost sometimes. However, we should not dismiss Rails just because of that. Like I said, it is not that magic is very bad and only Rails does magic, most do. We should see that Rails is evolving very fast and its code quality gets better and it has become more and more modular. Resources around Rails are huge. Those should be taken into consideration too.