
On the foolishness of “natural language programming” (1979) - lelf
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html
======
zokier
I really like this quote:

> _some still seem to equate "the ease of programming" with the ease of making
> undetected mistakes_

Conversely you could say that ease of programming is equal (or at least
correlated) with ease of getting confidence of your programs correctness.

On the wider subject of the essay, I do note that languages like APL that
really embraced symbolics for expression do not seem to have gained much
ground, and on the other hand languages that are light on syntax and use more
verbiage like for example Python have been massively popular.

Overall I think the essay also relates to the common idea that naming things
is difficult. The names we give our elements of code imbue the "all sorts of
nonsense that, when we use our native tongues, are almost impossible to
avoid". And how many bugs stem from people making assumptions about things
based on their names because the sort of linguistic ambiguity etc that
Dijkstra is talking about here?

~~~
goto11
I don't think the concern is whether an operation is called "and" or "&". They
are both symbols with unambiguous semantics in the language. Dijkstra is
ranting against the idea of programming using natural languages, with all the
redundancies and ambiguities this entails.

Perl was actually designed to be closer to the nature of natural languages
(despite its reputation as "executable line noise"), and Python was in many
ways a reaction _against_ this, by a having less ambiguities and implicit
context. "Explicit is better than implicit".

I think Perl and AppleScript were valuable experiments in having programming
languages closer to natural language. And what we learnt from the experiment
was that we absolutely does _not_ want that.

~~~
xtiansimon
<shudder> AppleScript was my first self-guided investigation into programming,
and I gave up. Followed by scripting for web with PHP & JavaScript (which is
its own mess). Only with Python was I able to pick up the practice, and then
only because my worked moved into accounting—programming language and
objectives are closely aligned.

~~~
hyperdimension
On the subject of syntax...

</shudder> ;)

~~~
pc86
Probably should have been <shudder />

------
gtsop
Computers don't speak any language, they exexute machine code - instructions.
From assembly, to C, to python, we never made computers understand any sort of
language. We managed to help humans reason about machine code in a manner that
is more convinient to us, that is some text that resembles our natural
languages. But this is the important part, let me repeat this in a different
way: Programming languages aren't stripped down natural languages repurposed
for computer interpretation. Programming languages are abstract machine code
resembling our natural languages.

The meaning of this is that all programming languages will inherently have
features of machine code (even if they are hidden away), else they would be
incomplete, unable to perform all the functions we expect a computer to do.

People now look at code as is today, seeing some english-speak that is not
completely english and think: hmmm well this looks like english but has some
extra syntactic garbage that non-technical people don't understand. What if we
removed all these and made the computer understand pure english? Then everyone
would be able to program.

And this is the moment that the man forgot he is actually looking at abstract
machine code rather than handicapped english.

