Frank Sommers
Posts: 2642
Nickname: fsommers
Registered: Jan, 2002
|
|
Re: Kirk Pepperdine: Why Are We Still Dealing with C++ vs Java?
|
Posted: Jun 6, 2006 12:35 AM
|
|
> This idea that a programmer's general competence is
> related to the language they use is something only junior
> high students should concern themselves with.
>
> What purpose does such a debate serve other than to
> pump-up our fragile egos?
I agree that language has not that much to do with general competence. In fact, a good programmer knows several languages fairly well, and therefore can decide what language to use for a given job (provided he's given that freedom).
I'd definitely say that not only the availability of APIs, but the existence of standards-based high-level APIs and infrastructure is also important in choosing a language for a project. That's especially (or perhaps only) an issue, of course, if one were to adhere to such standards. For instance, J2EE is one such standard in Java - if you are willing to live within the bounds of that framework, you have plenty of implementations and tools that can make your work very productive. In fact, those tools can make even below-average programmers more productive, too. (Even more productive, perhaps, than an above-average programmer who refuses to use such tools because, well, he is above avarege).
Also, few applications today are written from scratch - most apps must live within some existing context, and you have to hook new stuff into that existing fabric, or implement something within a given enterprise framework. In those situations, Java has a huge advantage, because many of its standard APIs and frameworks are aimed squarely at core enterprise computing tasks.
At the moment you leave the standard path, however, the productivity of a language's APIs and frameworks are less helpful, and hence developer productivity must rely more on core language productivity features, as well as more on developer competence.
As far as performance goes, much more difference in performance can be attributed to the choice of algorithms or tools than to whether an app is written in C++ or Java. Many Java apps, because they take advantage of high-level frameworks, rely on multiple levels of indirection, and hence are far from using optimized algorithms for a given task. Many organizations are willing to live with that compromise in the name of increased developer productivity, and just throw some computing resouces to the problem.
Partly as a consequence of using such high-level frameworks, many Java developers may not be much concerned these days with core computer science issues, such as algorithmic efficiencies (or even correctness, in the case of distributed operations). When I was writing C++ and C apps, even Perl apps, I know I was much more attuned to those sorts of issues. I can even say that Java sort of "corrupted" me in that regard, because, I just rely so much on someone else's API. Writing Java code often feels like stitching together some existing framework, and the main concern of development becomes how new code will fit those frameworks, not so much what, the language can express and how to best express that. The Java language, as it is increasingly used, is becoming a glue that ties various framework elements together. Just consider the preponderance of annotations in Java EE 5. The main concern of working in that environment is not the programming language, but the bits of magic that the annotations bring about.
The other issue is that many applications nowadays must concern more with scalability than with raw performance. That's especially the case for server applications, where Java is so heavily used. In other words, instead of optimizing on performing, say, more transactions per second on a singly processor, an application can handle more transaction throughput by distributing its operations across multiple processors. That sort of renders the raw performance argument a lot less important, and instead focuses, again, on API and tools support for that sort of scalability.
Anyway, here's a question to ponder. Who's the smarter programmer: one who knows all his algorithmic theories, is able to manage pointers in his sleep, is very detail oriented and conscientious - or one that may not know all that much about computer science or even programming languages, but knows instead where to turn for the right tools to get the job done quickly and cheaply?
My take is that both are smart, in their own way, and the world needs both kinds. It's not a question of choice over one or the other in absolute terms. However, it's often a question of choice in specific contexts. And, indeed, the smartest of all is the one who can combine these sides, knowing when to use VB or Java or C++.
|
|
Previous Topic
