Earlier quoted context omitted.
I understand your position and I think it's the norm. Yet I find it difficult to comprehend how it's not self-evidently absurd. Do you feel like software transcends pyhsics, mathematics and logics? Because that's what the statement translates to. The only reason it's impossible, is because nobody tries, because trying to do so would interfer with the deliverables of next sprint. The software industry has painted itse…
Physics is full of leaky abstractions. Solid? Leaky abstraction (melting). Ideal gas? Leaky abstraction (van der Walls). Molecule? Leaky abstraction (chemical reactions). Atom? Leaky abstraction (ionization, fusion, fission, alpha and beta decay). Proton? Leaky abstraction (sometimes you have to care about the quarks).
Dijkstra's Crisis: The End of Algol and Beginning of Software Engineering (2010) [pdf]
21–30 of 31 posts
Re: Dijkstra's Crisis: The End of Algol and Beginning of Software Engineering (2010) [pdf]
#22Earlier quoted context omitted.
A leaky abstraction is like obscenity: I know it when I see it. It's impossible to define the concept in a rigorous way, and yet it impacts everything that we do. You're simply wrong to claim that we accept the situation without spending any real effort. In reality the more experienced developers who build abstraction layers tend to spend a lot of time trying to prevent leaks, but they can't have perfect foresight to…
I understand your position and I think it's the norm. Yet I find it difficult to comprehend how it's not self-evidently absurd. Do you feel like software transcends pyhsics, mathematics and logics? Because that's what the statement translates to. The only reason it's impossible, is because nobody tries, because trying to do so would interfer with the deliverables of next sprint. The software industry has painted itse…
No such faith comforts the software engineer. Much of the complexity he must master is arbitrary complexity, forced without rhyme or reason by the many human institutions and systems to which his interfaces must conform. These differ from interface to interface, and from time to time, not because of necessity but only because they were designed by different people, rather than by God."
- Fred Brooks, No Silver Bullet
Re: Dijkstra's Crisis: The End of Algol and Beginning of Software Engineering (2010) [pdf]
#23Earlier quoted context omitted.
While there is certainly some amount of unnecessary junk code out there, your claim that it could be reduced by an order of magnitude isn't even close to correct. In general the only way to write less code is to use higher level abstractions. The problem, of course, is that those abstractions are always leaky and using them tends to make certain required features too slow or even impossible to build at all. There is…
as programmers we like to use all this jargon like "leaky abstraction", but never bothered to understsand it beyond the PL paradigms we use. There's no formal definition and simply makes them good terms to abuse, and throw in conversations to make our points. Why are the abstractions leaky? Are all abstractions leaky? Why - we simply accept the situation without spending any real effort. "There's no free lunch" - thi…
You cannot have a thing without doing the work to build it. You don't get the better abstraction without implementing it first. Your proof in theory, is just that, until exercised, and the divergence from the ideal to the real world is finally realized. I can teach a programmer all manner of linguistic trickery to allow them to exploit all sorts of mathematical abuse of notation. None of that makes a cotton-picking, salt-licking bit of difference if at the end of the day, if your symbolic proof isn't translateable to a machine code that runs and maps successfully onto the operational space of an implementation of a computing device. If you give a program written in the form of a Shakespearean sonnet (an example of a focus on radical novelty in encoding a program without regard to analogy); say; I still need a bloody compiler that'll turn that into something that is capable of running within the constraints of the machine, and the other primitives to make it work. That's TANSTAAFL. You break from what exists; you still have to reroot and establish a parallel basis of operation that covers the primitive operations you're familiar with. Djikstra might be right. There's something liberating to staying in the realm of the formal and mathematical. His detractor's were also right. He is so damn far above everyone else, that everybody in the room has trouble understanding just what it is he's going on about. At the end of the day, teach what the greatest number of the people there can firmly mentally grip, and pass that on. The geniuses like Djikstra will quickly outgrow it, and excel. They don't need the help. Everyone else on the other hand, does. I wouldn't be opposed, to trying Djikstra's approach myself. Shattering my current understanding of the practice of programming and working more from a formal methods POV. That comes after a career which has been fruitful, and was rooted in the old way which worked quite well for many others educated at the same time I was. I already know I can do it. His method just changes the emphasis. Though I will note with alarm, his reticence to test is disturbing. If he does assume everything is proofable from the get go, then I suppose you don't need tests; but that's hardly the way anything in the world actually bloody works. That's Math in a vacuum, with spherical cows. Not writing code then realizing "Shit, the processor in the machine I'm writing for doesn't support that primitive, or has a glitchy implementation thereof".
Software engineering isn't programming for people who can't; it's a set of practices and know-how to navigate a niche field that are battle hardened, and tested through time to actually guarantee some semblance of a chance of success in a field shaped by such fast development, the logic of 6 months ago seems antiquated. For that time with Moore's Law in full swing, yeah. Radical novelty might have been justifiable; but ultimately didn't push past the test of time. It can be as clever a hack as you can imagine, but if no one else can follow it... You haven't condensed it to a teachable form.
Re: Dijkstra's Crisis: The End of Algol and Beginning of Software Engineering (2010) [pdf]
#24Earlier quoted context omitted.
All right, he believed that all programming should be done by his approach , or one highly similar. He could train undergrads, but anyone who wasn't trained his way shouldn't be programming. Is that a fair statement?
This is such a common position in just about every professional industry, codified legally or as personal belief, that it barely qualifies to be called out as unique to Dijkstra.
Re: Dijkstra's Crisis: The End of Algol and Beginning of Software Engineering (2010) [pdf]
#25Earlier quoted context omitted.
> ALGOL 68 was much better than the ALGOL W .. or any of the languages designed later by Wirth. In what respects particularly?
There are too many things for a short explanation. A nice feature of ALGOL 68 that was new at that time was the fully bracketed syntax (like later in the Ada language) with different kinds of brackets for different purposes, i.e. not just one "begin" and "end" pair (or "{" and "}" pair). Having different kinds of brackets for loops, conditional statements and blocks greatly improves the readability of a program, whil…
Re: Dijkstra's Crisis: The End of Algol and Beginning of Software Engineering (2010) [pdf]
#26Excerpts:
What, for Dijkstra, was the crisis? I believe it was the separation of practice from theory in the development of commercial systems software. Recall the background shared by many of the most distinguishing contributors to the Nato conference, such as Dijkstra, Hoare, Perlis, Naur, and Wirth. They were exceptionally gifted men, many with strong scientific backgrounds, who in the early- and mid- 1960s had produced effective, elegant and reliable pieces of systems software with small teams and tiny budgets while working in research environments or for marginal computer firms. They were not by temperament successful corporate managers or project management specialists. So their instinct was to recoil as word spread of out-of-control industrial development efforts in which millions were being spend to produce unreliable, bloated, and incomplete operating systems and compilers ... Instead their faith was that with the application of suitably rigorous and mathematical methods a small team could produce high quality systems software without the need for massive teams of programmers and elaborate bureaucratic controls.
Near the end of his life, Dijkstra wrote that
"The ALGOL implementation was one of my proudest achievements. Its major significance was that it was done in 8 months at the investment of less than 3 man-years. The rumour was that IBM's FORTRAN implementation had taken 300 man-years and thus had been a project in size way beyond what a university could ever hope to undertake. By requiring only 1 % of that labour, our compiler returned language implementation to the academic world, and that was its political significance".
Yet his single biggest complaint, and one underlying many of the others, was against the idea that computer scientists must adjust their expectations to a world in which most programmers are intellectually mediocre and theory-averse. This is why he called himself a “humble programmer” in his Turing award speech, rather than, as his colleagues might, an arrogant (albeit insecure) academic computer scientist. Trained as a physicist he believed that the proper model for programming came from “mathematical engineering,” a concept he claimed was well understood in the Netherlands but which thoroughly confused his American colleagues. By seizing the mantle of programmer, despite his increasingly deep immersion in the world of mathematical theory and formal methods, Dijkstra could insist that he had not left programming behind. If actual programmers failed to grasp the importance of his new work then it was they who were betraying the true essence of programming.
Dijkstra gave a particularly clear statement of this in 1977, in an open letter circulated to fellow members of Working Group 2.3. According to Dijkstra, in the late 1960s it “became abundantly clear that we did not know how to program well enough.” As a result “people concerned with Programming Methodology,” by which he presumably means him and his fellow working group members, discovered that programming was “a tough engineering discipline with a strong mathematical flavor.” However this inarguable conclusion was sometimes ignored, “because of the unattractiveness of its implications, such as,”
(1) good programming is probably beyond the intellectual abilities of today's 'average programmer’
(2) to do, hic et nunc, the job well enough with today's army of practitioners, many of whom have been lured into a profession well beyond their intellectual abilities, is an insoluble problem
(3) our only hope is that, by revealing the intellectual contents of programming, we will make the subject attractive to the type of students it deserves, so that a next generation of better qualified programmers may gradually replace the current one.
According to Dijkstra, only “political or emotional reasons” could explain disagreement with these “technical” observations. He conceded that they were “unattractive” and had “severe” social implications and no quick solutions. Clearly it would not be easy to replace almost the entire programming workforce. But he dreamed of a scientific revolution, in which programming would win recognition as a mathematical discipline and the incompetent hordes currently messing things up would be swept away and replaced by an elite corps of scientists versed in new and more formal methods of software development.
PS: With AI tools becoming the norm in programming today, things are going to become exponentially worse if "the average programmers" do not study and use formal mathematical methods for code generation and verification.
Re: Dijkstra's Crisis: The End of Algol and Beginning of Software Engineering (2010) [pdf]
#27Earlier quoted context omitted.
as programmers we like to use all this jargon like "leaky abstraction", but never bothered to understsand it beyond the PL paradigms we use. There's no formal definition and simply makes them good terms to abuse, and throw in conversations to make our points. Why are the abstractions leaky? Are all abstractions leaky? Why - we simply accept the situation without spending any real effort. "There's no free lunch" - thi…
>"There's no free lunch" - this is representative of the level of argument in software circles entirely. But WTF does that mean? You cannot have a thing without doing the work to build it. You don't get the better abstraction without implementing it first. Your proof in theory, is just that, until exercised, and the divergence from the ideal to the real world is finally realized. I can teach a programmer all manner o…
Re: Dijkstra's Crisis: The End of Algol and Beginning of Software Engineering (2010) [pdf]
#28There's an irony about the design of ALGOL 68. It was denounced at the time as being too big a language, with too many experimental features. In fact, the language in the Report is unimplementable, primarily because the lexical syntax is fanciful (there's an actual difference between the roman period and the italic period) and also abstract (so no two implementations actually have the same lexical syntax). I was on the periphery of an ALGOL 68 implementation project that foundered because the goal was to implement every conceivable edge case, include those that could never occur in practice, e.g., x[i] := x[...50 pages of code...] Yet very reasonable subsets (including ALGOL-68R and FLACC) were built. As for the language breadth, arguably C# is much broader, and I haven't heard anyone claim that it is a failure.
As for the Report...there was a time when I understood it cover to cover. But Lindsey and van der Meulen's Informal Introduction presented the whole language at a level understandable to anyone who understood ALGOL 60. van Wijngaarden did the language a terrible disservice when he forced (that is the correct word, I believe) the use of two-level grammars in order to ensure type correctness. Had the Report never existed, the language would have had much more traction.
The irony? Apart from the grossly-overengineered “transput” library—much better adapted to a unit-record and line printer world than our modern world—the one actual experimental feature in the language was the par clause, which provided parallel execution, and relied on semaphores for synchronization. Dijkstra's semaphores.
Re: Dijkstra's Crisis: The End of Algol and Beginning of Software Engineering (2010) [pdf]
#29Intersting. The author of the attached document is Dr. Thomas Haigh, a prominent academic historian specializing in the history of computing. The document challenges the conventional historical narrative surrounding the birth of software engineering. It argues that the widely accepted origin story centering on the 1968 NATO Software Engineering Conference and the "software crisis" was actually a narrative constructed…
IDK what Dijkstra believed in terms of how programmers should have looked like, bu the did seem to have a sense (and taste) of a direction of programming that was lost within practicing software engineering and their prefered PLs. My own incomplete opionion is that the net effect is that we ended up writing orderd of magnitude more code than necessary to solve the problems at hand. It's the equivalent of doing the co…
Re: Dijkstra's Crisis: The End of Algol and Beginning of Software Engineering (2010) [pdf]
#30Earlier quoted context omitted.
A leaky abstraction is like obscenity: I know it when I see it. It's impossible to define the concept in a rigorous way, and yet it impacts everything that we do. You're simply wrong to claim that we accept the situation without spending any real effort. In reality the more experienced developers who build abstraction layers tend to spend a lot of time trying to prevent leaks, but they can't have perfect foresight to…
I understand your position and I think it's the norm. Yet I find it difficult to comprehend how it's not self-evidently absurd. Do you feel like software transcends pyhsics, mathematics and logics? Because that's what the statement translates to. The only reason it's impossible, is because nobody tries, because trying to do so would interfer with the deliverables of next sprint. The software industry has painted itse…