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.

<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.

I've heard far too many cs profs/TAs proclaim that "you get it or you don't" -- that either students come in with some innate ability to program, or they're a lost cause whose role in life is to bring down the cost of education for those worthy of it. Y'know, curmudgeons like Dijkstra. My response to this is generally that one can teach, or they can't, and that blaming the student is intellectual laziness. Also that they probably got their job on research talent and not teaching ability.

I was the same way with math. Stank at it 'til the context was right.

On the subject of syntax...

</shudder> ;)

Probably should have been <shudder />

Dijkstra considered you harmful! ;)

Indeed, Confucious himself recognized this issue and spent an enormous amount of effort on the “Rectification of names”, that to this day is still a major sticking point in any major endeavour. Which goes to show the challenges inherent in human languages.

Also, “Every historical event begins with a struggle centered on naming.” - Milun Kundera

I suppose it's not so easy to rectify the names we find in computing. It's a highly abstract field and also relatively young. It's really hard to come up with names for concepts which don't actually exist yet. We ended up with terse jargon at best and generic, sometimes incorrect names at worst. I think Scheme is the language with the cleanest symbol names and even in that language we find aggravating abbreviations such as the true and false symbols, all the different equality procedures and other historical Lisp jargon.

In science and medicine people seem to just make up new words using latin or greek roots. Things are often named after the people who discovered them. It's very inconsistent. Any attempts to fix it by introducing better names inevitably results in the new generation having to know all of the names. Some professors will even quiz students on obscure names nobody cares about anymore.

I wonder how mathematicians, physicists and engineers come up with names...

Mathematicians are happy to make up names from words with little or no comprehensible connection to the concept, such as Ring, Field, Magma, Group. That, or they name things after people, which is equally impenetrable. Doctors and biologists either name something after people, too, or create a Lego-word out of Classical roots which more-or-less describes it.

I wish it were (more) acceptable to use made up words, like medicine does. Once you know the base morphemes in greek/latin, it's really easy to decode medical jargon. You'd need to augment the list with a bunch of technical terms of course.

It would be cool to have a tiny vocab (a la Toki Pona) of say 256 single-syllable morphemes of 1-2 consonants and 1-2 vowels.

SimpleBeanFactoryAwareAspectInstance -> Haplefaesthamon

Of course this is probably appealing to conlangers and language nerds, and horrifying to everyone else.

Maybe the long name is a clue this monstrosity simply shouldn't exist?

The problem is not the number of letters used, but the number of ideas attached to one identifier.

Actually making compound words works in many natural languages by itself. It's just obscured in English due to its nature as a near-creole: it has lots of loan-words all over the place, so it's less obvious how you can mix-and-match. (And it's less obvious how the loan words themselves might have been mixed and matched in the first place)

In Greek, Latin, French it's much easier to make compound words already.

Dutch does it a bit too, and German is quite famous for it. People actually make up words on the spot, and other people can easily infer the meaning.

I learned this the hard way while training a natural language "AI". People just do it in their day-to-day use of those languages.

In any case, I don't think you need to make up new morphemes for English, it has too many already from all the languages it's been borrowing from. Drawing from the extant pool would be quite adequate for me!

> It would be cool to have a tiny vocab (a la Toki Pona) of say 256 single-syllable morphemes of 1-2 consonants and 1-2 vowels.

I'm sure the Urbit people will be by to explain that this is being worked on for Hoon, and email me now and I'll get you set up with a planet.

My father was a linguist. He one time suggested that I program in Lojban, as the logical aspect of it would be much easier to understand than the symbol-soup he perceived in what I was using.

He meant well.

> I wonder how mathematicians, physicists and engineers come up with names...

It might be outsiders view, but I feel like in their formalisms mathematicians fall back to single character "names" for lots of things, or maybe single character + subscript. That conveniently side-steps the issue of naming things, and I think it was what Dijkstra was referring to in his essay.

Additionally, within the scope of any one field or sub-field, you get a nice constant-factor boost by exploiting capital/lowercase, italics, bold-face, "chalkboard" font, etc. and usually that suffices. Anyone who has taken a linear algebra course instantly recognizes what I mean by "Solve Ax = b" in the appropriate context. And if I say "Solve Qx = b" you have even more information, etc.

Yes single letters but using greek, latin, fracture, small and capital. Only small fracture is rare though.

> I wonder how mathematicians, physicists and engineers come up with names...

Mathematicians simply name everything after Cauchy. https://en.wikipedia.org/wiki/List_of_things_named_after_Aug...

Well engineers and physicists can get around the naming issue by being very verbose. If an idea requires concepts from 5 different words to properly express then usually the whole 5 word phrase becomes the accepted nomenclature. The exceptions are usually when the preexisting words contain really different alternate meanings.

This is the precise insight that jumped out at me.

I often get raised eyebrows when I state that, by my definition, Python and Javascript are among the mostly brutally difficult programming languages out there.

Python is a wonderful candidate for one-off tooling and experimentation, particularly because the cost of wild explosions in these cases, and the odds of requiring long term maintenance, are rather low. However, if your plan is to hire fresh college grads, hand them a Python 2.7 interpreter, and ask them to a build a mission critical, 200k+ line, product - that just seems professionally negligent.

> 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

Comparing APL's popularity to Python's and assuming the difference is due to solely to an embrace of symbolics for expression does not take into account the many differences of the languages.

APL had barriers to entry that Python didn't; for example, APL cost money (you had to license it from IBM) and you needed a special keyboard. Python didn't. (Later versions of APL didn't require a license or keyboard).

APL was good at numbers, poor at I/O (I'm generalizing). I wouldn't want to write a webserver in APL; I'd use Python, but if I was doing matrix multiplication, I'd use APL. Or maybe a tool like Octave or Matlab.

There are APL variants like J and K, which use ASCII and have enjoyed limited success too; but those who do use the language tend to be very good at at.

I guess people just don't really want to learn a new language, which is what APL and its derivatives really are.

That assertion seems highly dubious to me given how many other new languages have been created and learned in the meantime. It would be more interesting to look at why people felt those languages were more appealing - some of that has obvious financial draws (Java, JavaScript, C#, etc.) but nobody picked learning e.g. Haskell because it was the easiest option.

Light on syntax? Python?

Oh, you mean light on symbols in the syntax. Python has a ridiculous mess of syntax, but it's mostly in the form of words.

Python is quite light on syntax compared to several other scripting languages (Ruby and Perl/Raku come to mind.)

Python has syntactic sugar, but Perl has syntactic syrup of ipecac.

https://en.wikipedia.org/wiki/Syrup_of_ipecac

Sometimes the Perl sugar is pretty sweet, though.

  my %h1 = ("xyz" => 2);
  my %h2 = ("abc" => 9, "def" => 3);
  # hashmap from Hash::MostUtils
  my %hash = hashmap { "$b-$a" => $a * $b } 
             %h1, %h2, "eieio" => 0, "abc" => 1;

  # "0-eieio" => "",
  # "1-abc" -> "abc"
  # "2-xyz" => "xyzxyz"
  # "3-def" => "defdefdef"