Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How do we tell truths that might hurt? (1975)

cs.utexas.edu

Post reply on HN
Print view View original

41–50 of 74 posts

Re: How do we tell truths that might hurt? (1975)

#41

Post by ThrowawayR2 »

madhadron wrote: post #7
ThrowawayR2 wrote: post #2

Personally, I've always thought this letter was the plainest proof that Dijkstra's pithy quotes (and those that parrot them) should not be taken seriously, no matter how entertaining they are. That list covers most the major languages of the day; what he would have to say about $(YOUR_FAVORITE_LANGUAGE) would surely be equally unkind were he alive today. That isn't to say that he did not have valid reasoning for his…

The context of this EWD is somewhat lost to history, because Dijkstra's point of view in many cases won so thoroughly that we cannot conceive of what he was describing. The BASIC he is describing had no call stack, nothing that would resemble a function in today's languages. FORTRAN at the time handed masses of state around in global variables and the latest version had just added subroutines and functions. This is a…

Having written code in the early microcomputer BASICs, I'm reasonably familiar with the context but I think it's a bit overblown. Sure, BASIC was limited in the syntactic sugar that was available to manage program complexity but, then again, the microcomputers of the era were so limited that complexity wasn't really possible without dropping to machine language anyway. And machine language definitely didn't have any of the syntactic sugar of ALGOL 60 or other high-level languagess.

Re: How do we tell truths that might hurt? (1975)

#42

Post by Jtsummers »

AnimalMuppet wrote: post #16
qntty wrote: post #6

Earlier quoted context omitted.

What modern language would Dijkstra approve of?

I suspect, none of them. If he did approve of one, it would probably be Haskell. And, for all his complaining, I don't know of any language that he authored. He's sure good at telling everyone that they're doing it wrong, though...

His rant-y EWDs seem to be the only ones people know. But his others go into much more detail about what he thinks and why. And while he didn't (to the best of my knowledge) directly create any language, he did implement an Algol 60 compiler and was involved in language design efforts throughout his life.

He helped create the ideas of Structured Programming, which most of us now take for granted, since pretty much every language in popular use these days are based on these ideas.

Re: How do we tell truths that might hurt? (1975)

#43

Post by ThrowawayR2 »

User23 wrote: post #32
ThrowawayR2 wrote: post #26

Earlier quoted context omitted.

> " He calls out BASIC specifically because it was ubiquitous and often the only option on the machines novices would have available at the time. " EWD's quote is from 1975 which is just barely the start of the microcomputer era (the Altair 8800 came out in '75 and the Apple II in '77), so he's not referring to those. Most people writing programs would have had access to mainframes and therefore had access to multipl…

https://en.wikipedia.org/wiki/BASIC#Explosive_growth:_the_ho...

The Altair 8800 came out in January 1975; Gates and Allen's Altair BASIC, the first microcomputer BASIC, came out "shortly thereafter" and EWD498 was written in June 1975. That's hardly long enough for an explosion. Again, Dijkstra probably had never even heard of either when he penned his missive and it's clear that his opinion of BASIC was well formed even before 1975.

Re: How do we tell truths that might hurt? (1975)

#44

Post by User23 »

_u9xp wrote: post #39
User23 wrote: post #8

Earlier quoted context omitted.

There are so many languages available today that I'm sure there are plenty he would have approved of. For example, I think he might have appreciated Zig. If you read his work it's pretty easy to see his top priority is managing complexity and limiting surprise.

> his top priority is managing complexity and limiting surprise Zig doesn't do either of those things. There are a fair amount of criticisms of the mental model of the author that I've seen voiced - some including security. What's worse, the community surrounding Zig (in particular, the Discord community) operates more like a cult - any negative questioning gets you shunned. I was personally a huge fan of Zig until a…

That’s too bad. I was judging based on the overview of Zig that was recently posted here. I gladly defer to your more informed opinion on the subject, but I’ll maintain Dijkstra would have liked the design goal of executing the procedure as written absent fancy obfuscated control structures.

The cult-like attitude that many programmers have about languages certainly supports Dijkstra’s claims about the immaturity of the field.

Re: How do we tell truths that might hurt? (1975)

#45

Post by brundolf »

_u9xp wrote: post #37
brundolf wrote: post #34

Earlier quoted context omitted.

I've no doubt they have license to do so without damaging their careers. That doesn't make it a good take.

Because it makes you uncomfortable? Or because you have reason to believe otherwise?

Because any subjective assertion this narrow is going to be some amount of wrong.

Re: How do we tell truths that might hurt? (1975)

#47

Post by user5994461 »

qntty wrote: post #6
Kednicma wrote: post #5

Some of these have aged so perfectly that I only need substitute a few letters: > Python —"the infantile disorder"—, by now nearly 30 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use. > It is practically impossible to teach good programming to students that have had a prior exposure to JS: as potential programmers t…

What modern language would Dijkstra approve of?

He would probably form a completely different opinion, the world is nothing like what could be anticipated 30 years go.

The first languages and their compilers were strongly driven by hardware constraints, a kilobyte of memory costing an arm and a leg.

Imagine storing function names in memory to compile the program, it doesn't fit in 1 kB. Imagine storing the whole source code in memory for processing, it doesn't work when there is less than a 1 MB of memory available.

It's ridiculous today but it's real reasons why things were made global back then or why C/pascal split the code between a header and a source file.

Re: How do we tell truths that might hurt? (1975)

#48

Post by dkarl »

brundolf wrote: post #45
_u9xp wrote: post #37

Earlier quoted context omitted.

Because it makes you uncomfortable? Or because you have reason to believe otherwise?

Because any subjective assertion this narrow is going to be some amount of wrong.

Dijkstra was obsessed with mathematical correctness and certainly knew it was pointless to pursue in human language speaking about complex topics. He wanted people to pay attention, and they did. I think it's a testament to the effectiveness of his writing, and proof that it was not merely inflammatory, that people still read him and debate his ideas today, when his ideas have as little mainstream acceptance as they ever had.

Re: How do we tell truths that might hurt? (1975)

#49

Post by jolux »

skrebbel wrote: post #19
jolux wrote: post #18

Earlier quoted context omitted.

Algol is quite different from Fortran.

Sure, so is COBOL. That wasn't my question.

Well, I believe the answer to your question is the edition of Algol he worked on. I personally think it’s one of the most elegant imperative language designs in history.

Re: How do we tell truths that might hurt? (1975)

#50

Post by andi999 »

qsort wrote: post #40
madhadron wrote: post #7

Earlier quoted context omitted.

The context of this EWD is somewhat lost to history, because Dijkstra's point of view in many cases won so thoroughly that we cannot conceive of what he was describing. The BASIC he is describing had no call stack, nothing that would resemble a function in today's languages. FORTRAN at the time handed masses of state around in global variables and the latest version had just added subroutines and functions. This is a…

As a massive fan of Dijkstra myself, true but up to a point. About programming languages I don't think there's any question he was right. Sometimes we agree with him even without realizing it, for example, the original argument of GOTO considered harmful was that GOTO statements decreased "linearity" by having the control flow jump to random places. The recent trend in mainstream PLs to adopt functional-style control…

The goto thing is one of my pet peeve, somehow it caught on, maybe it made people feel good so they can look down on others. There is basically 2 arguments against it: Knuths article arguing for goto (read it if you havent), and the observation that gotos and state machines (which are considered best practices) are basically equivalent (just convert the goto labels to your states).
Post reply on HN