In another thread I saw today someone referencing to Donald Knuth & Niklaus Wirth as something he learned 30 years ago (as I did myself to) Another member questioned who or what Knuth & Wirth were.

Silly question?

On the old punchcard days of programming we had 2 major languages (well, almost) Cobol and Fortran. I have never used Cobol, but I have used a lot of Fortran. I am talking here about the original Fortran, 1963 or so. It was not uncommon practice to write large Fortran programs of thousands of lines, lot of globals, no subroutines, or at least not logically designed, hundreds of GOTO's, etc etc, on other words unmaintainable spaghetti code.

Knuth & Wirth (among other things) tried to set up methods for logical and clean program design, like top down design, data structures, structured programming, correct use of variable scopes etc. Some of these terms are overlapping, I know, but most important of all was clean program design which lead to understandable and maintainable programs. Using their guidelines, programs in C could be just as readable and as structured as in Algol, Pascal or Modula2.

What is left of that today? Are Knuth & Wirth apparently not even teached anymore? In many mainstream languages (Java, C++) I see the use of huge number of objects, either predefined or selfdefined, which thru polymorphism and event-driven programming become a mass of incomprehensible pieces of code where one doesn't when or wich piece of code is being executed. It is even worse than Fortran spaghetti structure as you can't even find out the program flow. It is possible to follow a small piece of code making some assumptions, but grab the overall setup of a program: no way. (yes, it should be in the documentation)

As for data ordering we now use global data structures, objects (which are sometimes global for the application, sometimes not), data inside objects, which can have various flavours of accessibility and scoping so with each use you have to realize in which name space you are, not only dependent on the scope, but also within which class code is being executed. But you never can be sure which code is executed because of late binding...

Where have these design methods gone, or am I just looking thru dark glasses?

jlinkels

Hey -- yes, the person on that thread was a young physicist, not a programmer though. They were here to get some clues on how to start programming. Otherwise I'd say you'd be right to be surprised and even to some degree saddened that a part of your experience could be in threat of disappearing.

I recently finished a computer engineering degree, and Knuth was not mentioned -- or if he was, it was in an anecdotal way. I've heard about him from programmers -- in miscellaneous places "around." I have not picked up the Art of Computer Programming, but have recognized for some time that I really ought to do so. Similarly, Gang of Four.

This is an interesting juncture in the history of computer science, as domain knowledge and even cultural history is transferring from the first wave of pioneers in your vintage to fresh young Linux scouts like myself. It's quite a different field since 1963*, and I'm quite pleased I don't have to write cryptic subroutines on punch cards, yet Knuth, K&R, GoF, etc. will, I feel, be immortalized on the Founding Fathers of Modern Programming shelf for quite some time to come. Sound engineering design principles accrued throughout history will always be worth learning -- in particular within the nascent discipline of Computer Science.

* You know this better than I, but I have tried to take a byte¹ of computer history. :-)
¹ Always space for a pun or two.

I often ponder these philosophical questions:

• If all programs suddenly disappeared, how long would it take to build programming back up to a comparable state? How different would those parallel states be from each other?
• Is it necessary to retain the expertise and capability to do so? On the same token, should we still have experts on making light bulbs by hand?
• Is it actually possible to lose the support of a direct lineage?

Any implicit answers are unintentional.
Kevin Barry

PS In addition to studying Knuth and Wirth, kids need to get off of the computer and get outside more. And stay in good physical condition.

Donald Knuth is still around -- http://en.wikipedia.org/wiki/Donald_Knuth. His text books (note the plural) are still used in some Universities (more likely computer science than computer engineering). GNU even has a project that simulates the MIX assembly language so that you can do the assignments -- http://www.gnu.org/software/mdk/. And, his technical document processing program TeX is widely used in Math and Science departments, and even required as the document format to submit to some mathematically oriented scientific journals. I'm sure that just scratches the surface of where and how his contributions permeate current computer culture and usage.

Niklaus Wirth is best known for the programming languages he helped design -- http://en.wikipedia.org/wiki/Niklaus_Wirth.

How about Edsger Dijkstra? -- http://en.wikipedia.org/wiki/Edsger_Dijkstra. While I didn't think his writings were terribly clear, he motivated some of the original efforts to straighten out the domination of spaghetti code by promulgating structured programming. That was the principle guide for programming until object oriented programming came along. You can also thank him for re-inventing and implementing RPN to make more efficient use of the stack for calculations. Every HP calculator I've owned (only 3 of them since 1979) is RPN. PostScript is RPN.

