[glossyscr]

> Too much magic happening everywhere, a gazillion of built-in methods, weird shit happening all over the place

Couldn't agree more on this. Magic is good if you understand the underlying stuff but if you don't and you are once offtrack you are lost. Maybe it's also a matter of taste. However the hype and traction DHH could build when RoR started was quite impressive.

[jshen]

I think this is wrong. Nearly all of us build on top of things we don't understand. I don't understand the physics of a harddisk, or the pipelining of a CPU, or some of the low level OS functionality.

The issue is when do each of us, as individuals and/or teams, really need to understand more. And perhaps more importantly, when does it make business sense to leverage magic to get to market faster, build cheaper, or find market fit before worrying about building the most robust thing possible.

[zaphar]

I think this concern gets lost in translation sometimes. It's not that you need to understand everything but you do need to know that there is a layer underneath. And it needs to be possible to follow a trail to and through that layer to debug things. Most of the time I don't need to understand the physics of a harddisk. But I know a hard disk operates under certain pysical laws. When I encounter something happening wrong it has on occasion been useful to be able to follow the trail all the way down to that disk and debug at that level.

Ruby's freewheeling philosophy however means that even when you are the author of the code some other code might have reached in and changed something out from under you. Not only do you not know there is another layer somewhere doing stuff that impacts you you can't even reliably follow a path to find that layer and debug it. As long as everyone does everything perfectly this is a wonderful world to live in. But the first time someone breaks the rules and impacts you and you lose a week or more unnecessarily you'll understand the distaste that ruby fosters in some people.

It's more about being able to discover what you need to know that it is possessing full knowledge of everything you need to know.

[mhink]

> Most of the time I don't need to understand the physics of a harddisk. But I know a hard disk operates under certain physical laws. When I encounter something happening wrong it has on occasion been useful to be able to follow the trail all the way down to that disk and debug at that level.

I'm not entirely sure how a filesystem works under the hood (let alone the physical media it's on), despite interacting heavily with one every day. A bug involving a hard disk would be incredibly opaque to debug, from my perspective. I suspect that you find it easy, because you've spent the time developing an understanding of the system.

> Not only do you not know there is another layer somewhere doing stuff that impacts you you can't even reliably follow a path to find that layer and debug it.

And this is where our roles are reversed! I would have little trouble following that path, all the way down into C if needed- because I've spent plenty of time understanding the system.

The problems you describe are problems anyone would have with an unfamiliar system, and it's not Ruby's fault.

[bpchaps]

>The problems you describe are problems anyone would have with an unfamiliar system, and it's not Ruby's fault.

Way to reduce what he's saying into the classic, "He can't be depressed! There's starving kids in Africa dying!". You've taken his /observations/, misplaced the usefulness of those observations, and then reduced them into some absurd argument that he's not actually making.

Accessibility to the unfamiliar access goes wonders and reduces the "magic" feel. If ruby doesn't have that sort of accessibility, then it IS Ruby's fault. If that's what Ruby actually wants, that's fine - but holy crap, it's this sort of mentality that completely fucks over usability.

[jevgeni]

Exactly.

I actually like Ruby, but hate RoR, because of a very lacking sense of control, unless you are very deep into it. You have absolutely zero feeling for what it OK and what's not OK to do with so much implicit magic behind the scenes. And that's debilitating.

My interaction with RoR can be boiled down to this exaggerated dialog:

- Here, write your code in this pattern and it will work.

- And if I change it like this?

- No it won't work.

- But why?

- It's an opinionated framework. It's the opinion of some Very Smart People(tm).

- But this is my work. Why can't I do it the way I want?

- Because you are dumb. And your dog is dumb. You haven't grokked it. You aren't a hacker. Neither is your dog. Where are your hoodie and Nike Airs?

[Eridrus]

> I don't understand the physics of a harddisk, or the pipelining of a CPU, or some of the low level OS functionality.

I think the key difference is that you don't need to know how that works. I think there's a question of how leaky the abstraction is and how often you need to look behind the curtain.

[goldbrick]

Tons of people and use cases never need to delve into the implementation to get a lot of mileage out of Rails. I get a lot of work as a Rails consultant and most of the real pain I see is caused by people doing stuff like implementing their own ORM with an ActiveRecord-ish interface, or writing their own caching logic implemented as a mixin for ActiveRecord.

[jldugger]

> I think this is wrong. Nearly all of us build on top of things we don't understand. I don't understand the physics of a harddisk, or the pipelining of a CPU, or some of the low level OS functionality.

There's probably a SE paper somewhere stating this formally, but I figure well done implementations on top of abstractions only need to reference one layer down. It might be okay to inspect the state the layer below for performance reasons, but no further.

That means that a well done Rails app might want to inquire about the state of HTTP, but shouldn't inquire about IP addresses. And it might want to know about indexes on its databases, but not disk caching policies or i/o schedulers.

So the case of "too much magic" is not to become used to the discomfort of not understanding how underlying abstractions work, nor is it to stop using them. Instead you want to choose dependencies with well documented abstractions, implemented such that you can inspect if you need to.

This has nothing to do with Rails specifically. I see plenty of coworkers who dislike Django's large set of features, as too much bloat, or too much magic they don't understand. Instead of reading documentation, and becoming expert in Django's abstractions, they spin up Flask apps, slowly reinventing the wheels, but maybe not quite as round.

[pbreit]

There's a huge difference between lack of understanding being irrelevant (hard drive) and lack of understanding being a blocker (framework).

[hueving]

So you're saying that you have to understand all of the magic rails does before it should be adopted for anything?

[pbreit]

No. For example, on rails if I make a typo creating a table, I delete my whole project and start over from scratch. I have not been able to figure out how to edit the name of field. That's an impediment.

[prophetjohn]

A very quick Google search for "rails rename column" will show that there's a method called "rename_column"

You can even search for "rails typo in migration" and the first result is a stack overflow post suggesting and explaining how to roll back the migration so you can edit it

[rosser]

And this sort of thing is exactly why there was a satire site article titled "Computer Programming to be Officially Renamed 'Googling Stackoverflow'" the other day.

[pbreit]

I did a lot of Googling and tried a few things and still seemed to find it easier to start over.

[hvidgaard]

Sort of, but I'd rephrase it. I don't need to understand how a harddrive or SSD actually works, I just need a consistent and well documented abstraction.

[spoiler]

But Rails (and Ruby) do offer that. I agree that there's a lot of it, but it is there. Its abstractions are consistent, and Rails is generally well documented.

[hvidgaard]

I don't know Rails enough to really comment on that, but if it takes 1 years to learn it all, I'd say it fails my definition of concise and comprehensible. It should fit in a single volume book that I can read in the evening over the course of a week.

That said, I don't have a problem with frameworks that are larger. Hell, I'm a .Net dev by day myself and that certainly doesn't meet that requirement. I just don't find it elegant.

[mmanfrin]

You understand the underlying stuff after working with rails -- the complaint of Magic comes from (I believe) the fact that Rails is very easy to approach compared to other languages, so many people are able to create a lot with comparatively less understanding of the framework, so when things work or break, they are less likely to know the root cause/reason and blame it on 'magic'.