>because as a developer, you should be thinking about these
>things. That's the kind of thing that should contain
>absolutely zero magic, the logic should be upfront and visible
No, you shouldn't be thinking about these things. Because you'll get them wrong. Are you really going to account for all security cases?
Are you really going to account for all data coercion coming to/from the db? And even if you do, why go through the pain of those cases when there's a community of thousands of other developers, some of which have probably solved it infinitely better?
Eventually, we have to get shit done. The only code that is worth something is code that serves others. Eventually we have to pick some abstractions so that we can get on with the show.
> No, you shouldn't be thinking about these things. Because you'll get them wrong.
This attitude is really pervasive in web development, and I think it's kind of bizarre. If you're building something as a developer, you need to understand what it's doing, because at some point something will break and you will have to debug it.
When you get to the point you have to debug it, are you going to want to figure out some sort of insane meta-object protocol where you can't figure out where or why a method is dispatched, at what point inputs get santized, etc., or do you want to walk down a simple function chain?
Keep in mind I'm not advocating rolling everything yourself, I'm saying if you use a library it shouldn't be treated as a black box. I'm advocating avoiding abstractions that obscure your ability to understand what's happening (what I call magic). Use a library for user authentication, for sure, but if you can't explain how it works well enough that you could replace it, you shouldn't use it.
So do you roll your own OS? Payment processing system? Web server on your own hardware?
Just because you aren't hand-coding it doesn't make it "magic" or "lazy," it makes it efficient. I'm perfectly happy to use Bootstrap for my web application's styling because they've handled most of the exact same styling problems I will have to, and quite well. I am quite confident I could replicate a lot of that functionality every time I needed to build a web app, but why would I do that when it's already been done and I can focus on other problems?
As an aside I'm curious why you think that "magic" is good for beginners. When you don't have a clue what is going on at all, you really should spend some time learning what happens when you create a user via ActiveRecord, which can easily be done if you study the log files for a bit and read the Rails documentation. Once you are comfortable with what's going on, then you can use the framework to auto-generate code for you.
It's about reading the code, and having a good mental model of what is happening. This is the point Rich Hickey tried to drive home with his talk "Simple Made Easy".
If you are a developer and haven't watched this yet, you really, really should. Very important distinction to keep in mind any time you are writing software.
Haven't read the Active Record source code, but would be interesting to find out where it falls on the "Simple vs. Easy" continuum.
> As an aside I'm curious why you think that "magic" is good for beginners.
I was referring to absolute beginners with little prior background. To them, technical documentation is a bunch of gobbly gook. For these people it's usually better to be somewhat opinionated and just tell them "there are other ways, but this is the tried and tested way and it works". A nice side effect is that they don't suffer analysis paralysis and panic attacks.
They don't know what they don't know, so it's sometimes useful to just tell them "this is the syntax to do X" (aka "magic") and gloss over the finer details. I've found that the time to unveil the magic is when they poke around under the hood, read up, and start asking questions about how things work.
>things. That's the kind of thing that should contain
>absolutely zero magic, the logic should be upfront and visible
No, you shouldn't be thinking about these things. Because you'll get them wrong. Are you really going to account for all security cases?
Are you really going to account for all data coercion coming to/from the db? And even if you do, why go through the pain of those cases when there's a community of thousands of other developers, some of which have probably solved it infinitely better?
Eventually, we have to get shit done. The only code that is worth something is code that serves others. Eventually we have to pick some abstractions so that we can get on with the show.