You've got your Wirth and Knuth. Great guys. Lots of things to say 30 years ago when structured programming was needed to sort out the mess that sprang forth from the early programmers. But even structured programming had its limits. We got Booch and Meyers to teach us OOAD. When that hit its limits, we got the Gang of Four. From there we have Kent Beck, Robert Martin, and Martin Fowler. There are plenty others that are missing from the list. All I'm saying is that Wirth and Knuth had a lot to say. We wouldn't be here without them. Each generation has allowed us to write ever more complex programs. But you can't touch anything written today with just the knowledge of those two. The software engineering world has incorporated their ideas and moved on.

I am not sure what exactly you mena, but the person in that thread who mentioned Knuth and Wirth was me - already not young, but still a physicist - at least, by education and by real life exposure to HW development with a lot of SW involved.

...

To jlinkels - great opening post.

It often feels sad talking to OO proponents who think OO is a value in itself, rather than a means to achieve noble ends.

It's also sad in the same context to talk to the same proponent just to realize their mind is set on OO and they are not ready to consider other alternatives like functional, for example.

On the optimistic note - some younger folks suddenly realize that it can be much easier and practical to do some things in Perl than, say, in Java: http://linux.sys-con.com/node/44251 .

I picked the above link in another forum, and people were complaining about countless level of hierarchy: "25 levels of abstraction. So reusable, it is unusable".

Sergei -- I meant the other person who had started the thread, and who had not heard of those people. I did not know that you are a physicist as well!

There's a general lack of formality in software these days. Probably there always was (I've only been paying attention for ten years). We've traded the complexity of casting problems in the language of the machine for the complexity of building systems bigger than any one person can imagine. Whereas we've all adopted the easier programming languages (starting with C, then moving to larger forms of abstraction e.g. function and object) the kind of care in designing things that both Knuth and Dijkstra were proponents of just hasn't caught on. If it works then that's all that matters. This whole unit testing craze is just sort of a demonstration of that; you know the things that ought to work and you code to meet that expectation. It's useful, but it's also the opposite of how good design should work: it starts with the goal and works backwards rather than developing a sound theory of functionality on which the actual implementation is built. If you forget a test case then what? Perhaps your code will not work in that situation at all.

But because we've all got these huge languages with these massive libraries (which is essentially required since we cannot possibly conceive of both our enormous projects and having to code all the data structures and algorithms) we can be more sloppy. It's obvious when your priority queue doesn't work right so you need to be very strict to make sure it works. But a tiny little fragment of code that runs once per week on predictable data may fail much more subtly when something goes awry. If it rarely happens you allocate less resources to fixing it, and because of deadlines maybe it just ships anyway. It passes all the unit tests, right? Must have just been a glitch. After all, we've all seen bugs that crop up once and then we can never find them again. It's just an excuse not to put time in up front to do the proper formal design. I think perhaps if we had to write more low-level type stuff, if we all had to "eat our own dogfood" by writing string searches and priority queues, we'd have a better appreciation for what it takes to create a well thought out design with no semantic holes. Of course then nothing would ever get done...

That's been a common complaint among experienced long time sysadmins around my work. The computer science folks are way too focused on Java, and don't get enough of the broader, more practical, background. We have gotten some of our best young sysadmins and systems programmers from the linguistics department.

Thanks all for your reactions.

It is not very promising for the future of efficient and elegant software design.

OK, I thought that I was insane being not really fond of this unit testing. I have exactly the same experience with an external company who wrote some pieces of software for me. With each deliverable their code passes their unit tests but it doesn't run in my environment.

jlinkels

That is an interesting point -- I like the way you've put it into words. And I think, in accordance with what you have said, it is no surprise that unit testing has seen more push from the OO Java apps "just get things done" crowd than from the C/UNIX hackers. When you "do one thing and do it well" as a design philosophy, much of the utility of unit testing has already been precluded.

unfortunatley it's idiot project managers who drive things on.
unix is crap, it can't even open powerpoint.
java is the future didn't you know?

development is seen as a junior role, a stepping stone; not a proper engineering
discipline.
these methods are to train college kids who don't know how the world works.
The fact is most people in I.T. ain't got a clue about computers, hence MS is everywhere.