 |
|
What is it about a new computer language that turns us into Bolsheviks? It's only been about three years since we learned that C++ was going to save humanity, yet it's already being labeled the opium of the masses. My college Russian teacher spoke at least fifteen languages fluently. She'd wince when I'd accidentally insert a Spanish word into a Russian sentence because, to her, words in one language sounded better when combined with other words in the same language. But never in the many years I knew her did Madame Bogo tell me that Russian was a better language than Spanish (although she might have thought this was true). What she said was that Russian is used in different contexts than Spanish: It is used in environments where it is appropriate to speak Russian.
Now I am not advocating cultural relativism for computer languages. Higher level languages evolved from lower level languages for good reason, and most users of computers have benefited from this progress. However, C and COBOL and Fortran and, yes, even assembly language, may be the most appropriate tools for use in some situations for years to come. The flood of introductory Java books continues unabated. Most of them are perfectly acceptable for their kind. However, if their authors would consume fewer trees in bashing C++, these books might be even more believable. Consider the following slam from Michael Daconta in Java Programming for C/C++ Programmers:
"Since Java is not preprocessed, there is no direct correlation for the assert macro. It is also debatable whether it is needed at all in an object-oriented language that supports encapsulation and exception handling. There is no reason to sprinkle your code with assertions about the values of variables because data members of properly implemented objects are always in a stable state." -- Page 70
Well, excuse me! I read this paragraph, thought about it for about five seconds, then went back to the C++ program I was working on and added about fifty asserts. Just because a variable that was declared as an int contains an integer value does not mean that the value it contains is within the range I, the programmer, expected it to be in. If, during testing, I can detect that the variable is out of the range I expected it to be in, I can fix whatever problem it was that caused the variable to go out of range. If I can't detect it, I won't fix it, and, frankly, as testing cycles get shorter and shorter, the fewer tools I have for detecting problems, the fewer problems will be detected. Not only that, but by putting in an assert, I let programmers who may read my code after I am gone know what I was expecting, so if they cause a problem, they can more easily find out about it. Only perfect programmers (and I've met very few of these) can create variables, object-oriented or otherwise, that never contain values that surprise them. Perhaps Mr. Daconta is one of these perfect programmers. The rest of us will undoubtedly miss having asserts as part of our programming language (and it seems unlikely that asserts won't get added back into Java).
Which is not to say that Java is an unappealing programming language or that Java Programming for C/C++ Programmers is not a valuable book. It's just that everything about Java is not great and everything about C++ is not terrible. Aside from his occasionally over-zealous evangelism for the Java language, Daconta is a good teacher. In fact, Chapter 3, Comparing Java to C++, in which many of these partisan swipes at C++ occur, should prove an excellent resource for those C++ programmers who are not put off by Daconta's chauvinism.
Daconta's prose is pleasantly blunt and matter-of-fact without being boring. Throughout, he avoids both cuteness and over-enthusiasm, although he makes it clear that he believes strongly in Java. Daconta obviously knows the history of C and C++ quite well. As I read his explanations of how Java diverges from them, I was reminded of quite a bit of arcana about C and C++ as I learned more about Java. Daconta's examples are nice, too. They are fairly long, so you really do have to read them to follow his explanations. However, many of them also seem like code that one might eventually want to re-use in a real program.
Of particular interest were Daconta's excellent discussion of multi-threading in Chapter 5 and of Java's Abstract Window Toolkit in Chapter 6. The examples provided in the AWT chapter highlight the distinctions between the states of graphical objects and very clearly and in a step-by-step manner show how to manipulate them.
Chapter 2, in which Daconta attempts to convey to C programmers all they might need to know to program in Java, is less successful. Reading Michael Daconta's valiant effort to get C programmers to jump the gulch between linear and object-oriented programming made me wish that he had written two different books -- one for C programmers and one for C++ programmers. Although Java looks deceptively like C, Java is so unlike C that it is unfair to expect a C programmer to get there from here, with just a one-chapter summary, even though Daconta's is a pretty good and thorough summary.
One important issue that is never discussed in this book is the ability to port from C++ to Java and to call legacy code written in C or C++ from Java. Many C++ shops have huge libraries of debugged code that they will be loathe to lose as they migrate to yet another programming language. In fact, one of the major selling points of C++ over other, more object-oriented (Bolsheviks would say, "better") programming languages, was that it allowed C programmers to re-use existing code as they migrated to C++.
Java does provide the ability to call "native" functions originally written in C and other earlier languages via its Java Native Interface. The question is: how viable will the JNI prove for shops with large bodies of existing code, especially C and C++ shops accustomed to being able to call these functions easily as they migrate. If large portions of legacy code will need to be abandoned because Java just won't interface with it smoothly, then Daconta needs to come out and tell C++ programmers this bad news. (Actually, programmers probably won't mind at all. It's their managers whose schedules will be adversely affected.) There might be some excuse for books that discuss Java not in the context of other languages, to ignore this important issue. But in a book targeted at C and C++ programmers, programmers accustomed to calling libraries of Fortran, Pascal, C and assembly language code at will, failing to discuss this important topic is a serious omission.
C++ programmers who are interested in learning Java will no doubt find this book helpful. Programmers used to linear programming environments, C programmers in particular, would be better served by a beginning Java book, or by learning C++ first.
-- Emily Berk (armadill@ix.netcom.com)
-- From Java for C/C++ Programmers, pages 245-246
| Readability |
|
| Originality |
|
| Organization |
|
| Accuracy |
|
| Consistency |
|
| Depth |
|
| Timeliness |
|
| Editing |
|
| Design |
|
| Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.