simon.crick (9/27/2013)
L' Eomot Inversé (9/26/2013)
The idea that abstraction is a bad idea is just plain crazy. Abstraction is one of the main tools for reducing a problem into multiple smaller parts. Simple advanced programming concepts like reduction, function mapping, and unification are going to cause far less damage that hideous primitve complexity like C++'s Friend concept.Abstraction is good when used appropriately, but all too often I find myself debugging a rediculously simple piece of logic that could have been written in 10 lines of code that someone has somehow turned into 1000 lines of services, factories, handlers, delegates, extensions, overrides and god knows what else. I trace it through the 17 layers of junk only to find that it has done "x = a + b" instead of "x = a * b".
I couldn't agree more. In fact one of the things I really dislike about C++ is the way that sort of idiocy is encouraged in the C++ world. I've no particular objection to template libraries, factories, post offices, services, and so on but I have an intense dislike of their misuse, which appears to be much more common than sensible use of them; and certainly overuse implies misuse.
Such elementary bugs would never occur if the logic was not obscured by vast amounts of unnecessary abstraction.
I dont regard that sort of misuse of tools abstraction, I call it stupidity. The purpose of abstraction is to simplify, to reduce complexity, to make understanding easier. For example using STL iteraters to loop over the numbers from 1 to 7 instead of a simple C-style loop is not abstraction, it's obfuscation, because it makes the code harder to unerstand, not easier. Using prolog for a task which requires unification instead of reinventing the wheel in C++ is abstraction - because implementing unification in C++ is probably going to be a nightmare, whereas in prolog unification happens behind the scenes so you've abstracted away all the detail of its implementation (that's why we have logic programming languages - because they can do serious unification and constraint resolution without asking us to implement it in a language not designed for it). Using prolog for a task that doesn't require unification is not abstraction, it's just idiocy.
This is not directly the fault of the programming language, as programmers do not have to use these techniques, but the fact that so much emphasis is placed on learning "advanced" programming concepts seems to make a lot of new programmers think they should be using the advanced concepts all the time.
Yes, that's often true. But I can't understand anyone who thinks that. Surely anyone who has been taught to programme anything in whatever language (except perhaps C++ or Java) knows that you pick the tools and off-the-shelf components that will give you the easiest design, programming, testing, integration, validation, rollout and support task? If they haven't been made to understand that, they surely shouldn't be allowed to do anything except under very close supervision until they have learnt to understand it, because letting a developer ignore the impact of what he does on any part of that chain is giving him carte blanche to write unusable rubbish. Anyway, in some cases it is the fault of the programming language (or the development system or the available components/libraries for that language) - for example you probably can't write anything useful in Java without using a lot of stuff from run-time libraries and in the case of Java it seems to be the norm for those libraries to wrap things up in such a way that it is sometimes well nigh impossible to understand what they are supposed to be an abstraction of (and some, but not all, of the C++ template libraries are as bad or even worse, or were last time I looked which admittedly is a while back).
Personally, I would like to see more computer scientists working on ways to prevent unnecessary complexity, e.g. automatic compiler warnings when the amount of wrapper code exceeds some multiple of worker code.
Unfortunately it's not the computer scientists who provide the development tools, it's companies like IBM and Microsoft and Oracle and Apple and so on. Abstraction is where I don't need to know the exact details of something my program does because my development tool kit or a component I get off the shelf deals with that for me, a wrapper sometimes is and sometimes isn't. A wrapper can indeed be an abstraction (SQL Agent is a wrapper that abstracts the handling of scheduling for me, so that I don't have to worry about it, and by its job-step mechanism abstracts some mixed language programming issues for me, because I can have a job with steps using a dozen different subsystems which give me several different languages (but I've never actually written a job that used more than 3). A wrapper can also be nothing but obfuscation, something that's used because the developer thinks it's a cute thing to do.
Tom