Why Programming Still Stinks

Andrew Leonard writes "Scott Rosenberg has a column on Salon today about a conference held in honor of the twentieth anniversary of the publishing of 'Programmers at Work.' Among the panelists saying interesting things about the state of programing today are Andy Hertzfeld, Charles Simonyi, Jaron Lanier, and Jef Raskin."

Comments

panel link

[AnonymousCowheart]

here is the link to the ppl on the panel, and talks about their backround

Re:Copyright

[CeleronXL]

In general I'd have to agree, but in this case seeing as Salon was simply trying to get money by having one of their own staffers(?) submit the article here, I think it would be well deserved. ;)

Re:This is why I hate slashdot

[torokun]

This is some serious copyright infringement, man. Ripping an article verbatim and posting it on another site.

Re:And Here's the Google Cache to the Article

[JPriest]

Here is the same link without the annoying highlighted words.
just remove all+the+search+terms

The same link here with extra words highlighted.

Hungarian Notation

[Speare]

The linked page didn't mention that Charles Simonyi is the Hungarian for whom the term, Hungarian Notation is named.

Hungarian Notation is that Microsoft Windows programming naming strategy where the first few characters of a variable name should hint to the reader as to its data type. So hToolbox tips you to understand that it was a HANDLE type, even without scrolling your editor up a couple pages to find out; papszEnvironment would likewise tell a Win32 devotee that it was a Pointer to an Array of Pointers to Zero-terminated Strings.

It's not the first such instance of binding data type and name, and it won't be the last. For example, FORTRAN compilers have long had implicit variables; any variable not otherwise declared that started with I, J, K, L, M, or N would be assumed to be an integer, where most other variables would assume a real (floating-point) type. So FORCE(LAMBDA) directs the code to a real scalar from a real array, given an integer index. Many programmers start a routine with IMPLICIT NONE to disable this assumptive behavior, as mistakes are easy to make when you let the machine decide things for you.

BASIC would use sigils at the end of the variable names (NAME$, COUNT#, and scripting languages like Perl use sigils that precede the name %phones, @log, $count).

Re:Hungarian Notation

[john.r.strohm]

Hungarian notation was originally developed as a band-aid (tm) for the near-complete lack of type checking in C. When all ints are created equal, and may be freely assigned to each other, and pointers must routinely be type-coerced to something else, and the compiler refuses to help the programmer keep things straight, something like Hungarian notation becomes necessary.

Hungarian notation declined after Stroustrup added strong typing to C++. It is worth noting that Stroustrup never even considered NOT doing strong typing in C++. (Read his book on the design and evolution of C++.) Distaste on the part of hard-line C programmers for strong typing also declined, after C++ forced them to eat their broccoli, and they discovered it actually tasted pretty good (by catching errors that would otherwise not have been found nearly as easily).

It is also worth noting that Hungarian notation never caught on in any language other than C. In particular, Ada programmers never bothered with it: the Ada type system was rich enough that it could do everything that Hungarian notation pretended to do, and enforce it, by requiring compilers to refuse to compile type-incorrect programs.

(Somewhere, recently, I saw something about a commercial satellite project that was forced to use Ada, because there was no C/C++ compiler available for a recently-declassified microprocessor. Their programmers screamed bloody murder at the idea. The screams stopped when they noticed that the Ada compiler was catching errors for them.)

It helps to understand low-level stuff

[Admiral Burrito]

You can learn as much from a data structures class taugh in Java as you can from one taught in $language_of_choice. The idea is to learn how things work fundamentally, and then apply those ideas practically. A linked list in Java works the same as a linked list in C.

The thing is, Java is somewhat high-level. There are things that go on under the hood that you won't learn about, but once in a while pop up anyway. For example, being taught Java, you won't learn about the difference between memory allocated on the heap, and memory allocated on the stack. And yet...

This does not work (it doesn't even compile):

String x = "a";
(new Runnable() { public void run() { x = "b"; } } ).run();
System.out.println(x);

There's nothing wrong with the code; the problem is that Java pretends to support closures but really doesn't. To use x in the anonymous inner class, you need to declare it final. But if you declare it final, you can't do the x = "b" assignment.

I'm familiar with C, so I understand the difference between the heap and the stack. I can infer that x (the reference to the string, not the string itself) is allocated on the stack. It is not uncommon for instances of anonymous inner classes to outlive the stack frame they were created in, so the compiler doesn't know whether or not x (on the stack) will still exist when the object's run() method is called. So it makes a _copy_ of x, but in order to pretend that it is still x, the compiler wants you to declare it final so that the original and the copy can never get out of sync.

Having experience with C, I know the heap is a safe place to put things that may need to outlive the current stack frame:

final String[] x = new String[] { "a" };
(new Runnable() { public void run() { x[0] = "b"; } } ).run();
System.out.println(x[0]);

It's ugly, but it works. The reference called x needs to be declared final (because it's on the stack) but the reference contained in the array does not need to be final (because it's on the heap).

Because of my experience with lower-level stuff, I understand how Java is faking its support for closures, and how to work around the limitations. This is only one example; there are many other times when understanding things from a closer-to-the-metal perspective gives insights that would be lost if things were only understood from a high level. Joel Spolsky summed this up fairly well: Leaky Abstractions

Re:Keep it simple, stupid.

[MythMoth]

I think you're over stating your case.

In pure line count a minimal Java Hello World would only have one additional line.

It is crammed with keywords, and it contains the notion of Objects and Classes.

But I see that as a good thing - you can concentrate on the mainline code and introduce the student to control flow and so forth, but when you come to the concepts of classes you've got a nice immediate example to point to.

It's so much easier to teach a language when a common reaction to new information is "oh, I wondered what that was for" rather than "why would I ever need that ?"

Finally I have to completely disagree with you about type safety. A perfectly written and comprehended program does not need type safety. A real world program will never be either, and type safety will prevent some of the nastiest bugs from occurring and keep your data intact.

I have no problem with C in its place, but its place is not as a learning language or as a business language.

D.