Live data from Hacker News

E.W.Dijkstra: On the foolishness of "natural language programming"

cs.utexas.edu

31–40 of 71 posts

Re: E.W.Dijkstra: On the foolishness of "natural language programming"

#31
post #9
post #4

Earlier quoted context omitted.

It's often the foolhardy and the ignorant that tackle problems that are supposedly impossible. And sometimes end up succeeding. Wisdom is certainly something to take from, but embodying the limits imposed by someone as a roadblock to onself isn't the way to innovation.

> It's often the foolhardy and the ignorant that [...] sometimes end up succeeding. Please name some examples. How often is sometimes? What is their probability of success compared to that of domain experts?

Will get pointed up but just smacks of passive-agressive argumental.

History, specifically in science and math is full of examples where people who actively sought to question the knowledge of more senior experts have made discoveries that advanced the knowledge of human-kind and have then been overlooked or ignored because they did not have the correct background. Institutions such as The Royal Society and The Geological Society where created exactly on this principle.

The idea that "you cannot question X because X is a learned man above your station" is what IMO destroys general interest in fields such as physics. You have to spend a career following the party line in the hope that one day you will be given enough rope to actually challenge anything.

How on earth would you put probability on something like that?

Re: E.W.Dijkstra: On the foolishness of "natural language programming"

#32
Does a specification count as native-tongue programming (using this term as NLP seems overloaded)? If it doesn't, why doesn't it? Would it be better if everybody on a project expressed their ideas in a computer programming language?

This seems like an eloquent diatribe against AppleScript, but Applescript is not what I imagine native-tongue programming to be.

Re: E.W.Dijkstra: On the foolishness of "natural language programming"

#33
post #15
post #11

Earlier quoted context omitted.

Let's suppose it's a really easy problem to solve. Why the hell would anyone want to program in a natural language? Suppose you could write a kernel in such a language, and one of the instructions was: "Load the first 5 bits at address 0x323abc into the last 5 bits after address 0x89bbca" Now, wouldn't it be easier to say 'shuffle_bits(5, 0x232abc, 0x89bbca);' where you control precisely what 'shuffle_bits' does?

copy the time field from cpuinfo to temp_time' backup the low 5 bits of goodnameformemorylocation' locA's low 5 to locb's low 5' Seems like there are a fair number of nice representations. Context is obviously important though: in a kernel, you probably want fairly implicit ways of referring to bits.

That is basically what COBOL looks like.

Re: E.W.Dijkstra: On the foolishness of "natural language programming"

#34
post #31
post #9

Earlier quoted context omitted.

> It's often the foolhardy and the ignorant that [...] sometimes end up succeeding. Please name some examples. How often is sometimes? What is their probability of success compared to that of domain experts?

Will get pointed up but just smacks of passive-agressive argumental. History, specifically in science and math is full of examples where people who actively sought to question the knowledge of more senior experts have made discoveries that advanced the knowledge of human-kind and have then been overlooked or ignored because they did not have the correct background. Institutions such as The Royal Society and The Geolo…

The existence of a black swan doesn't imply that swans are usually black.

A. "There are examples where newcomers to a field found a novel solution that senior experts have missed."

B. "It is often the ignorant who succeeds."

B does not follow from A. Not even in mathematics where people use to say that you have to prove yourself worthwhile by the age of 25 or it won't happen.

> You have to spend a career following the party line in the hope that ...

This is a slightly different discussion but IMHO in many fields (e.g. medicine) contemporary science has little to do with genious or insight but rather is an industrial effort ... and that _often_ isn't fun.

Re: E.W.Dijkstra: On the foolishness of "natural language programming"

#36
post #34
post #31

Earlier quoted context omitted.

Will get pointed up but just smacks of passive-agressive argumental. History, specifically in science and math is full of examples where people who actively sought to question the knowledge of more senior experts have made discoveries that advanced the knowledge of human-kind and have then been overlooked or ignored because they did not have the correct background. Institutions such as The Royal Society and The Geolo…

The existence of a black swan doesn't imply that swans are usually black. A. "There are examples where newcomers to a field found a novel solution that senior experts have missed." B. "It is often the ignorant who succeeds." B does not follow from A. Not even in mathematics where people use to say that you have to prove yourself worthwhile by the age of 25 or it won't happen. > You have to spend a career following th…

A lesson on logic from somebody who equates "It's often the foolhardy and the ignorant that tackle problems that are supposedly impossible. And sometimes end up succeeding" to "It is often the ignorant who succeeds" seems ironic to put it mildly.

Re: E.W.Dijkstra: On the foolishness of "natural language programming"

#37

"When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong." — Arthur C. Clarke's First Law

To be fair, he doesn't so much say it's impossible as say it's a bad idea.

Re: E.W.Dijkstra: On the foolishness of "natural language programming"

#38
post #22

some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes This is interesting, I think - this is really one of the core parts of the argument between static and dynamic typing. I prefer bondage and discipline to free love when it…

Actually, I don't think this has to do with dynamic vs static typing. It is more about strong vs weak typing, i.e. implicit type casting.

In many dynamically but strongly typed languages (like Ruby), you would still get a type mismatch when you try to add a string to a number at runtime. It's just that with static typing, you would have realized your error much earlier at compile time.

Re: E.W.Dijkstra: On the foolishness of "natural language programming"

#39
post #37

"When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong." — Arthur C. Clarke's First Law

To be fair, he doesn't so much say it's impossible as say it's a bad idea.

Exactly. The grandparent's comment is anything but relevant. While I do agree with it, it is clear it has nothing do with this.

Re: E.W.Dijkstra: On the foolishness of "natural language programming"

#40
post #22

some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes This is interesting, I think - this is really one of the core parts of the argument between static and dynamic typing. I prefer bondage and discipline to free love when it…

Actually, I don't think this has to do with dynamic vs static typing. It is more about strong vs weak typing, i.e. implicit type casting. In many dynamically but strongly typed languages (like Ruby), you would still get a type mismatch when you try to add a string to a number at runtime. It's just that with static typing, you would have realized your error much earlier at compile time.

While I think you're right, my guess is that he had strong static typing in mind when he wrote the article.

Ultimately they lie on a scale. With a dynamic, strongly typed language, you still leave plenty of opportunity to make undetected mistakes. The obvious example is changing the expected type of a method argument, while only updating a subset of the call sites.

Post reply on HN