Remineds me of a line from Paul Graham’s essay, Hackers and Painters:

“A programming language is for thinking of programs, not for expressing programs you’ve already thought of”

Thinking is done in a language and the design of the language has influence on the thinking.

But I think you have wrong the reason people are making this move. It’s not because people don’t like strong typing as much as they don’t like the pain-in-the-you-know-what declarative typing that languages like Java use. Type inference makes a world of difference.

Firstly, one point of agreement is that ensuring verifiability is crucial goal of every project. However the only technique i know which works is multi level automated testing. Dijkstra in the article does not address any of this technique. Another technique that I expect to gain the momentuim is independent usability reviews. But this is only my speculation.

There’s a great article of perl creator Lary Wall http://www.oreilly.com/catalog/opensources/book/larry.html

Let me quote from it:-
…This is important, and a little hard to understand. English is useful because it’s a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess (though in the nicest of possible ways)…

You see, Perl, was designed on purpose as a “mess” (nicest mess though). That’s why it is so useful. Do you think Dijkstra would approve this “mess” approach in design of the languiage? I have an impression that not. And that is my main point of criticism.

The point is not that every problem that we trying to solve in programs is so somplicated that we should abandon any hope to improve the quality of the code. But the variance of problems themselves that software engeneering is applied to is so big that any attepmt of finding universal approach to this is doomed to fail.

The strategy lies not in “limiting” techinques - like the one’s Dijkstra suggests, but on opposite inserting more “nice mess” as in Perl or even C++. See how “loosely typed” languages are getting momentum. The world is going in quite opposite direction than Dijkstra predicted.

I agree. Tests are not proof but they are a close substitute. I saw some statistics from large software projects showing that testing even one execution path through a function found 55% of the defects in that function. Testing two execution paths found 65% of the defects. It takes surprisingly few test cases (say a dozen good tests) to reach 95%. These are averages of course, but they point to the power of TDD.

I’m reminded of the famous remark attributed to Sir Tony Hoare, “I don’t know what the programming language of the year 2000 will look like, but I know it will be called Fortran.” I used FORTRAN in the 60s. And I am totally confidant that if we could time-transport to 2006 a FORTRAN programmer and an ALGOL programmer of the mid-60s, the ALGOL programmer would be *far* more at home with FORTRAN 2003 than the FORTRAN programmer. Finally, there is much evidence that the relative frequency of use between FORTRAN and ALGOL (in the US!) had more to do with IBM and politics than technical considerations.

One of the papers that helped me understand the POV of Dijkstra, and other significant European computing scientists, is “On the fact that the Atlantic Ocean has two sides”. (EWD 611)

I didn’t mean at all to deny formal, mathematical methods as an important part of what Dijkstra taught and wrote. Rather, what I had hoped to emphasize is that our field is now coming [back] to some of the core concerns that motivated his work, such as verifiability as a core design concept.

Few (if any) of Dijkstra’s writings can be used as quick recipes (and I suspect he would have been horrified at an attempt to do so ;-). I personally found his book, _A_Discipline_of_Programming_ (1976), simultaneously challenging to read and rewarding to contemplate and apply. If I had to suggest concrete applications of his ideas, the first one that comes to mind is, “Never write a line of code without first asking yourself how you’ll verify that it is correct.” If I could master that one and avoid the creation of unnecessary complexity, then that would be enough for me.

“The competent programmer is fully aware of the strictly limited size of his own skull; therefor he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.”

It reminds me of Richard Gabriel’s “Habitability”:

“Habitability is the characteristic of source code that enables
programmers, coders, bug-fixers, and people coming to the code
later in its life to understand its construction and intentions and
to change it comfortably and confidently”.

(from http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf)

“Clever tricks” are likely to reduce habitability. This is not to say that they are never warranted, just (in production code) not as ends in themselves. To improve type safety or efficiency in some critical piece of code, quite possibly.

I also appreciated the sentiment of this comment from Dijkstra’s summary:

“We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.”

More easily said than done of course, and what constitutes a “modest and elegant programming language” is a minefield, but one worth carefully exploring.

As to Algol I still see it in one raw with other artifacts of computer history that we learned more from their failures then from their real achievments. It was important stage of learning curve but I would not call them achievements by themsleves. Algol, Multix, CORBA etc all failed partially due to rigorous design process which totally neglected “real life” requirements and addressing it as “implementation issues”. By the way FORTRAN was invented before ALGOL and is still in more extensive use. DC-9 flew a lot, ALGOL never really got airborne.

It not easy arguing with you as you don’t give any concrete anchor examples as how to implement Dijkstra vision of “intellectually manageable software”. You rejected mathematical proof as what Dijkstra meant and you didn’t give any example of methodology that would get us close to what Dijkstra would approve.

Actually this is another problem with Dijkstra article. What are concrete steps we must take to improve the current state of affairs.

“…restrict ourselves to the subset of the intellectually manageable programs…” - Too vague advice to be of any usefulness.

“…vital abstraction patterns…” - I answered that before.

Argument three - sounds to me as test-driven (in this case I totally support it) but I am quite not sure that Dijkstra meant it.

“…use better languages/tools..”! - Tottally agree. But when Dijkstra tries to be a little more concrete with his “baroque” concept, he looses me. “baroque languages” (php, perl, python, ruby) are the ones that are winning over disciplined ones (java).

“…The wider applicability of nicely factored solutions…”- C’mon who will argue, but how? How you decide which abstraction is better then other. Actually overabstraction is more problematic anmongst young programmer then under-abstraction. But this is theme for another article.

Reading it over and over I couldn’t find any really useful advice of how to imrove my work starting toady. Can you help me?