rainwarrior wrote:psycopathicteen wrote:C++ is so abstracted that it becomes confusing to figure out what the codes actually do.
The point of the abstraction is not to have to figure that out.
Apparently you've never had the "pleasure" of using the following things in combination: Ruby 1.8 (language), Sinatra (framework), Padrino (framework), Rack (framework), ActiveRecord (framework or something, still not sure), and MongoMapper (I can't even explain to you what this is, but it interacts with a Mongo database, just in some utterly weird way). Oh and I'll throw in Plucky, which is the database driver for MongoDB (which should make you wonder what the hell MongoMapper actually is in itself, right?).
I deal with these at work on a daily basis (it's now part of my job), and have been doing so for 2 months now. Just last week I asked a co-worker what this one particular method (function) did because I couldn't figure out how on earth to use it. His first response was "no problem, let's work on it together". He starts to try to find docs -- can't, the docs give no information about its calling arguments aside from "implicit names". So he's forced to go look at the actual source code to the framework on github. This takes a while and in the process he "gets lost" by it; there's no comments in any of this code by the way. Eventually he re-focuses and manages to determine that it actually is an abstracted/exported method from another framework. Goes to those docs -- no information. Again, github source. Source explains nothing, like before. This forces him to put me on hold for a while, and after 2-3 hours, finally comes back and explains that it actually comes from Rack, and though there's sparse documentation, this is how it works. I ask him "how would I have been able to figure that out on my own?" and his answer was "you wouldn't have been able to. I've been doing this for several years and even I had never gone and done this before".
MongoMapper is another great one. How do you feel about "abstracted" method/function names that are dynamic and not declared anywhere in the code? Say, for example,
someobject.find_by_name()? You go looking through the entire source repo to find the definition of
find_by_name but there is none. It's a mystery... until your co-worker tells you about
dynamic queries. This confuses the living fuck out of me, so he proceeds to step me through it. Still makes no sense, although my brain at this point is saying "oh god, please do not let this be some idiocy where the function name itself can just be 'variable' and there is some horrible function that matches strings as function names, like a wrapper function". After an hour or so, I am shown
this and
this. My heart sank -- my gut feeling was correct.
The above two cases are real-world situations which have happened to me. I dealt with them last week. I will also point out that at my job, in the past 9 days I have written a total of 3 lines of code. NINE DAYS, THREE LINES. While I am not a programmer by profession, do I even need to state the obvious of how this makes me feel both worthless and like I'm incapable of accomplishing something?
This is the reality of programming today -- nothing is linear, nothing makes sense, nothing is documented (correctly), and -- the best part of all -- chances are the people writing this garbage have
no idea how a computer (read: processor) actually works/behaves. It's like constant tunnel vision, where "thinking outside the box" means "creating more vague ambiguity and crazy madness". All I see are brogrammers en masse, creating utter crap in bulk and releasing it into the world for others to use. Nobody knows what's going on under the hood though.
There comes a point, and usually quickly where the abstracted design approach loses its intention (the cut-off point, if you ask me, is 3 layers. Any more and you lose sanity). The intention of the abstraction, meaning the intended design, was to allow a person to simply use a class/object without having to know anything about its innards -- except that in most cases, you really do have to know about its innards to understand either 1) what to pass the method/function, 2) how the method/function actually behaves if passed something that manipulates data, or 3) why existing code is using this particular method/function in the manner it is ("I keep seeing the person do X, then call this method, then Y right after, almost like the method has a bug in it...").
What I have learned about myself is that I am an extremely "procedure-oriented" or "linear" programmer, and this stems from the fact that I grew up programming in assembly, BASIC, Pascal, and classic ANSI C. I put "procedure-oriented" in quotes, and did not choose to use the phrase "procedural programming", because the definition of that does not really match what I'm trying to say. I don't like there being "magic bullshit" going on within a program -- it makes it very hard to debug and virtually impossible for someone new to understand what is happening. I'd been given kudos repeatedly at my last job about the (perl) programs I wrote because guys who had never looked at them before were able to understand exactly how something works from start to finish simply because I apply KISS principle "without being a dick" (smarmy perl programmers often want to show off / flex proverbial muscles by writing horribly cryptic one-liners -- I do not do this), and because I comment well (contextually and not excessive).
And don't even me started on writing specs (ex. Rspec).
So sorry to say I am in complete agreement with psycopathicteen here.