I find it very interesting that all languages (the ones I've seen at least)
that claim to be for non-technical people achive their goal in a veeery
limited set of applications. As soon as one needs variables and functions (and
that is usually very soon) things get technical fast.

~~~
dbtc
But a programming language has 2 purposes: to tell a computer what to do and
also to tell a human what the computer does. That's why programming languages
are between machine code and human language. Some weighted more one way or the
other, but always some kind of balance.

~~~
thaumasiotes
No, that's why programming languages have syntax for comments.

~~~
bildung
For that to fulfil the second purpose, fixing a comment would fix the code
itself. This obviously doesn't work, so we are back at the beginning: The
programming language also has to be somewhat human-readable to be productive.

------
pdfernhout
Natural language is adapted for many tens of thousands of years to be used by
groups of hunter/gatherers working together on a common task -- which also
includes arguing about related things like assumptions and priorities. In that
context, physically pointing or showing things is important ("put it _there_
"). As is also non-verbal feedback from expressions on people's faces or by
where their eyes are looking. Also, people in the group can ask clarifying
questions, like "What did you mean by X?" or "Can you be more specific?". Or
the speaker can ask, "Did you understand what I said?" When people try to
explain how to do a task without getting immediate feedback on how the
receiver is understanding the communication, one can expect that natural
language instructions will be missing critical information -- or may also
specify unneeded extra information. Ever since I worked in the IBM Speech
Research Group circa 2000, I have felt natural speech could be useful in
programming -- but it will take a different perspective on how to use natural
language as conversation and related creative experimentation to provide a
different experience compared to what people are used to doing with
conventional programming languages. It might be more akin to some aspects of
pair programming perhaps.

That said, a big feature of HyperTalk (used by HyperCard) was that is is
closer to natural language than most programming languages. HyperTalk
supported various alternate phrasings and also the use of the word "it". And
the physical "card" metaphor provided an approachable metaphor for
instructions about manipulating stacks. It is sad that Apple essentially
killed off HyperCard for most users with various marketing decisions as it was
an amazing platform that made programming approachable for many non-
programmers.
[https://en.wikipedia.org/wiki/HyperTalk](https://en.wikipedia.org/wiki/HyperTalk)

And Inform7 as mentioned by someone else here is another example. Although
Inform7 feels more about being read as natural language (when you write is
within strict limits) than about being written flexibly as natural language.

~~~
simonh
The HyperCard language, or a relative of it, still lives on in the form of
AppleScript but honestly it’s a pain to use. The verbosity gets annoying
really fast.

HyperCard seems ok to get something basic up and running quickly, but
variations on it have existed for decades and never proved popular. I think
Excel took over that role as the gateway to programming for many non
programmers.

~~~
TheOtherHobbes
The problem with AppleScript isn't the verbosity, it's the fact that the
verbosity hides the API path model, which is actually quite brittle, obscure,
and poorly documented - possibly because the features were added as an
afterthought to the Accessibility framework, and there is no actual Automation
API.

You spend a lot of time selecting objects or processes, and the syntax can
appear painfully arbitrary with a lot of "Need to know the magic word" code
that you can't improvise from scratch - because you don't know the magic word.

The fix would be to expose the API so users can click on any on-screen object,
and AppleScript fills in the API path for the object.

There's a utility that sort-of does this, but it's very well-hidden and not at
all easy to use.

------
Animats
Ah, that's Dijkstra - programming is hard and programmers should _suffer_.

He's right, though. Natural language is for communicating, not describing.
When we really need to describe something detailed, we need either visuals or
formalism.

~~~
Koshkin
But there are things that can only be fully described using natural language.
Emotions, for example. There aren't any visuals or formalism for those. (And
no, emoticons don't count.) On the other hand, description is a form of
communication anyway, so I fail to see the distinction that you are trying to
make here.

~~~
cibritzio
Just curious why you suggest emoticons are glyphs insufficient for the
communication of intelligence re emotions. They seem an almost incredibly
insightful development in orthography. What earlier alphabetic cultures
expressed so clearly via visuals interspersed among lithographs the essence of
ineffable universal emotions?

~~~
Koshkin
Because a smile is not an emotion.

~~~
cibritzio
But are not emoticons smilies?

~~~
DonHopkins
Emoticons are similes for smilies.

------
mleonhard
Google uses a config language called Borg Config Language (BCL). It is an
extension of GCL ([https://research.tue.nl/en/studentTheses/gcl-
viewer](https://research.tue.nl/en/studentTheses/gcl-viewer) ). GCL was built
with ideas from natural language programming. It is extremely difficult to
learn and use. Errors are very easy to make and hard to detect.
Maintainability is poor.

Some lessons are still unlearned after 40 years.

~~~
pydry
Gherkin/Cucumber/Behave too. All the same problems.

------
dshep
For better or worst, reading Dijkstra always reminds of these funny (I think)
comments that Alan Kay made in 1997...

"Arrogance in Computer Science is measured in nano-Dijkstras" \--Alan Kay

Video:
[https://www.youtube.com/watch?v=9KivesLMncs](https://www.youtube.com/watch?v=9KivesLMncs)

~~~
DonHopkins
[https://www.quora.com/Has-anyone-criticized-Alan-
Kay](https://www.quora.com/Has-anyone-criticized-Alan-Kay)

>Has anyone criticized Alan Kay?

>Alan Kay, Had something to do with "Object-Oriented Programming". Answered
May 3, 2016.

>As Mark Miller mentioned, Dijkstra once said that "Object-Oriented
Programming was such a bad idea that it could only have come from California"!
However, he and I were friendly, so I took that as a backhanded compliment. My
research group at Xerox Parc was known as "The Lunatic Fringe", usually (I
thought) affectionately. I don't count trolls on reddit and slashdot and
elsewhere.

[...]

------
jasperry
I feel Dijkstra kind of undermines himself with the curmudgeonly "kids these
days" remark at the end. Still, he makes a very strong historical argument for
a broader point than the title suggests--for not being in such a hurry to get
rid of formal notation. For some of us, that's preaching to the choir, but I
feel like it could be well aimed today at those who think "IT" has no need for
"Computer Science".

~~~
coldtea
> _I feel Dijkstra kind of undermines himself with the curmudgeonly "kids
> these days" remark at the end_

Not necessarily. The idea that "kids" across generations are always either the
same or improving across times and cultural changes is an even bigger cliche
than "kids these days".

Dijkstra in this, as is made clear from the context, case doesn't even talk
about kids (people) in general, but about a specific subset: educated people.

So, while more people get an education than ever, and you could find total
illiterates in greater masses in e.g. 1900 than when Dijkstra wrote this,
there's also a decline in many aspects between a university graduate of 1950
and a graduate of say 2020. Part of this is because in the 1950 university
degrees where rarer, and thus more demanding and elite.

But it can be true even for graduates from colleges that remain highly
selective (Yale/Harvard 1950 vs Yale/Harvard 2020).

One example might be a CS degree with C/Assembly or Lisp and SICP vs one with
some Java "market-driven" introductions to programming... One makes computer
scientists, the other is a glorified job training program...

~~~
rowanG077
I wouldn't be so sure that that 1950 university degrees were more demanding.
More rare and elite, definitely. But it wasn't really intelligence or drive
that made sure you could go to university. It was whether your social standing
allowed it.

~~~
Gibbon1
My dad borrowed a couple of my engineer books. He said they had more material
and harder problems than his old college books did. Also my instructors said
they fretted about trying to figure out what to teach out of the ever growing
body of work. When my dad went everyone graduated in four years. When I went
was more typical to graduate in 5 to 6 years. And they worried that they
wouldn't have enough four year students to meet accreditation requirements.
Same time I never heard my professor complain about the poor quality of
students.

------
mhh__
In the same sense that the data structures are generally more important than
the code, I think the "quality"-axis is around some combination strictness,
semantics, and safety rather than the syntax.

I may be outspoken in saying this, but I try to avoid Python wherever possible
because - although I like the syntax - I am quite worried about having to
trust other humans to enforce semantics rather than a compiler. If something
ill-formed is in my program, I want to know about it before it starts running
rather than 5 hours into execution. I have the same opinion of C, too.

In an ideal world where we could all sit around and plan our programs from
scratch, I would love to program in a pure functional style - but this isn't
really possible half the time: I try to minimize as much global (or even
local) mutable state as possible, especially now that progress in execution
speed is incremental and the growth is probably going to be in our ability to
use concurrent execution.

Python is supposed to faster to get going, and maybe it is compared to C++,
but even then C++ can express things that can only be done with writing tests
in Python (for free). There is a trade-off in that I've spent years honing my
skills now, but is it that hard (It's quite hard to be holistic when teaching
programming, I'm slightly glad I figured most of it out myself)

------
amelius
Maybe natural language should become more like programming languages instead
of the other way around. I suppose this could be especially useful in e.g.
legal circles, where ambiguities are problematic.

~~~
euske
Maybe not this extreme, but we can use natural language as more like
programming languages (by reducing vagueness).

Corollary of this: we should mandate that politicians and officials all learn
programming language and speak rather like programmers, so that they can say
less BS.

~~~
dragonwriter
> we should mandate that politicians and officials all learn programming
> language and speak rather like programmers, so that they can say less BS.

I've rarely met anyone who uses natural language as imprecisely as most
programmers, so I'm not sure that you want what you literally describe.

Also, politicians (at least in the US) are disproportionately lawyers, who
happen to be professionally trained in the precise use of natural language.
They often use this, when they aren't outright lying, to say things that make
very different commitments than casual listeners not themselves trained in the
precise use and interpretation of natural language will initially interpret,
so what you really need is to train their _audience_ in critical listening.

~~~
pydry
>I've rarely met anyone who uses natural language as imprecisely as most
programmers

I've rarely met a good programmer that didn't communicate with precision.

Ive met lots of bad programmers who write unreadable code though, who couldnt
communicate clearly by speech or writing either.

------
sigsergv
Natural language is so opaque term. You need to establish context (vocabulary,
relations, rules) if you want to pass some information to another person. The
same phrase could have different meanings in different context. And from this
point programming language is just another context.

------
dang
If curious see also

2014
[https://news.ycombinator.com/item?id=8222017](https://news.ycombinator.com/item?id=8222017)

2010
[https://news.ycombinator.com/item?id=1913308](https://news.ycombinator.com/item?id=1913308)

2008 (1 comment)
[https://news.ycombinator.com/item?id=233780](https://news.ycombinator.com/item?id=233780)

------
cs702
_> It may be illuminating to try to imagine what would have happened if, right
from the start our native tongue would have been the only vehicle for the
input into and the output from our information processing equipment. My
considered guess is that history would, in a sense, have repeated itself, and
that computer science would consist mainly of the indeed black art how to
bootstrap from there to a sufficiently well-defined formal system. We would
need all the intellect in the world to get the interface narrow enough to be
usable, and, in view of the history of mankind, it may not be overly
pessimistic to guess that to do the job well enough would require again a few
thousand years._

This is highly relevant now that we have information processing systems that
can be -- and are being -- programmed in our native tongue, or natural
language, such as GPT-3.

------
astrowar
inform 7 is an example of programming in natural language. It specializes in
solving a single problem and being more of a set of statements than a place to
write algorithms. Even so, ambiguity problems in writing are complex and
require constant consultations with the documentation to know which sentence
is valid for which situation.

~~~
Jtsummers
Inform 7 is a natural language DSL for a rather narrow domain (interactive
fiction). Dijkstra's discussion in this letter is probably from the general
(at the time and recurring) discussion of general purpose natural language
programming. That is an important distinction to keep in mind.

------
sytelus
Natural language is designed for describing state of natural objects and
events. Traditional programming is so much more abstract. It's super hard to
describe what is an array or dictionary. Two people can agree how heavy an
apple may be but they could not agree what exactly is an array. We grow up
interacting with apple and its what nature designed for us. We don't grow up
talking about arrays, they are purely imaginary abstract concept. This is why
it is very hard to write quickshort algorithm in English than it is in
pseudocode.

But things are changin now. It is increasingly possible to take natural
language constructs that can compose low level primitives through _program
synthesis_. That is, AI can write lower level while we dictact higher level.

------
NAR8789
Natural language is ambiguous, sure, but natural-language programming already
exists. I suspect most readers of HN are already very familiar with it.

Dijkstra is of course right that you can't replace the precision of formal
languages. Precision allows you to "one-shot" a spec. For simplicity, consider
just machine code. A compiled program, given to the right machine, is a sort
of message that can be delivered unidirectionally and understood perfectly.
From the perspective of natural languages, that is nothing short of a miracle.
Can you think of a case where you said something mildly complex and were
understood perfectly, the first time, without questions and clarification?

To drop the need for formality and precision then, the tradeoff is this: we
must program by conversation; the compiler must be able to talk back and
collaborate with the programmer to "discover" the program spec. This is not
talking back in the sense of waiting for input or mouse events--at that point
we are already running the fully compiled program. Remember, this conversation
is replacing the work of writing the program. We want something that
substitutes for the information content of the compiled binary, that "single
message" I can send to a computer to tell it unambiguously what to do.

Programming by conversation ends up being a kind of iterative programming by
trial-and-correction. \- Programmer says, "I my windows to automatically close
when it's raining, and open when the sky is blue." \- Compiler: "I can almost
do that, but what about when it's both raining and the sky has patches of
blue?" \- Programmer: "That can happen?" \- Compiler: "It's kind of
counterintuitive, but it happens occasonally" \- Programmer: "Well when that
happens just keep the windows closed" \- Compiler: "Ok, but what about-" \-
Programmer interrupts: "Do the other edge cases happen often?" \- Compiler:
"Maybe 0.1% of the time." \- Programmer: "Ignore them and just let the system
crash and call for help--I can just come work the windows myself those days"
\- Compiler: "Sure, I'll just need to ziptie a few motors to the windows like
so, and-" \- Programmer: "Whoa whoa, can't we make it prettier?" \- Compiler:
"I guess... gonna take a while though" \- Programmer: "Oh, well I'm in a
hurry. Ziptied motors it is!" \- Compiler: "Ziptied motors it is!"

You've seen this conversation before. You've had this conversation before.
You've met and interacted with programmers who use this "natural language
programming language".

We call these programmers "Product Managers". You are deeply familiar with
natural language programming, because you are the first compile-step in the
build chain. You, the "programmer", are a very-high-level conversational code
editor.

Joking aside, any "natural language programming language" would probably need
to operate in some kind of conversation format. Still probably immensely
complex to build, and Dijkstra's point about ease of expression stands strong
--some things are much, much faster to say in formal language rather than by
having a slow conversation that whittles away the ambiguities, and it
increases the amount of work from both Programmer and Compiler (conversations
take mental energy!). But whittle away ambiguities we nonetheless can.
Building a synthetic programmer is certainly a very far away goal, but
"foolish"? Maybe, maybe not.

------
stevebmark
It’s great how far English has come from this kind of terrible writing. It’s
indirect, condescending, and hard to follow. We’ve become more direct speakers
and looking back at this is a great example of how not to write.

~~~
NateEag
I wish more people wrote as clearly and directly as Dijkstra.

You must know a lot of literary geniuses, because I don't know many who come
anywhere close to it.

------
torgian
This was a fascinating read

------
MaxBarraclough
> it has been proposed (to try) to design machines that we could instruct in
> our native tongues. this would, admittedly, make the machines much more
> complicated, but, it was argued, by letting the machine carry a larger share
> of the burden, life would become easier for us.

> I suspect that machines to be programmed in our native tongues - be it
> Dutch, English, American, French, German, or Swahili - are as damned
> difficult to make as they would be to use.

Seems to me there's a intermediate step here that's worth mentioning: formal
specification languages, such as _Z notation_ and _Event-B_ , which let us
precisely describe our problem. [0] If you want a 'compiler' to be able to
deal with a natural language request like _Give me a C function that sorts an
array of uint32_t, of arbitrary length, in place_ , you have two challenges:

1\. Automatically map the natural language problem-description to a precise
formal specification of the problem, in a language like Event-B.

2\. Automatically map the formal spec to an efficient and correct
implementation in C. (This is called _refinement_. For an example, see [1].)

Formal specification languages are rarely used in today's software
engineering, but it would make sense to use one in an automated system, to
separate out these two very different challenges. (Needless to say, automating
either of these stages is enormously challenging, and we're nowhere near
accomplishing either of them.)

Ideally, stage 1 would warn or error about the ambiguity in the example
request: most likely the user wants an ascending ordering, but this should be
made explicit in the request.

Would such a system be _useful_? I think the answer is yes regardless of what
precisely is meant. I don't share Dijkstra's concerns. We already know it's
possible for _humans_ to do effective software engineering, and the question
here is really one of what an automated system would have to do to compete
with that. Managers already make software happen using natural language! I
don't think a comparison to attempts at spoken-word mathematics are all that
relevant.

A computer simulation of a skilled software engineer, including being a good
conversationalist with requirements-engineering skills and the ability to
absorb domain knowledge, would be useful by definition, and would put software
engineers out of a job at a stroke. Would it be useful to have the weaker
system Dijkstra describes, that 'compiles' a natural language specification?
Seems clear enough that it would, as much human effort is currently spent
doing this. Assuming the system works well, and isn't unworkably pedantic or
obtuse, it would still be extremely valuable.

> As a result of the educational trend away from intellectual discipline, the
> last decades have shown in the Western world a sharp decline of people's
> mastery of their own language

Is this actually true, or is this one of those _back in my day children were
respectful_ things?

[0]
[https://en.wikipedia.org/wiki/Specification_language](https://en.wikipedia.org/wiki/Specification_language)

[1] See chapter 7 of this large PDF:
[https://eprints.soton.ac.uk/422225/1/Thesis.pdf](https://eprints.soton.ac.uk/422225/1/Thesis.pdf)

------
ebg13
I find that Dijkstra's essays often rub me the wrong way. He readily admits
that high-level programming languages are a huge improvement over machine
code, and then says (I'm paraphrasing) "BUT YOU MUST NOT TRY TO GO FURTHER".
What?! That's just crass!

Here it's like he's buried his head in a bucket of sand ensconced safely in
his ivory tower, never having to interact with real people who have real
desires for real things that could be solved with real programs if only baking
apple pies from scratch didn't first require inventing the universe.

The first two sentences show this well, where he conflates dreaming of a more
interesting future with blaming the machine for being just a machine.

> _They blamed the mechanical slave for its strict obedience_

They just want a more forgiving interface that makes developing programs
easier and they're probably frustrated that it doesn't exist. That's not the
same as blaming the machine. Like, at all. That's blaming _us_ for making
obscene devices that you can't program without a fuck ton of training and
practice.

How has one of the fathers of modern computer programming forgotten about the
value of layers of abstraction and interactive feedback?

He's dismissing the very same drive that causes us to write libraries and
wizards and not just programs. It's the reason why we can now just magic up
GUI windows and shit without having to think _at_ _all_ about what it actually
means to construct blobs of pixels that can resize and move around and scroll
and receive clicks and blink and marquee and and and. It's why we can now send
an email to our friend Jeff in one line of new code and have it actually work,
because there are thousands of other lines of code behind the scenes doing the
work for us that we don't have to even think about most of the time.

Would it really be so bad to try to keep going further down that road? To add
abstractions for using real human sentences as well?

Would it be so terrible if we could one day say "make a window called 'my
window', and put a button in the lower left, and when I click on it play a
trumpet sound" (with default behaviors for size and padding and fonts and
stupid shit like that that normal people don't actually care about) instead of
having to copypaste a thousand lines of greek from some website?

Is it really so hard to imagine that a billion people are newly able to
satisfy a billion simple desires over night every time we remove a small piece
of that _need_ for always using bullshit symbols with unhelpful machines? That
"but it won't automatically be precisely X" is a stupid programmer thing that
only programmers say?

Is it hard to do? Yes. Would it be bad if we did it? Wtf, no.

~~~
simonh
I think you’re mischaracterising his argument. His problem isn’t with further
layers of abstraction, it’s with people complaining that those layers of
abstraction still need to be strictly and unambiguously defined.

~~~
ebg13
Except that the higher up you get with your needs, regular person needs, where
instead of constructing universes from subatomic particles you place pre-fab
buildings, the less ambiguity matters. If I want, say, a window that adheres
to the standards of the system and don't want to fuck about with fiddly shit
that only programmers care about, the amount of acceptable ambiguity in the
directive should be much higher.

Because, for one thing, if my cognitive requirement is transformed from a
thousand directives to one higher order directive, I suddenly have energy and
time for clarifying dialogue and exploration of presented options.

Like...right now I can google "email program" and be recommended an email
program to download where I just click a button and suddenly I have a new
email program installed. And that's even with google trying to organize
literally everything being said online and being constantly bombarded by
blogspammers and other malicious actors. It should not be horrifying to anyone
to desire being able to program computers that way too.

------
ris
Bookmarking this to point rubyistas at.

------
jimbob45
Ironically, natural language makes finding documentation extremely difficult.
If you’re SQL problem revolves around the keywords “USING”, “HAVING”, or
“WHERE”, Bing is going to really struggle to find you results. If, instead,
you’re looking for strcpy, nearly every result will be relevant with little
effort.

~~~
drunkpotato
I just went to bing.com and typed `sql using` into the search box. The results
were relevant. I tried again with google and duckduckgo. Same. I wonder if
perhaps you are overestimating the difficulty here.

~~~
jimbob45
Easy searches like that will work but you never need help on the easy queries.
It’s in the complex queries with keywords modifying keywords where the issue
arises.

~~~
wizzwizz4
I have yet to succeed in getting my search engine to help me with debugging
something like:

    
    
      colordiff -d -c3 <(wget -U "" -O /dev/stdout "https://www.microsoft.com/en-gb/servicesagreement/" | tidy) <(wget -U "" -O /dev/stdout "https://www.microsoft.com/en-gb/servicesagreement/upcoming.aspx" | tidy) | less -R
    

SQL statements have the same problem; it's not their use of English-like
words, it's the fact that SQL statements are _programs_ and not mere
_commands_.

