Letters to the editor may be sent via email to cujed@cmp.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.
Chuck,
I thought your editorial in C/C++ Users Journal was excellent. The only thing that I would comment on is programming is not just technical expertise. I think you touched on that, but I think that most people miss that the best programmers are part technician, part artist. It takes more to craft a solution that is both technically correct and easily understood by the layman. (This you definitely touched upon.) The thing that I wish is that more “leaders” would get information like yours. They need to understand that sometimes the best way to lead is to get out of the way. I think that the best programmers are often the most frustrated. It becomes very difficult to convey an understanding, an ideology, a picture that others’ cannot see. Not that they are dullards or anything like that, just not able to see. And at times it becomes very difficult to bite your tongue and not say, “I told you so.” The passion to solve problems, and the ability to do it in an easy-to-understand manner, is pure artistry. Thank you for your article.
Thanks,
Tony Harmon
I was just reading your editorial from the December 2001 issue and I must jump on my soapbox.What every programmer should know is what are bits and bytes and what is boolean math. I am shocked at how few programmers coming out of college can write a piece of code that will take a byte and return the value of, say, the least significant three bits. My company writes peripheral diagnostic software, and we have to manipulate bits and bytes all day long, and I find I have to teach every new programmer the basics. I may think of more things, but this one is near and dear to my heart.
Mike Miller
Got my issue yesterday and read it this morning. Really appreciated your editorial on “What Every Programmer Should Know.” I would add that programmers must keep on learning throughout life. There is probably a better quote about that, but I don’t have my Bartlett’s handy. Let me know how your list grows. I would like to make a little poster of it and give to the next Java class I teach.
Thanks,
Jim Burke
Hi. I’d like permission to put either the text of, or a link to a permanent archive URL for your “Editor’s Forum: What Every Programmer Should Know” (<www.cuj.com/articles/2001/0112/0112j/0112j.htm>) on our internal Wiki. I’ve just started working as a project manager in a small IT department, and part of my job is to oversee and develop our programming staff. I’ve set up an internal Wiki (using UseModWiki; see <www.usemod.com/> if you’re interested in the concept and the software) that everyone seems to love, and I’d like to make available to them topical items such as your article.
Thanks for your consideration,
Loh
Chuck,
First off, if you really want feedback, make your email address easier to find. For example, put it right in the editorial. Second, regarding code reuse, I think it is extremely important to be able to recognize a square wheel that shouldn’t be reused. Lastly, the things that you discard so lightly look like skills that can be taught. The things you rate most highly look more like character traits that need to be built through experience, rather than taught in a classroom.
Good luck building character,
J. Edward Ellis
Hello,
I found your article in “Editor’s Forum: What Every Programmer Should Know” quite interesting.
Depending on the circumstances where the list is presented, I would add the understanding and need of a source control system to the list.
The item “readable by humans” depends very much on the knowledge of the humans you deal with, which in turn depends on the people who are likely responsible for dealing with the code.
Regards,
Marco Malva
Can you tell me how I can obtain a copy of the article “What Every Computer Scientist Should Know About Floating-point Arithmetic” that is mentioned in your Editor’s Forum in the December C/C++ Users Journal? Thanks in advance for your help with this search.
Paul Siggins
Dear Mr. Allison,
I have spent a good amount of time mulling this problem after tutoring students and mentoring junior programmers for a while. The first thing that I recommend: be explicit that you are talking about programmers only. Not software engineers. Not computer scientists. Not architects. Next recommendation: subdivide the problem. It’ll be easier for us to answer if you ask about systems programmers, application programmers, script programmers, and performance programmers (or whatever categories you care to cook up). If you really want sweeping generalizations, just look for the similarities between the different categories. I expect answers to the more manageable questions will be more interesting, though.
About your specific points, do you want knowledge base/skills or character traits? Knowledge base is more concrete. I can say that systems programmers should know binary arithmetic, hex, and basic machine architecture. Having the patience to decipher a poorly translated Korean chip spec is fuzzier. Well, good luck; I’m sure you’ll at least get a good article out of it. Too bad this wasn’t on a discussion forum, though. Cheers.
Augustus Saunders
Greetings Chuck,
My name is Javier Isassi and I’m a embedded software developer working in the aerospace industry. Here are my thoughts on what every programmer should know. Thanks for your excellent input.
[...]
At school (U.T. Austin), I was taught to program in a variety of languages: Haskell, Pascal, Ada, Assembly, C, C++. At work, I was indoctrinated in three technologies: Ada95, GNU C, GNU C++.
Today I read the Editor’s Forum from Chuck Allison on his take of what every program should know and I ponder over the same issue. But I think he talks more about attitude than knowledge, which is the aspect that troubles me.
I’m a ‘97 CS major. One of the roughest times I had at school was my class on linguistics. I still have on my cube shelf the book I once dreaded, Elements of the Theory of Computation, by Lewis & Papadimitriou — nothing to do with some cool looking Java coders talking about their Java beans and the cool GUI’s.
When I got out of school, I thought fundamental theory would take me a long way. Boy was I asking for it. Once in my first cube and in my first argument at a peer review meeting, I found that programming was not the neat clear-cut applied theories of academia. If programming was cooking, I found out that, although some went to chef schools, some learned to cook at McDonalds and some others use their great-great-great-grandmother’s recipe book. Some don’t even cook, but drive by the Black-Eyed Pea and buy their food! And they are praised for the great taste of their food!
I have my own classification for my colleagues I have run into during my career: Hard-Coders, Soft-Coders, and Latch-Key-Coders.
Hard-Coders: vi-editor, index-finger typing, “Fortran anyone?”, VAX/VT-100 terminal old timers. “STL? What’s that? A TV show?” Most of them are EE majors.
Soft-Coders: NOT EE’s, abstractionists to wide variety of degrees.
Latch-Key-Coders: An English major who stumbled with MS Visual Java and learned by heart and now he calls himself a programmer. They know the tools so well that nobody knows that they don’t know the difference between let’s say a language or a grammar. I call them latch-key programmers because the can get around on their own and prepare simple dishes.
[...]
I’m baffled when I see some institutions with CS Master Degree programs teaching XML and CORBA. Is that science? What comes next? Macromedia Flash Plug-Ins?
Not even universities agree on where to place the computer science department. Some say in natural sciences. Some say in Engineering. Is programming applied science or just a science like math or biology? An art? A trade? A hobby? Once I heard that Texas was planning on licensing the practice of software development via a certification.
So to sum up, what every programmer should know is... how to gracefully cope with it. Enough said.
Regards,
Javier Isassi
Thanks to everyone who responded to that Editor’s Forum. (I’ve responded to all personally, but there is no room here). As you can tell, I write about things that are near and dear to This Heart in my forums (for a? :-). Our faculty is in the midst of validating/redoing our curriculum, and we find ourselves returning to a search for what is the core of computer science (a different question than “what should every programmer know?”, to be sure, but an exercise similar in spirit). For my part, I have found that theory has given me a grasp of principles that prove very useful in practice. I have of course, like anyone else, learned things in practice that I could have learned nowhere else. What I learned in Lewis & Papdimitrious as a student, for example, helped me understand when to use a state machine and how to code it. It also helped me know what is solvable and what isn’t. I suppose there is no single definitive answer to this question, but what we learn in the asking is of great worth, and perhaps would never be learned if we hadn’t asked.
For those who asked where to find the article “What Every Computer Scientist Should Know about Floating-Point Arithmetic”, go to <http://docs.sun.com/htmlcoll/coll.648.2/iso-8859-1/NUMCOMPGD/ncg_goldberg. html>.
Cheers.— cda
I just finished reading through Michael C. Ring’s article on his arbitrary precision math library in the November 2001 issue of C/C++ Users Journal.
I found Mr. Ring’s article quite educational. He presents some interesting techniques and numerical methods that were not familiar to me. The idea of doing a million digit multiply using an FFT was worth the price of the subscription.
However, I fear he may be deluding himself and misleading his readers regarding the need for such extreme precision. If Mr. Ring were involved in pure mathematics or numerological research, I could appreciate his position, but his biography listed him as an electrical engineer. This causes me concern.
For instance, his first example involves multiplying values with 22 significant digits and 20 significant digits, producing 42 significant digits in the result. There are several large problems with this. First, no physical process in this galaxy can be measured with 22 significant digits of accuracy. That’s equivalent to measuring the distance to the sun in nanometers. Such accuracy is well beyond the capabilities of the human race today.
Second, and perhaps more importantly, multiplying a value with 22 significant digits by a value with 20 significant digits does not produce 42 significant digits of result. Instead, it produces a result with at most 20 significant digits. One never creates accuracy through arithmetic; one only loses accuracy. This is perhaps one of the most confusing and potentially dangerous areas of computerized numeric manipulation.
I thank Mr. Ring for this article, but it is important that readers understand their problem domains enough to ensure that this library is not used to provide a false sense of accuracy.
Tim Roberts
timr@probo.com
Providenza & Boekelheide, Inc.Your points are well taken, but there are circumstances that warrant extra precision. Keep in mind my choice of 22 and 20 digits was strictly for illustration.
I disagree with your statement that the result of 22 digits multiplied by 20 digits does not result in 42 digits. It does. It is common practice (Knuth, pg. 268) to consider that an N digit number multiplied by an M digit number results in an (N+M) digit result. Every multiplication algorithm devoted to arbitrary precision treats multiplication in this manner.
This is even true in integer multiply instructions of every CPU I’ve had access to. An 8-bit multiply by an 8-bit multiply ends up in a 16-bit (or two 8-bit) register. 16-bit x 16-bit yields a 32-bit result, etc.
What is the factorial of 500? There is an exact answer for this. It is approximately 1.22E+1134. There are approximately 1,000 digits in this factorial. Are all there digits useless? A user of my library is computing “multinomial probabilities on gene sequencing data” and has gone up to 8,000 so far. I’m not exactly sure what he’s doing with the data and I don’t care either. He simply needed a tool to do large factorials, logs, Nth power calculations, and so on.
In my case, I was doing polynomial curve fitting as I discussed in the article. Due to the round-off error of the Standard C double, I could only model (up to) an 18th order polynomial. Higher-order curve fits did not show any improvement. I had to use arbitrary precision because of the nature of the least squares curve-fitting algorithm. There are high-power calculations (x(2*order)) necessary to use this algorithm. My inputs were doubles, and my desired outputs were also doubles. I determined in order to have a stable result in the polynomial coefficients (final result double value not changing in the 16th digit), the intermediate math required that I maintain ~35-40 digits. By maintaining more digits in the intermediate math, I was able to compute the coefficients for much higher-order polynomials, up to 36th order or so. It turns out the solution was “good enough” at about a 24th order polynomial.
From my requirements just mentioned above, there is no physical analogy to the math I needed to perform. That did not change the fact that the math performed required higher precision, even though you can’t attach it to a “physical process.”
I never said there is a need for extreme precision. I simply provide the means to use the precision if you, the user, want it.
The fact that I’m an electrical engineer is irrelevant. I needed a tool to calculate with higher precision and I wrote one. It evolved into a general-purpose library that most anyone can use in his or her work, even PhDs in math doing numerological research. I hope this alleviates any concerns you may have.
Mike Ring