Letters to the editor may be sent via email to cujed@mfi.com, or via the postal service to Letters to the Editor, C/C++ Users Journal, 1601 W. 23rd St., Ste 200, Lawrence, KS 66046-2700.
PJP,
I read your article in the January 2000 issue of C/C++ User's Journal on the history and heritage of Algol, C, C++, and Java. While I certainly cannot claim the longevity or scale of experience which you can, (I have spent thousands of hours writing C and C++ code on various platforms, but I am only 20), I resonate with the sentiment you expressed in your statement, "Thus, I feel confident in opining that Java in some ways is an overreaction to the perceived problems of code portability in C."
That concisely states what I feel when the programmers from the Web department boast of the miraculous powers of Java. Perhaps I am not a "mature programmer" as described in the Editor's Forum of the same issue of CUJ, but I feel a little weakened when my pointers and typecasts are taken away, or at least buried just below my reach. I know that writing truly portable C code can be complicated, especially when a Microsoft platform is involved, but on the other hand, I have recently been porting some of my code from Windows to Linux for a personal interest historical database project, and it is beautiful how the same code does the same thing on a totally different OS. I'm not sure the difference in portability of Java and C is so great as some people seem to think.
I also find it vaguely amusing that the JVMs which provide the platform independence of Java are apparently written in C, thus borrowing the portability of C to provide portability to Java. The principle advantage I see in Java is that it is, as you described it, a child of the Internet. Anyway, thanks for expressing in a public forum the same opinions which have to me been voiceless.
Mark Aardsma
And thanks for reinforcing my point so well. — pjp
Dear PJP,
I like your writings (starting from the Software Tools days). Some questions and comments:
1. When I teach C++, I tell the students to be on the lookout for your STL book. Amazon reports the publication date as having been pushed later to December 2001 (about a year ago, it said February 1999). What's the story? Josuttis's tome looks to be strong competition. (I'm sorry to say I steer them away from The Draft Standard C++ Library unless they're interested in a well-written history.)
2. Re your CUJ January 2000 article: In 1958, work on the International Algorithmic Language (later renamed Algol) started. Jules Schwartz's dialect was Jovial (Jules' Own Version of the International Algorithmic Language). I don't have my ACM History of Programming Languages proceedings with me, so I can't check what Schwartz's affiliation was; I think he was with RAND. I'd hate to see him lose credit to some nonexistent "Joe."
3. Re your CUJ October 1999 article: I'm curious why you didn't do the small optimization Sedgewick suggested in his dissertation. Every time the recursion gets down to a number of elements below your threshhold, don't insertion sort that range immediately; just return. When the quicksort algorithm finishes, all the pivots you ever selected will be in the right place, and the elements between them will be between the right pivots, but unsorted in that area. If your threshhold is T, no element will be more that T places away from where it belongs. Insertion sorting N items with this property is O(T*N), so you can finish the job efficiently by doing one insertion sort at the end. Admittedly this saves you no more than N/T times the loop control overhead for an insertion sort, but it's simple.
David Smallberg
The STL book was the victim of several years of painful litigation that ate all my time (not to mention a lot of money and emotional energy). Since that era ended, Dinkumware has been eating most of my time, mostly due to an excess of success, I'm happy to report. But the book is nearly finished and I'm still committed to passing it off to my coauthors for finalization.
As for the Sedgewick optimization, I used to do it. I guess it just got lost in all the revisions. Thanks for pointing out the lapse. I'll pick it up in a future revision. — pjp
Dear Editor,
Out of pure interest I began reading CUJ when I was a public servant for a foreign goverment. (Programming was not part of the job.) I read it when I became a translator (French/Spanish). I read it when I became a trainee in a corporate IT program. I read it when I became a VB programmer. And I am reading it now that I have become a Java programmer. Thus, I am very glad that CUJ articles and my professional life have finally merged as some point, allowing me to not only enjoy the quality writing it provides but also to more easily apply some of the ideas that it professes.
I would also like to say that I have particularly enjoyed articles by Plauger, Saks, Schmidt, and Becker. Thanks for a good read.
Sincerely,
Thomas J. Sherlock
Maspeth NY
tj.sherlock@computer.orgGosh, maybe we ought to change our newsstand strategy, get ourselves placed in the rack next to Atlantic Monthly or The New Yorker. I hope you'll keep reading us when you start programming in C++. Thanks for the compliments. — mb
Dear CUJ,
I must take issue with Pete Becker's analysis of Java's popularity.
Becker writes, "The other aspect of Java that contributes to its appeal to beginners is that much of the Java library was designed and implemented by people who were new to object-oriented programming. They made typical beginner's mistakes, and that makes the library comfortable for beginners, because it's written the way they think."
I'm sure Becker doesn't mean that beginners prefer to work with badly designed libaries as opposed to well designed ones. These design errors are errors precisely because they make the library harder to program with. This is not a source of comfort to beginners or to experienced programmers, but a source of discomfort to all. I have experienced some of these very flaws myself. What he must mean is that beginners don't realize that these are flaws and may even learn poor design strategies from them.
I don't take issue with the design flaws that Becker identifies but I am somewhat distressed by the general tone that is being taken in this article as well as with others that have appeared lately in CUJ. It seems to me that CUJ has added an unappealing chip to its shoulder. Why is a C/C++ magazine devoting so much space to Java? And why has the coverage turned so negative? A few months ago, it looked as if you were thinking of becoming the "C/C++/Java User's Journal." Now it looks more like the "C/C++/Anti-Java User's Journal." To me, this tone is offensive and curmudgeonly.
In the past year I have made the switch from C++ to Java, so my perspectives are somewhat different than those of Becker. I like Java, precisely because, errors aside, I find it a better object-oriented environment in which to work than is C++. I used to scoff at those who said C++ needed to be made easier. Harrumph! I wasn't afraid of no steenking pointers. I knew how to delete my objects at the right time. Why did I need to be babied?
What I found when I switched is that by "encapsulating" memory management and other arcana, Java makes it possible to spend more time in the problem domain and less time in the memory-management domain. This, by the way, is exactly the same reason I used to love the STL when I programmed in C++. Encapsulating memory management in the container allows you to see the algorithms. Try doing that in traditional C code. In less than a year as a Java programmer, I have written more code that has actually been reused than in five years of C++ programming.
Is the Java library growing unwieldy? Can you name me a library that hasn't? MFC? Perl? Or even the C++ Standard? Get real! One reason that Java presents such a fat target is because it "incorporates" its libraries in a way that C++ does not. By "Java" one might mean just the compiler and no libaries at all, not even java.lang. But in practice, nobody uses the word this way.
Is this good or bad? I'm not sure. By existing without a standard library for many years, C++ ceded the ground to unofficial libraries of varying quality. If you want to talk about learning bad habits from libraries, I still get distressed at all the programmers I meet who "learned C++" by coding with the MFC library. Now there's a source of bad advice that beats anything I've seen in Java, even with all the flaws that Pete has identified. But on the down side, I will agree that Sun has rushed into production poorly designed libraries in some cases, perhaps because it's trying to do too much too fast.
I don't know where Java is ultimately headed. Like you all, I would feel better about it if Sun would allow the language to be standardized. And no, it's not perfect for every use, but it's also true that C++ with all its power has been applied to tasks where that power isn't necessary, and where Java is, in fact, as of now, the better choice. There's a reason besides hype why so much new stuff is being written in Java.
I'll continue to read CUJ because much of its content is (or should be) interesting to programmers in general. I love looking over P.J. Plauger's shoulder as he works on extending the C++ Standard, and the way he explains the tradeoffs he has to make at each turn. But guys, lose the Java chip on your shoulder. It's ugly and it doesn't ( or should I say "shouldn't") become you.
Java, like it or not, is here to stay.
Steve Cohen
Pete Becker replies:
I agree that the tone of some of CUJ's articles about Java has been critical. That's not a bad thing. Many Java writers and Java users have uncritically accepted the marketing claims made about Java. But things are changing — a year ago, articles that criticized Java rarely appeared in Java magazines; now we're seeing more of them. That reflects the increasing sophistication of Java users, who are looking for real information instead of marketing hype.
My introductory comments were not a slur on Java programmers. They were a criticism of the Java library. It is in some places badly designed, badly implemented, and badly documented. The two columns that I wrote on this subject point out some of these places.
Beginning programmers do not know how to "program correctly," and look to commercial libraries as one of their sources of examples of good programming. While some beginners may know enough to recognize bad examples, many do not. When they see bad examples they learn bad habits. I've mentioned some of these problems in newsgroup discussions, and the responses have usually indicated a lack of understanding of the underlying issue. That's a pretty good way to recognize a beginner.
I'm not absolutely convinced that Java is here to stay, but I would like it to succeed. As part of my job at Dinkumware, Ltd. I've spent the past two years implementing the Java core library and the requisite support code, including threading and garbage collection. That's not something I want to throw away. For Java to succeed, however, people must understand what it does well and what it does badly. Some parts of the Java library are done badly. Ultimately, a broader understanding of where these parts are and how the problems they pose could have been avoided will be beneficial to Java programmers and to the Java language. — pb
Mr. Briand:
I suddenly noticed that I am way behind on my reading. I felt compelled anyway to write about your comments on component-based development. Actually, I am quite surprised at the entire microcomputer development cycle since its inception. It seems to me that they are taking absolutely no lessons from the computer industry as a whole. My feeling is that a bunch of kids from high school who had learned a bit of programming are all that do any programming for the Microsoft OS.
When DSOs (Dynamic Shared Objects) were developed for Unix, they had to change the object file format to ELF to properly support it. DSOs are much like DLLs in what they do and how they operate. Part of an ELF object is a structure known as a Dynamic Structure, which provides a number of special purpose fields, including DT_SONAME, which is the name of the DSO. Convention has it that this name includes a major version number.
DSOs are usually named with the major and sometimes the minor version numbers. These correspond to the DT_SONAME in the file. The file is then symbolically linked to the library without the version number appended. When linking an executable, it links to the library without the version number, but the DT_SONAME is remembered as the required library. Thus, libc.so will be remembered as libc.so.6. When run, the executable links with libc.so.6. This allows a user to install a new version of libc.so, which will actually be a symbolic link to libc.so.7 (for example). Applications that were linked with libc.so.6 will still run and use libc.so.6 as it was not replaced on the system. There are programs that can be used to read the DT_SONAME from a particular DSO. To me, this is an example of providing what you are suggesting from a library point of view.
I find it interesting that the concept of providing version information and a form of run-time typing is fairly common for class libraries on Unix. For example, Doug Young applied your idea to the ViewKit class library, provided on Linux and SGI for X Windows. Since the entire class library comes as a package, it is possible to access three static const values that are part of VkApp (base class for all applications using ViewKit) that contain major version and minor version numbers as integers and as a string. These are known as ViewKitMajorRelease, ViewKitMinorRelease, and ViewKitReleaseString. Also, all classes are defined with a virtual method className, which returns a character string, usually the name of the class object.
Anyway, I'm just surprised that this seems to be so foreign to Microsoft Windows developers. It also surprises me that Microsoft hasn't made any effort to separate files into specialized directories. Currently, there must be a couple of hundred files in the Windows and Windows\system32 directories. It would be nice if all DLLs were in a library directory, initialization, configuration and startup files in another directory, and applications in yet another directory.
Just some thoughts with respect to your article in the October issue of C/C++ Users Journal. Thanks, and keep up the great work on a fine magazine.
Chris Carlson
Thanks for your comments. — mb
Dear PJP,
Just started reading your Dec CUJ column, and the following stopped me dead:
So here is a cute dance you can perform:
vec.swap(vector<int>(vec));No no no no no. I know it's no, because I recently made the same mistake myself in a clcm (comp.lang.cpp.moderated newsgroup) posting. As I followed up to myself:
In a reply to an earlier posting of Anders', I wrote:
vector<Widget> w; . .... // put the results of makeWidgets() // into w without copying any // Widgets w.swap(makeWidgets());This shouldn't compile, because swap takes a vector<T>&, and you can't bind a temporary (such as the result of a function call) to a reference-to-non-const. The correct statement is this:
// put the results of makeWidgets() // into w without copying any // Widgets makeWidgets().swap(w);For some reason, I always get that backwards...
I don't know about always, but it seems that you sometimes get it backwards, too :-)
Scott Meyers
P.S. — I have this vague recollection that some compilers allow the above illegal construct under the rubric of compatibility with rules long-since changed in C++.
I vaguely recall testing that statement under VC++ before putting it in print. Not a thorough enough test. Well, if Scott Meyers can make much the same mistake, I don't feel too bad. Thanks for pointing it out. — pjp
Dear Sir,
I tested the LU decomposition of the smatrix class published in Mark C. Peterson's "Manipulating Sparse Matrices" in the December issue against a simple Gauss-Jordan elimination program that I use, with the only difference being that I test the entries before multiplying. The results are that even for a "very sparse" (6,000 of 4,000,000 entries) matrix the simple Gauss-Jordan elimination works faster (more than ten times!). I thought this may interest other readers, so the program I am using is also attached. [We supply this program with the CUJ online sources on our ftp site. See ftp.mfi.com/pub/cuj/2000/1804/letters.zip or www.cuj.com. —mb]
Regards,
Guy Alfandary
alfandary@mail.comMark Peterson replies:
Guy,
You are correct. The smatrix<t> template carries a lot of overhead for storage. A dense matrix with explicit zero checking would be faster if you have the available memory, i.e. 32 MB for a 2,000 x 2,000 dense matrix vs. around 64 KB for a 6,000 element sparse matrix.
As an algorithm, LU decomposition is only somewhat slower than a straightforward Gauss-Jordan elimination, but Gauss-Jordan elimination is only an option if you have few vectors and never need a solution from that matrix again. LU decomposition works better if you need to solve for many vectors and don't know what they will all be ahead of time.
Hmmm, I've been meaning to write some code that had a better storage/performance tradeoff. Perhaps it's time for another article... — mp