In a recent interview, Bjarne Stroustrup (the man behind C+) said the following::
"I think [making computer languages easier for average people] would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and under-trained."
There are a few more gems like this in his interview, most certainly worth a read. Most experienced software developers would agree with much of the above statement. I however would add that computer languages should be designed to aid/improve productivity of a trained developer. This does not mean that they are easier.
One of the greatest improvements in productivity in a team development environment is the concept of a garbage collector. This is one aspect that C++ does not provide, and hence when using C++ for a solution it is best to have developers that are familiar with this limitation. Also, managers would need to understand that the benefits of C++ come with a very well known trade-off ... developers are just not as productive. When working in a team, it is important to know that the reference to an object/structure that you have been provided is safe as long as you use it -- developers being humans make mistakes and in a dead-line constrained environment you only need a few weak developers before it starts to get rather painful.
4 comments:
aw :( What's wrong with gcroot<string>? :)
I'm not really sure who to blame for a lot of this though. Universities, for actually teaching these dumbed-down patterns you see everywhere? Companies like Sun, for coming up with so many? Who knows. All I know is that Enterprise Java type development has to be the worst for this, it's all patterns this, patterns that, and in a room of the wannabe-head-of-the-business programmers-in-suits, not a brain capable of understanding the concept of a pointer between them. Same thing with software development life cycles. Yeah, oldschool programmers will know it like the back of their hands (usually), but anyone who in this day and age insists that anything that resembles the waterfall model is 'acceptable', let alone the only thing allowed to be used, should be sacked on the spot.
The problem isn't languages so much. It's patterns and technologies. Next time you come across a masters student responsible for rolling out some enterprise system, fire them a few low-level or algorithm questions.
I'll definitely agree that C++ is often counterproductive though, with all the potential bugs and issues caused by memory leaks and mismanaged memory.
Jeff Atwood has just posted about the same thing and strangely enough, the only person I really agree with is Stroustrup. Garbage collection is not the answer (I'm not pretending it's the only suggestion, I'm just not listing all the rest), training programmers is the answer.
I've blogged before about "too many people push[ing] some area as a panacea", particularly with respect to OO and the problem here is that OO isn't enough to fully train software developers. To extend Stroustrup's analogy, you wouldn't call someone a bridge engineer (or whatever the proper name is) simply because they can place a ready made bridge into place or assemble it from prefabricated components. They should be capable of designing and building a bridge from scratch. If they never do it because of expense/time it doesn't matter. They can, so they are rewarded with a qualification.
Important concepts such as memory management shouldn't be any less important to a software developer than manually computing compound interest is to an accountant.
Garbage collection and C++ aren’t necessarily mutually exclusive – the Boehm Garbage Collector is more than adequate in many circumstances. However, most of the time there are even better approaches. The most obvious examples are the additions to the C++ standard library mandated in technical corundum 1 (TR1). These include shared_ptr, weak_ptr and scoped_ptr, which grant the appearance of garbage collection. To give some idea of how easy these tools are to use - I saw a team of eight undergraduate developers with little experience in C++ write more than 100,000 lines of code in twelve months. They had a single memory leak – a problem that was identified and fixed in minutes with a shared_ptr.
As to whether GC is necessary or required, I wouldn’t like to say. On work time I do what I’m told, but if given a choice I’d prefer to get code out late rather than having to correct problems later. The small amount of time I get to myself to write code at home is now so precious that the last thing I want to be doing is debugging memory leaks, so I write my code in a way that leaks can’t occur.
One of the biggest issues for all software development is the question of managing abstraction. For small pieces of software anything will work, but the ad hoc approach doesn’t scale. Anyone who has worked on a large scale knows that at any given level of abstraction there are only so many things you can keep in your head at once. C++ compilers and linkers provides an abundance of approaches to manage abstraction (function, classes, namespaces, files, libraries, processes, ...).
So if you have to use C++ do you want to build your own abstractions or do you want to use someone else’s? The last 5-10 years have clearly demonstrated that it’s not issues within languages that developers get frustrated with, it’s about building up the infrastructure to do their work, so now we have the .NET framework and the java API. The cost of this however is that new developers are swamped with the size of the abstraction, and thus we have situations like Paul Graham’s viaweb where companies who build from scratch make everyone else in the market look bad.
After nearly 30 years C++ is starting to look old with regard to the ready built abstraction. Personally I think this has a lot to do with market fragmentation over time, but also to a certain extent because the standards committee lacks a single driving force (Sun or Microsoft)
If I had to pick the one thing that was most wrong with C++ at the moment it would be support for multithreaded development (gprof or gcov on multithread apps anyone?). End users are pushing for software to become ever more responsive and perform better whilst maintaining a high level of robustness, we’re now at the point where the free lunch is over.
Significantly most programmers don’t even realise some of the easiest traps to fall into (for example The Double Checked Locking Pattern) . If some of the proposed changes do make their way into TR2 it’s too early to say what this will mean for C++. In some ways the forthcoming C++0x standard will be the make or break time for the language – will it live to fight another day or will too many unimplementable or undesirable features be added (much as was the case with the ’98 standard)
I'd have to disagree with Bjarne's opinion. It seems self-defeating (as a computer scientist). We can't continue to "engineer" software with our current tools and method forever. It's not sustainable. Imho making programming languages easier is an important step in increasing productivity and sustainability of software development. This does *not* imply that having easier programming languages means needing less qualifications in software engineering!
Just think about the construction analogy. If you're a civil engineer and want to build a building would you regress so far as to mine your own ore?
Making programming languages easier and at a higher level of abstraction is a natural step in Software Engineering's road to maturity. It has little to do with qualified programmers losing their jobs.
Post a Comment