Programming languages are not languages (2018)
medium.com
medium.com
Then I actually learned a second language in my late 20s and chuckle at my former hubris (well, more like wishful thinking) that a programming language was comparable.
Programming was just something my socially destitute self did for fun in the comfort of my bedroom. To learn how to speak a language, I had to (shudder) talk to other people. And socializing with people isn't this finite, self-defined virtual world like your game.js file where you just invent your own physics: You have to actually figure out the social world.
I would push back slightly on this. I don't consider the ability to have a conversation in french to be a greater achievement than reading (and understanding) a latin text.
can you read latin?
The greater point is that reading and writing are actually both easier and simpler than listening and speaking[0], even though we tend to learn how to do the former after the latter; think of the difference in difficulty between building software that can process natural language from text vs. from speech, and realise that many of the same additional problems (such as the sheer ambiguity of sound versus letters and the ephemerality of real-time speech) apply to human brains as well as to software systems. In fact, as you develop beyond infancy, the ability of your brain to distinguish sounds that are not a part of your native language(s) rapidly atrophies in favour of optimising for the ones you heard on a daily basis as a baby[1].
> can you read latin?
No, because I have next to zero interest in it. I am however familiar enough with [Ecclesiastical] Latin to recognise that it is largely overhyped in "difficulty" by monolingual English speakers for whom it is their first tangle with extensive conjugations and declensions - it's not much harder or more complex than the Romance languages it birthed[2], and is significantly less so than, say, modern Arabic or many of the Slavic languages.
0. Additionally reading and listening are relatively easier than writing and speaking respectively, due to the brain ingesting information more readily than it produces it.
1. There are about 800 distinct sounds used in all human speech, but the average language only uses ~40. By the time you're a year old, you've neurally committed to whatever handful of those sounds those around you have been making; you become hard-pressed indeed to even hear the difference between the remaining ~760 and the ones you already know. As a concrete example I've had personal experience with, in Hausa the sound written as `f` isn't pronounced labiodentally (upper teeth to bottom lip, the way it is in English) but rather bilabially (lips close together, not quite touching, and air forced between them at varying speeds depending on the word). People whose languages don't have that sound almost invariably interpret that sound as a `p`, an English `f`, or even an `h`.
2. As something of an aside, French is my third language (having been exposed to it since I was three or four years old) and I can attest to how much more difficult it is to speak/listen to it than to read it.
Computers have a much easier time translating text than they do holding conversations. That might be an indication that one is more complex than the other.
>That might be an indication that one is more complex than the other.
It just means that most of the work is done by the humans.
If it was easier for computers to do it, they would. That humans do the work is further evidence it is more complex.
As for human languages, being bilingual myself (acquired over 30ish years (am 37), not innate), I can only testify that this is as close to having "two different minds" as it gets— the sheer experience of life is different depending on which language you think it in, you speak it or write it to others.
That's as close as I can get experientially (qualia) to the notion that language is culture, civilization, thus psychological mindset (both individual and collective).
It's a very weird experience of life to have this ability to switch between modes. Doesn't make you any smarter I guess, but certainly opens one's horizons, helps thinking 'out of the box' (i.e. perspective), reach more balanced views perhaps.
I'd like to write a short piece about that someday. Hopefully later if #19 hasn't disposed of me by then.
Note that there is little to no overlap with programming languages or math. You can think these domains in any human language, the translation in symbols/code remains identical, ideally (that's formalism to me, requiring mathematical rigor, not literature skills).
As such, it is interesting and enriching to learn both— several human languages, and math (or at least one programming language). You gain things from each that do not exist in the other subset no matter how deep you look.
The appeal and strength of a programming language is its ability to be executed, something that pure mathematics does not and cannot ever have.
Then you haven't learned anything. Even pure mathematics is still expressed in arbitrary notation. It's no different than a programming language in that regard.
You can see that if you ever try to do actual maths on a computer, e.g. with a CAS or, worse, an automated theorem prover. Suddenly you have to care about all these technical details and you get bogged down quickly.
I'd rather ignore ad hominem above ;)
Vocabulary is not the real difference. A word is an abstract concept given a definition in terms of other words. The equivalent of set of related words is an API in a programming language.
The real difference is that natural languages are intended and optimized for speaking, and they inherently encourage ambiguity because conversation is an interactive process where one can request clarification. Programming languages are typically non-interactive and don't tolerate ambiguity at all.
It also is. Because in a programming language every vocable is clearly defined when used, or you get an error.
Words in natural languages are not really clearly defined. There is only a very small subset of words, people are not fighting over their definition.
Thats why it is an art, to write a understandable book. Or give a lecture, the audience can understand.
But you are right, languages are optimized for being spoken in 2 ways. With the possibilitie of clarification.
>1 undefined behavior
>behavior, upon use of a non portable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements
>2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
>3 EXAMPLE An example of undefined behavior is the behavior on integer overflow.
Yeah, that is obvious, but is there a example, where a defined variable is not clear defined and ambigious?
Larry Wall vehemently disagrees.
The only difference I see is that we don't speak C++ (though you could argue that sometimes we do). Mostly because it is pretty laborious and not worth the effort when we have a common tongue (pun intended) between us.
Spoken languages were created to communicate. They advanced to allow us to convey complex and highly abstract ideas. I wouldn't say programming languages were constructed with the same intent (at least they are intended to be interpreted by a computer, not by a human).
French is harder - but programming is also hard. One interesting contrast is that programming "languages" might be better placed as wide sweeping paradigms, with learning C++ if you know Java being closer to learning a Boston accent and learning PHP if you know Java maybe learning a new dialect.
Fluency in a natural language is a woolly concept. There is no such thing as being "completely fluent." There are various dimensions of language proficiency and even native speakers vary greatly in their abilities. Even the most eloquent writers and speakers of a natural language are ignorant of vast portions of it, after using it for decades.
Small children learn two languages because they're surrounded by people speaking two languages. Children's brains are highly plastic; if they were immersed in people speaking code language as they speak natural language constantly, then they would learn that, too.
If you doubt that, good luck becoming even halfway productive[0] with a second natural language as an adult in anything close to the amount of time it takes to become productive with a second programming language.
0. Productive, while a fairly weird word choice, can here be taken to mean "able to consistently engage in and with non-trivial communication" the way that productive in a programming language can be taken to mean the same for non-trivial features and tasks.
I do agree however that natural languages are almost universally larger and more complex than programming languages, largely because there's no restrictive compiler or interpreter shutting down people who attempt to corrupt it. Left to their own devices people will ruin a language. History has proven this over and over again.
Computer languages on the other hand are far more static, so once you've learned its typically very simple grammar and vocabulary you are done save for a handful of tweaks in major version updates that happen only once every few years.
Human languages are used to communicate abstract and concrete ideas, and that is achieved by the use of either symbols, sounds and/or body expressions. Now, it happens that we don't speak 'C++' for sure, and we can't certainly wave 'C++', but we definitely can communicate abstract ideas by using C++; besides, that's what happen when you write C++ code. Also, when you read someone's else C++ code, eventually you'll learn the abstract ideas that are being communicated, can take a while, depends on many factors, but eventually you'll do.
So, by this reasoning, programming languages are as just as "language" as the humans one, as far as we consider communicating ideas the main objective here. They might not be efficient enough so you can communicate to your friend how you liked the book you've just read (without using a string literal all alone, ofc), but human languages aren't also efficient in communicating a x86 processor what to do in order to sort an array; but both languages communicate ideas nevertheless.
I suppose you can learn a language without ever interacting with others. I thought I could learn Spanish that way, the same way I learned to program.
Eventually I could read in Spanish yet was hard pressed to utter a sentence. And when I interacted with people who could speak Spanish, it was just depressing and shameful. Learning a language just to be able to read some more books and watch some movies turns out to be pretty dull.
As an introvert, this was part of the journey that made me truly appreciate human interaction and question how much time we spend caring about programming and tech. Kind of like how I cared about things when I was younger and have started caring about people as I get older.
Of course, my whole top level comment is a complete derailing of the discussion around the article and just an unsolicited meandering on my part. I don't think there's much analysis to be had in my post. I just immediately though of my younger self and anyone I've ever heard trying to compare programming to communicating with other humans in their native tongue.
But again, why does this require speech? There's sign language. There's braille. Are neither of these languages?
What I'm trying to say is that this isn't really a simple question. We've clearly thrown out the dictionary definition of a language, but these restrictions seem arbitrarily created to disclude programming languages but the way they're done also disclude things we do consider languages. Verbal communication seems like a strange restriction.
After all, we hear all the time that programmers in a particular environment analyze problems differently, or think of different solutions, or do or don't write certain kinds of bugs, compared to programmers in a different environment. Since strong forms of Sapir-Whorf have come in for so much criticism among linguists as applied to natural language, I'm not sure my intuition about this points in the same direction as the author's!
I tend to agree with your hypothesis: firstly, I don't think that the strong form of the Sapir-Whorf Hypothesis holds for natural languages [0], which sets the bar pretty low for PLs. And secondly, the SWH does (seem to) hold for programming languages: the cognitive tools and abstractions reached for by users of language A can be very different from those reached for by users of language B. Lisp users, Haskell users, C users, Forth users, etc all seem to think about problems differently. It would be interesting to see some empirical work on this.
[0] Almost all post-Chomsky linguists agree with this, but there are a few that have tried to argue that you can kind of bend the strong form to make it fit some empirical results; see the color word research of Paul Kay for example -- http://www1.icsi.berkeley.edu/~kay/Kay&Kempton.1984.pdf
Is that really true? Having moved from OO programming to distributed functional programming, I definitely think that my worldview is different; I'm constantly thinking about how to deal with systems unreliabilty and message passing latency, which is not where the bulk of my time was spent thinking when I was writing for non-concurrent systems with shared memory
First, I don't think he quite gets what the Racket folks mean by "language oriented programming." They're not talking about adding stuff to the whole language. They're talking about making the toolbox for generating languages and connecting between them so straightforward that you build something more than DSLs, more like adapted variants that share some kind of common semantic core.
Second, a human language is a mechanism for establishing and playing language games. A programming language, like any other formal notation, is a means of expressing the subjects of a range of language games. Consider the various language games you play on a function: summarizing, calculating run time complexity, simulating, listing side effects... Language oriented programming is a way of saying that there are often specialized language games that are important in a particular context but nonsense outside of that context, and it would be nice to make it easy to engage in them in that context without trying to force the whole world into that image.
This is anecdotal, but once I learned Clojure, some things about the way I thought about problems changed. I didn't think about things in a functional way before that. The same has happened since I started learning Rust. Now I'm thinking about ownership and lifetimes. And in C I had to manually allocate and free memory.
Perhaps the hypothesis should be amended to refer to programming language paradigms, or something along those lines.
I certainly don't "categorize the world in English" before "encoding that into a program".
I've also met dozens of programmers over the years who found it easier to "show code" than to explain in English (or Spanish or any other "natural" language). I would be shocked to discover this is an isolated phenomenon.
In Iverson's book "A Programming Language" (1962) says in §1.1:
Ordinary English lacks both precision and conciseness. The widely used Goldstine-Von Neumann (1947) flowcharting provides the conciseness necessary to an over-all view of the process. only at the cost of suppressing essential detail. The so-called pseudo-English used as a basis for certain automatic programming systems suffers from the same defect. Moreover, the potential mnemonic advantage in substituting familiar English words and phrases for less familiar but more compact mathematical symbols fails to materialize because of the obvious but unwonted precision required in their use.
So I'm not sure Iverson would agree either.
Maybe just start with something simple like: Why is it important to classify programming as "not a language"?
I had a hard time understanding what the author might think the answer to this question is. The only thing that jumps out at me is this:
> … after seeing what happened with Scala and SBT, where sometimes the project build description ends up written directly in Scala, I’m not sure having one language that encompasses all is something I’d want …
> Is it worth to expose users to an alien configuration format, just so the developers of the project can program in just one language?
If you seek a purely utilitarian answer; an answer to what makes the software best perform the intended function, then yes it is worth it: There will not be bugs in the code you do not write.
However getting people to use your software (i.e. "Sales") means making the software accessible to other peoples expectations and that's a social exercise.
This is a business decision with simple economic drivers, and not a technical one. Some languages are simply better at sales than others; English is the most widely-spoken language in the world, but that doesn't mean English poetry is superior to Chinese poetry.
Speaking solely for myself, I don't find this to be true. Yes, it does seem to be the case that you have to represent the program in your mind before you can accurately convey it to the computer. But no, I don't find myself using words to represent that. Maybe I use English to talk myself through the concepts, but I would not conflate the mental model with the words I use to describe that model.
My mental model feels a lot more like data structures -- abstract relationships between parts of the program, degrees of closeness, and senses of information flow. I can't represent the brainfeel of that in words without losing too much of it. And very often, yes, the semantic world in which I know this program will be embedded -- by way of a programming language that exposes that semantics -- does influence how I think about the program.
> If we think of programming languages as tools, then it becomes evident how some programming languages lend themselves naturally to problems that in other languages might be — while not impossible — hard to solve. See for example Erlang, a language that’s tailored for Concurrency Oriented and Message Passing programming, or Racket itself, a language tailored for LOP.
I don't understand the proposed distinction. If we can agree that the "tool" affects how you think about a program built using that tool, aren't we ultimately just quibbling over what the word "language" means? I feel like that's missing the point of the assertion that programming languages are languages -- you still end up with some form of Sapir-Whorf.
The idea of a "programming language paradigm" better captures the essential semantic distinctions between languages, but even these can be too coarse-grained. I'm more interested in adjectives like "single-ownership", "message-passing", "immutable", "backtracking", and so on. Words that describe the semantic world that the PL purports to be an interface to. Maybe that's what the word "tool" is supposed to convey, here, but then I don't think PL researchers really disagree.
I'm not sure I do that. I'm often "thinking" about code by stubbing out functions or classes. I definitely don't translate algorithms I'm familiar with from English, I just write them directly.
But say that's how we do work. What happens next? Someone else looks for a bug. Or someone else adds a feature. Maybe you refactor.
A real software project is a team effort that requires countless interactions between authors over time.
The structure of the programming language dramatically influences the development of a large scale project. There are selective pressures all the time, you can rarely put into words why certain things are "idiomatic" to a language, but when a particular expression is confusing or odd, someone is likely to clean it up before long.
So, yes, programming languages are absolutely languages.
I agree that programming languages and natural languages are different. That being said, programming languages do meet the definition of languages bc they communicate structured information.
Example: "if x < y { string z = `${x + 1}` } else { string z = `${y - 1}` }" . This short program communicates a structured piece of logic with clear meaning. It's not all encompassing, but then, neither is a English.
This is not the case for programming languages, because programming languages, even non-imperative ones, only have one mode: how to do something. They are not a way of describing the world. If I can't figure out the C++ code necessary to accomplish the task I want, that doesn't mean I can't imagine what that task is. Determining the task and figuring out how to code them are very different.
You probably won't be. I have observed a similar phenomenon when trying to imagine truly new things.
> If I can't figure out the C++ code necessary to accomplish the task I want, that doesn't mean I can't imagine what that task is.
If you can't figure it out in C++, but you could in (say) assembly (or Perl, or Python or whatever), then I would agree with that and would say I don't think that's an essential limitation of programming languages, and just that C++ is unfamiliar and byzantine.
But if you can't figure out the task in C++, but [believe] you could in [plain] English, I'd say you're just wrong: Whenever someone has told me "the ticket is perfectly clear" it most definitely was not. If your experiences are different, I'd like to hear about them.
At MIT some people tried to write code using natural language: http://news.mit.edu/2013/writing-programs-using-ordinary-lan...
Both programming languages and natural languages can be described in terms of Formal language theory and that's the most they have in common: they have words, grammar.
By definition at the term level you can express any cognitive categories. The weak hypothesis applies, since languages encourage use of terms in cognitive categories amenable the type system.
https://medium.com/bits-and-behavior/my-splash-2016-keynote-...
After watching Amy's piece, I have to disagree with the conclusion of the author at hand: "I’d say it’s better to use the tool metaphor, and see where that framing could take us."
I think the PL as tool metaphor has been almost as thoroughly been mined as the PL as math metaphor. Most PL conferences are filled with papers approaching PL from these angles -- we know where that framing takes us. The other metaphors are more interesting to me and I think are more ripe for interesting new research (good luck getting them into some PL conferences though).
I don't think it applies to languages, period.
The Sapir-Whorf hypothesis seems to me like a classic case of inverted causality ("wet streets cause rain", as Michael Crichton put it). Sure, it's definitely possible that in a given instant one's language might constrain or otherwise influence one's cognition, but it's vastly more likely to be the other way around: if the language is unable to support a concept in one's cognitive process, an individual is prone to bend the language, whether by grabbing a loanword from some other language, recombining roots to create a new word, or what have you.
That's the fundamental issue with programming language design that I think the author's trying to articulate: they're designed, and more fatally, they're designed in such a way that they're rarely able to evolve as needs dictate. The many Eskimo words for snow didn't come down from on high and conjure those forms of snow (and their perception by humans) into existence; rather, I strongly suspect people encountered (and had to describe) these different kinds of snow often enough that they found it worthwhile to give them names rather than merely descriptions. Phrases turned to compound words turned to shared roots.
This is in contrast to most programming languages; yes, at some point they were obviously created to satisfy a certain need and give "words" to certain computing concepts, but very rarely are they able to fully evolve to address new computing paradigms (at least not without rigidly declaring a new version or new dialect of the language with new syntax or keywords, which just punts the issue a bit farther into the future). There are a handful that are better at this (Lisp, Forth, and Tcl - and their respective descendants - all come to mind), and they happen to lend themselves well to DSLs, but I feel like they stop just a little bit short of being able to entirely evolve on their own; programming languages need implementations and runtimes to be actually useful, and few (if any) languages provide the mechanisms to freely manipulate their own implementations/runtimes (there are certainly plenty of Lisps that can bootstrap themselves and other Lisps, but that's almost always an ahead-of-time operation with little to no exposure to the language user, nor any practical means for said user to leverage that within one's own code to tailor the language and the implementation thereof to the exact problem domain).
My only qualm with Sapir-Whorf is that it only credits language with this cultural transmission. But there are a lot of other things that can do this (arts, rituals, customs), even if language is a big part of it.
Well that and that the original version ("the Hopi don't know the concept of time") is a bit ridiculous.
Ironically, a definition for the term "define" is given.
To me the world is objects. To you maybe it's a continuum.
Where exactly does an atom begin or end? Where does my body end, and does it also occupy the vast empty spaces between atoms, and so on? Is it solid with an outside, or rather just a bunch of probability clouds loosely held together by mysterious forces? Considering all mass attracts all other mass in the universe, no matter how weakly, can it be considere separate?
All I can say for sure is that "there is something", or "there is something going on", but I don't even know which of either, or if one follows from the other.
the author does not give definitions of things that he makes comparisons between. for example, no definition of language, natural language, programming language, or metaphor is given, and he even conflates natural language with language. and this entire article seems to be based on analyzing the meaning behind a footnote.
what he misses is that the racket/LOP community think of programming as communication between people and not between human and machine. matthias felleisen says so here (https://www.youtube.com/watch?v=91hynuuM_As). that is the very definition of language: the words, their pronunciation, and the methods of combining them used and understood by a community (merriam-webster). this definition is actually a little overly specific, but one thing i am reminded of is the text from SICP that says:
> when we describe a language, we should pay particular attention to the means that the language provides for combining simple ideas to form more complex ideas. Every powerful language has three mechanisms for accomplishing this:
* primitive expressions, which represent the simplest entities the language is concerned with,
* means of combination, by which compound elements are built from simpler ones, and
* means of abstraction, by which compound elements can be named and manipulated as units.
> Also when they refer to “extra-linguistic mechanisms” do they mean different codes as in semiotics?
the author should understand what they mean before writing this article. by extra-linguistic mechanisms they mean reaching outside of the chosen language, like java, to other languages (these are the configuration, project description, and makefile languages mentioned). the purpose of LOP is to bring these extra-linguistic mechanisms into the base language. so in racket, rather than creating a wholly new languages for documentation, they created scribble which is a language that sits on top of racket and can interact with racket. this is turning the extra-linguistic mechanism of writing documentation into a linguistic construct so that scribble is not a totally separate language, it is an extension of racket.
> If we want to think about what kind of problems a programming language makes easy to solve, and which ones they make more difficult, I’d say it’s better to use the tool metaphor, and see where that framing could take us.
the so-called tool metaphor has been the dominant view and is the source of almost all problems of software. software is not just a tool.
what makes software hard is that it isn't one thing. it is all of a way to do something (a tool), a way to think about something (a conceptual model), and a way to communicate something (a language).
Tom this sounds about as correct as saying that someone who resorts to using picture/diagram/melody/.../whatever beside text acknowledges that the chosen language lacks expressive power. Although correct, it's so vapid sentence that I don't think it deserves having whole article based on it and in the end makes the article itself needless as well.