> 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?
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.
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.
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!
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.
> 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.
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.
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.
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.
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.
That does not make sense to me. Surely I could apply the same logic to any supposedly thinking thing, including humans. If I could capture all the physical processes that your brain / body confirms, I can perform all of those on paper. Thus I can perform the same thoughts as you. However, I don’t understand you in any way - I can’t tell what or how you think from intermediate states in the process.
This argument only works if you don’t believe that the physical processes are all you are and a perfect reproduction could do the same.
I have my own theory of why that capture isn’t possible, but that doesn’t matter for the Chinese room argument.
The other interpretation of this thought experiment (and maybe what you alluded to) is the idea that humans, and all living things with a nervous system, are really just "meat computers." Processing inputs and outputs using the cascading electrical signals, swapping circuits for neurons. The technical name for this philosophy of thought is called computationalism, or the computational theory of mind (CTM). The term was used first around the 1940s as digital electronics were starting to gain traction (precursor to the AND gate, the Coincidence circuit, being documented ~1920s). I think that this type of philosophy appeals to software and hardware minded people because of the lens through which they choose to view the way the world works.
Thanks for this resource, I've been thinking that software engineers tend to falsely look at people as "meat computers" but wasn't aware of that philosophical branch. I can now research this school of thought easier.
Yeah and in essence, just because the thing can communicate with you, doesn't mean it understands you.
Especially when you consider all you have to do is follow a "translation layer" to repeat steps to produce an output, then it doesn't mean anything is understood. Just a "thing" that can follow steps consistently to produce a result.
It is quite an interesting concept when considering at what extent is there anything actually translated in any system that is understood or just an interface to reproducing an algorithm based on some consistent logic?
No, it's why dissecting a human looking for its general intelligence is a waste of time. You won't find an atom of the stuff. The "person" is a process running on the hardware, not the hardware itself. Searle's position is only different from Descartes' dualism in vocabulary.
No it isn't. The mistake Dijkstra - and everyone else - makes is assuming the code has to be a complete description of the algorithm used to solved the problem.
Algorithms are fragile and have edge cases, so of course you can't specify an algorithm without a formal algorithm description language.
But if you have an AGI that can infer intent and has contextual awareness, domain-specific knowledge, and a complete library of previous conversations and their resulting solutions, the problem stops being so problematic.
Especially if the AGI can ask questions about your intent if your specification is still ambiguous. Even more so if it can research and explore a large improvised solution space and use its own heuristics to find the most robust solutions.
So natural language programming will be very much be a thing in the future. But not for quite a while yet.
You are "proving" we are wrong by "assuming" the existence of a solution. This is a falacy.
I would also argue that contextual awareness of a computer will never resemble the contextual awareness of a human being. That is because contextual awareness can only be derrived by actively participating in a culture, inherent attribute of human beings and not a thing computers can do.
However, even if computers came to have contextual awareness as a human (again, i don't believe this is possible) that is something we would not want. Cultural differences produce different interpretations out of the same input. Example: Is it ok for a guy to get married with 10 women? Depending on your location on this world, the answer WILL be dofferent. Do you really want computers to interpret and (more importantly) act on their own based on some sort of contextual awareness they came up with? I'd say not.
Actually if an AGI has access to previous conversations it might just get utterly confused. So is 'goto considered harmful' or can you have 'structured programming with go to'. Probably real people also get confused thats why nobody reads this stuff.
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
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.
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.
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.
Thanks for the question (and indirectly an example of my main point on natural language as dialog). Sorry for not being clearer. I did not mean the words themselves. I mean the neural circuitry in humans for language.
Also related: "Researcher Responds to Arguments Over His Theory of Arguing" https://artsbeat.blogs.nytimes.com/2011/06/15/researcher-res...
"The main idea of the “argumentative theory of reasoning,” put forward by Dan Sperber and myself is that the function of human reasoning — why it evolved — is to improve communication by allowing people to debate with each other: to produce and evaluate arguments during a discussion. This contrasts with the standard view of reasoning — apparently shared by quite a few of the readers — that reasoning evolved in order to further individual reasoning: to make better decisions, to plan ahead, to get better beliefs, etc. ... We do not claim that reasoning has nothing to do with the truth. We claim that reasoning did not evolve to allow the lone reasoner to find the truth. We think it evolved to argue. But arguing is not only about trying to convince other people; it’s also about listening to their arguments. So reasoning is two-sided. On the one hand, it is used to produce arguments. Here its goal is to convince people. Accordingly, it displays a strong confirmation bias — what people see as the “rhetoric” side of reasoning. On the other hand, reasoning is also used to evaluate arguments. Here its goal is to tease out good arguments from bad ones so as to accept warranted conclusions and, if things go well, get better beliefs and make better decisions in the end."
I don't have the time for a more specific reply, but please understand that the epistemic uncertainty related to anthropology, evolutionary biology and psychology ought to be always high. This is very different from physical/natural sciences where a single experiment can often determine to very low epistemic uncertainty (or at least with bounded model error) some working model. This evidence may exist (say with uncontroversial genetic evidence and uncontroversial say neural models), but for most discussions in those fields it's usually not available (and would be very costly).
This is why you have to take it as an ongoing discussion and everything as a hypothesis. You can't say "Human language evolved to argue, not to make better decisions", or any similar assertions, with almost any certainty. It's a point of an ongoing conversation. The hypotheses themselves don't always lend themselves to formalization the same way as the natural sciences. Of course any science strives for as much precision as possible though! Simply in practice anthropological and psychological phenomena are even harder or impossible to formalize in the sense of mathematical precision, at least non-trivial observations; the little I understand of those fields they go to great lengths to reduce and communicate uncertainty (this includes History as well, where it seems a core concept of the canonical research methodology[1]).
Because part of the reason we develop those theories and those fields in those places is to better understand ourselves and put them to practical use, particularly in practical use (when thinking about thinking, or how to interact with people, etc.) this uncertainty shouldn't be forgotten -- more as an inspiration than strict guidelines for human behavior.
I took me a while to understand this, and the subtle differences between the different fields of study!
[1] In history research, I believe you rarely hear "Such and such happened..." (unless there's overwhelming evidence), and more likely hear "According to [e.g. some Greek historian] in [such account], such and such happened...", historical records are understood to be unreliable.
> We claim that reasoning did not evolve to allow the lone reasoner to find the truth. We think it evolved to argue.
Argue over what?
One can easily argue (npi, and I will) that reasoning evolved in the individual to aid understanding, to comprehend. You first need to hold a point of view before you can argue that position and collectively reason about an object.
You seem to give legs to your position by substituting "truth" for "understanding". A reminder that we humans collectively have "understood", "communicated", and wrote tomes on all sorts of falsehoolds. Reasoning has nothing to do with "truth" in principle.
About why language gave us an evolutionary advantage, there’s another hypothesis than the informational/hunting one (and it has much more explaining and predicting power in my opinion), the Dunbar’s one:
Dunbar's suggestion],"then, is that language evolved as a 'cheap form of social grooming, so enabling the ancestral humans to maintain the cohesion of the unusually large groups demanded by the particular conditions they faced at the time."
"In other words, did language evolve tofacilitate the exchange of technological infor-mation (with gossip as an idle by-product), ordid it evolve to facilitate the exchange of socialinformation (with the exchange of technologicalinformation as a useful by-product)?"
Human language is full of imprecision that lets two parties disagree without coming to blows, or one party to achieve a coup over the other.
There are a number of reasons legal documents bear only a loose resemblance to spoken language, but an important one is because they are closer to programming than they are to literature. They're trying to nail down all of the boundary conditions so that asymmetric information doesn't result in excessive harm to either party in the agreement. So one party can't use a Trojan or a 0-day exploit against the other.
And every time they discover they've screwed it up, the language becomes a little more stilted.
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.
He's got an anti-visual-programming rant in the archive as well, although I'm having a hard time remembering the keywords to find it with, perhaps because all who seek Dijkstra's wisdom must also suffer.
I doubt Dijkstra would have objected to a visual formalism that was, well, formal. Something like Peirce's existential graphs[1] for example. Dijkstra despised sloppiness, probably as a consequence of growing up in a war-ravaged country where his group could only manage to beg an hour a week of computer time from the Americans.
As you imply, the EWD is a treasure. I've read through the vast majority of the English language ones and it has deeply improved my understanding of "Computing Science." I personally enjoy his non-technical writing too, abrasiveness and all, but I know that's not to everyone's taste. If it isn't, it's easily skipped. I do wish I had some Dutch though to get the bits I missed.
Edit:
> He's got an anti-visual-programming rant in the archive as well
It just occurred to me to ask, is this the one where he argues that any visual description by its nature overspecifies? That's one of the recurring themes in his work, specify everything that needs to be specified, but no more. Of course even a vector of glyphs is still in the end a visual representation, so things are always overspecified. For example a + b and b + a are, in some languages, exactly equivalent and it would be nice to be able to directly represent that rather than having it require additional knowledge of the semantics.
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.
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?
If I say the word ‘ellipse’ (in French) you’d be hard pressed to know if I mean an oval or an omission. You can only know that from context.
Body language works exactly the same, the exact meaning of a smile by itself is ambiguous, as it’s built from context.
Adding back information previously lost via traditional sentence serialisation in text medium through text emoticons, graphic emojis, and other annotations (like /s) conveys this information which might entirely change the meaning of the sentence; emotion is completely tied to the semantics and critical to understanding.
To me it looks a lot like didascalies (stage direction notes) in theatre play texts.
I've never suffered so much as when programming in Applescript, which was supposed to be natural language programming. (Or for that matter, when trying to communicate with voice assistants, which are supposed to be natural language processing, but would be much easier to work with if they came with a list of keywords they understand)
Google uses a config language called Borg Config Language (BCL). It is an extension of GCL (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.
>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.
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".
>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...
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.
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.
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)
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.
For as long as the concepts that words refer to remain ambiguous for general discourse, there's not much use for a grammar that can only indicate extremely specific relations. Well, except in, say your example of a legal domain, where a specialized language (legalese) comes into service.
Legalese is unambiguous? I have never seen any of that and we spent millions on legalese (as a company and being a company owner). It's always full of holes and difficultly written but easily confused language that you can interpret in many ways (and that happens exactly when in court by the opposing lawyers). Good or bad, but unambiguous it's not. Maybe Lojban or a fuzzy programming language could work.
> It's always full of holes and difficultly written but easily confused language that you can interpret in many ways (and that happens exactly when in court by the opposing lawyers).
This sounds exactly like code.
It's one place bugs come from - the human who wrote it interpreted the code differently from the human who wrote the language they used. See JS's implicit global vars for a classic example.
And before someone says, "But that's human error; programs have only one valid interpretation," let me remind you of undefined behavior. It exists and is used in defining the C language (yes, it's one reason people don't like C, but since C is the substrate for a whole lot of other languages, it's hard to avoid at the moment).
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.
> 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.
> "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."
Unrealistic since most programmers I've met can't even manage to put together a logically coherent document or presentation without a lot of prompting.
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.
> 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.
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.
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.
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.
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.
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.
> 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?
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.
> 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?
Applescript reads kind of like this.
It's interesting to read but a terrible pain to learn, and as you get deeper into it, it still retains the subtle gotchas native to every programming language I've touched. There are always weird implications that you don't see until they bite you or someone points them out to you.
Which, I think, touches on the case Dijkstra is making here.
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.
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.
What's a window? What's a Trumpet? Lower Left of what? How long should I play the music? Don't like the music that's played, oh too bad now you have to go one level deeper.
Don't like the color of the button. Shit now we have to go another level deeper.
When I click the button the trumpet doesn't play. Oh shit, now we have to go really deep
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.
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.
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.
> 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?
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.
I was the same way with math. Stank at it 'til the context was right.
</shudder> ;)
Also, “Every historical event begins with a struggle centered on naming.” - Milun Kundera
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...
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.
The problem is not the number of letters used, but the number of ideas attached to one identifier.
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!
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.
He meant well.
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.
Mathematicians simply name everything after Cauchy. https://en.wikipedia.org/wiki/List_of_things_named_after_Aug...
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.
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.
I guess people just don't really want to learn a new language, which is what APL and its derivatives really are.
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.
https://en.wikipedia.org/wiki/Syrup_of_ipecac
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.
Input Function(input) { Something needs being done with input } Output by calling Function
It is what the computer does and it is what the human writes, even if it gets re-translated along the way.
Replace Chinese with language as an interface between humans and computation / AI even.
This argument only works if you don’t believe that the physical processes are all you are and a perfect reproduction could do the same.
I have my own theory of why that capture isn’t possible, but that doesn’t matter for the Chinese room argument.
Especially when you consider all you have to do is follow a "translation layer" to repeat steps to produce an output, then it doesn't mean anything is understood. Just a "thing" that can follow steps consistently to produce a result.
It is quite an interesting concept when considering at what extent is there anything actually translated in any system that is understood or just an interface to reproducing an algorithm based on some consistent logic?
Fun stuff to me.
You can. The Chinese Room wants to be an argument against AI, but if you take it seriously it's an argument for solipsism.
Programming is fundamentally too technical to be able to elegantly replace with speaking/typing sentences in layman's terms.
Algorithms are fragile and have edge cases, so of course you can't specify an algorithm without a formal algorithm description language.
But if you have an AGI that can infer intent and has contextual awareness, domain-specific knowledge, and a complete library of previous conversations and their resulting solutions, the problem stops being so problematic.
Especially if the AGI can ask questions about your intent if your specification is still ambiguous. Even more so if it can research and explore a large improvised solution space and use its own heuristics to find the most robust solutions.
So natural language programming will be very much be a thing in the future. But not for quite a while yet.
Well sure, but we don't know when that's gonna happen, if ever.
I would also argue that contextual awareness of a computer will never resemble the contextual awareness of a human being. That is because contextual awareness can only be derrived by actively participating in a culture, inherent attribute of human beings and not a thing computers can do.
However, even if computers came to have contextual awareness as a human (again, i don't believe this is possible) that is something we would not want. Cultural differences produce different interpretations out of the same input. Example: Is it ok for a guy to get married with 10 women? Depending on your location on this world, the answer WILL be dofferent. Do you really want computers to interpret and (more importantly) act on their own based on some sort of contextual awareness they came up with? I'd say not.
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
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.
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.
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.
Is this the case?
I don't know much about languages, but I can't even recognise earlier version of my native language from a few centuries ago.
Also related: "Researcher Responds to Arguments Over His Theory of Arguing" https://artsbeat.blogs.nytimes.com/2011/06/15/researcher-res... "The main idea of the “argumentative theory of reasoning,” put forward by Dan Sperber and myself is that the function of human reasoning — why it evolved — is to improve communication by allowing people to debate with each other: to produce and evaluate arguments during a discussion. This contrasts with the standard view of reasoning — apparently shared by quite a few of the readers — that reasoning evolved in order to further individual reasoning: to make better decisions, to plan ahead, to get better beliefs, etc. ... We do not claim that reasoning has nothing to do with the truth. We claim that reasoning did not evolve to allow the lone reasoner to find the truth. We think it evolved to argue. But arguing is not only about trying to convince other people; it’s also about listening to their arguments. So reasoning is two-sided. On the one hand, it is used to produce arguments. Here its goal is to convince people. Accordingly, it displays a strong confirmation bias — what people see as the “rhetoric” side of reasoning. On the other hand, reasoning is also used to evaluate arguments. Here its goal is to tease out good arguments from bad ones so as to accept warranted conclusions and, if things go well, get better beliefs and make better decisions in the end."
This is why you have to take it as an ongoing discussion and everything as a hypothesis. You can't say "Human language evolved to argue, not to make better decisions", or any similar assertions, with almost any certainty. It's a point of an ongoing conversation. The hypotheses themselves don't always lend themselves to formalization the same way as the natural sciences. Of course any science strives for as much precision as possible though! Simply in practice anthropological and psychological phenomena are even harder or impossible to formalize in the sense of mathematical precision, at least non-trivial observations; the little I understand of those fields they go to great lengths to reduce and communicate uncertainty (this includes History as well, where it seems a core concept of the canonical research methodology[1]).
Because part of the reason we develop those theories and those fields in those places is to better understand ourselves and put them to practical use, particularly in practical use (when thinking about thinking, or how to interact with people, etc.) this uncertainty shouldn't be forgotten -- more as an inspiration than strict guidelines for human behavior.
I took me a while to understand this, and the subtle differences between the different fields of study!
[1] In history research, I believe you rarely hear "Such and such happened..." (unless there's overwhelming evidence), and more likely hear "According to [e.g. some Greek historian] in [such account], such and such happened...", historical records are understood to be unreliable.
I appreciate it greatly.
Argue over what?
One can easily argue (npi, and I will) that reasoning evolved in the individual to aid understanding, to comprehend. You first need to hold a point of view before you can argue that position and collectively reason about an object.
You seem to give legs to your position by substituting "truth" for "understanding". A reminder that we humans collectively have "understood", "communicated", and wrote tomes on all sorts of falsehoolds. Reasoning has nothing to do with "truth" in principle.
Dunbar's suggestion],"then, is that language evolved as a 'cheap form of social grooming, so enabling the ancestral humans to maintain the cohesion of the unusually large groups demanded by the particular conditions they faced at the time."
https://www.sciencedirect.com/science/article/abs/pii/004724...
"In other words, did language evolve tofacilitate the exchange of technological infor-mation (with gossip as an idle by-product), ordid it evolve to facilitate the exchange of socialinformation (with the exchange of technologicalinformation as a useful by-product)?"
https://attach.matita.net/ziorufus/Dunbar%20gossip.pdf
I'm curious why you say tens of thousand of years when the Homo genus has been around for over 2.5 million years?
There are a number of reasons legal documents bear only a loose resemblance to spoken language, but an important one is because they are closer to programming than they are to literature. They're trying to nail down all of the boundary conditions so that asymmetric information doesn't result in excessive harm to either party in the agreement. So one party can't use a Trojan or a 0-day exploit against the other.
And every time they discover they've screwed it up, the language becomes a little more stilted.
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.
As you imply, the EWD is a treasure. I've read through the vast majority of the English language ones and it has deeply improved my understanding of "Computing Science." I personally enjoy his non-technical writing too, abrasiveness and all, but I know that's not to everyone's taste. If it isn't, it's easily skipped. I do wish I had some Dutch though to get the bits I missed.
Edit: > He's got an anti-visual-programming rant in the archive as well
It just occurred to me to ask, is this the one where he argues that any visual description by its nature overspecifies? That's one of the recurring themes in his work, specify everything that needs to be specified, but no more. Of course even a vector of glyphs is still in the end a visual representation, so things are always overspecified. For example a + b and b + a are, in some languages, exactly equivalent and it would be nice to be able to directly represent that rather than having it require additional knowledge of the semantics.
[1] https://en.wikipedia.org/wiki/Existential_graph
Body language works exactly the same, the exact meaning of a smile by itself is ambiguous, as it’s built from context.
Adding back information previously lost via traditional sentence serialisation in text medium through text emoticons, graphic emojis, and other annotations (like /s) conveys this information which might entirely change the meaning of the sentence; emotion is completely tied to the semantics and critical to understanding.
To me it looks a lot like didascalies (stage direction notes) in theatre play texts.
Second best would be through narrative, like reading a story or watching a movie or play.
Third could be a description of it but my reading of a description doesn't necessarily lead to my feeling of the emotion.
But that communication can very well be clearly describing something precisely.
Or ordering someone else to do something in clear, well defined terms. Do this. Do that. Do known method y, x times.
Some lessons are still unlearned after 40 years.
"Arrogance in Computer Science is measured in nano-Dijkstras" --Alan Kay
Video: https://www.youtube.com/watch?v=9KivesLMncs
>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.
[...]
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...
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)
This sounds exactly like code.
It's one place bugs come from - the human who wrote it interpreted the code differently from the human who wrote the language they used. See JS's implicit global vars for a classic example.
And before someone says, "But that's human error; programs have only one valid interpretation," let me remind you of undefined behavior. It exists and is used in defining the C language (yes, it's one reason people don't like C, but since C is the substrate for a whole lot of other languages, it's hard to avoid at the moment).
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.
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.
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.
Unrealistic since most programmers I've met can't even manage to put together a logically coherent document or presentation without a lot of prompting.
2014 https://news.ycombinator.com/item?id=8222017
2010 https://news.ycombinator.com/item?id=1913308
2008 (1 comment) https://news.ycombinator.com/item?id=233780
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.
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.
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.
You must know a lot of literary geniuses, because I don't know many who come anywhere close to it.
> 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
[1] See chapter 7 of this large PDF: https://eprints.soton.ac.uk/422225/1/Thesis.pdf
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.
Applescript reads kind of like this.
It's interesting to read but a terrible pain to learn, and as you get deeper into it, it still retains the subtle gotchas native to every programming language I've touched. There are always weird implications that you don't see until they bite you or someone points them out to you.
Which, I think, touches on the case Dijkstra is making here.
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.
Don't like the color of the button. Shit now we have to go another level deeper.
When I click the button the trumpet doesn't play. Oh shit, now we have to go really deep
"period" and "full stop" were less successful than "dot", though.