I know this isn't related to the article's content, but I've certainly, and sheepishly, thought at some point in my youth that learning programming was pretty admirable like learning a second language. Sure, you learned French, but I learned C++, I would think to myself, envious.
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.
This is an illusion that was fed early on by people working on programming. The reality is that programming languages are languages, but only for a very restricted vocabulary that is not even close to what can be done on human languages. Also, being fluent in a human language involves not only reading and writing, but also talking, which as you pointed out is a considerably more complex skill.
> The reality is that programming languages are languages, but only for a very restricted vocabulary that is not even close to what can be done on human languages.
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.
>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.
I totally agree. I find that the appeal of programming languages, their strength, fades away in the face of pure mathematics anyway. There's nothing like the full complement of a formal language, symbols, abstractions and all, one that you can write and read just as fluently as English.
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.
>I totally agree. I find that the appeal of programming languages, their strength, fades away in the face of pure mathematics anyway.
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.
Mathematical notation is much more fluid than programming languages. People make up notations on the spot or abuse notation all the time. This is all done in the interest of uncluttering the maths from any unimportant details so you can focus on the important patterns.
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.
> Also, being fluent in a human language involves not only reading and writing, but also talking, which as you pointed out is a considerably more complex skill.
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.
I had my first conversation in English recently, despise having been reading books and texting people using this language for a while; and yet, managed to express my ideas just fine. English pronunciation is a bit harder though, as what is written is oftentimes different from what is spoken, and you risk running in circles trying to find the correct pronunciation. My native language has a phonemic writing system.
==I don't consider the ability to have a conversation in french to be a greater achievement than reading (and understanding) a latin text.==
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.
Translation is far harder than holding conversations. It means that you must be fully aware of tiny cultural differences in the languages. Just because two words have the same dictionary definition doesn't mean they actually are equivalent. However, the quality of translation usually doesn't matter as much as the quality of a conversation precisely because a human wrote the original text and the recipient knows the target language and culture.
>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.
translating is not the same as reading and understanding. out of curiosity, I plugged catullus 16 into google translate. it did a decent job, but not much better than looking up each word one-by-one in a latin dictionary and picking the first english meaning.
"Enough Spanish to make myself understood" doesn't really tell me much. There is a huge gap in command of a language between "I can order food or ask for directions on the street" and "I can drop into a conversation about today's news, no problem", and a huge gap in fluency between "My grammar/diction/pronunciation are incorrect but people can strain themselves to figure out what I mean" and "My speech is accented but clearly intelligible".
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.
To add to this, there are extremely limiting languages like Toki Pona[0]. To construct complex ideas it relies heavily on combining words. But that's also a characteristic we see in most languages, especially in German and Chinese.
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).
I always wonder why anyone would bother with pictograms for a new language. The Latin alphabet is just a bunch of strokes that can be trivially written in cursive. When you consider all the awful writing systems that exist around the world the Latin alphabet appears to be near perfect. Toki Pona is just adding one entry on the list of languages with awful writing systems.
Chinese is pretty efficient as a language. I think there are things that are more obvious in traditional though. There are advantages and disadvantages to each. But beware self bias because you (I'm assuming) grew up with an alphabet based language.
IMO, I'm not linguist but I can see a programming language being just as "language" as any other. Follow my thinking. Just like math topology, if you don't punch a hole into your domain, you can stretch and shape the former until you obtain something else that also doesn't have a hole and looks like something else, but it's fundamentally the same "domain" you started from, you can stretch and shape it back into that. Now let's progress into languages.
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.
To contrast - oh sure there are some obscure C++ language features you can only learn from a mountaintop guru, but there are obscure french features you can only learn in an isolated swiss township.
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.
C++ is a language just like Math is a language. How hard or easy it is to learn isn't the point, it is a means of conveying thought into a transcribable form.
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.
Are you aware that the language you speak is just "ruined" Old English, which is just "ruined" Germanic, which is "ruined" Indo-European? Yet, strangely, we had Chaucer and Shakespeare using these "ruined" languages to perfection.
That phrasing was somewhat tongue in cheek, but you've hit the main problem. Natural languages are constantly mixing, evolving, mutating, and diversifying. As a result they pick up loads of sometimes temporary inconsistencies and regional variances that simply require the person learning it to memorize an ever changing set of arbitrary rules.
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.
I think it comes down to this: the purpose of human languages is communication (i.e. two-way), while the purpose of programming languages is instruction (i.e. one-way).
Well, the ability to communicate with others. Transferring and receiving the state of our mind and emotions to others. It's fundamentally deeper and hairier than the things we program.
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.
> Well, the ability to communicate with others. Transferring and receiving the state of our mind and emotions to others.
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.
The ability of the infant brain to pick up as many languages as surround it is a testament to its incredible plasticity, not an indicator that it's "easy".
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.
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.
I sadly do not remember the name, but there was a teacher/philosopher around 1900, who tried to teach his pupils the natural language in a math defined way. (and wrote books about the concept). His intentions were good, but he was not liked so much and he ultimately had to accept the impossibility of it...
That's interesting -- although I agree that it's important to distinguish programming languages from spoken languages and that they do very different things, I could imagine that the Sapir-Whorf hypothesis applies better to programming languages than to natural languages!
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!
Paul Graham has an interesting take on the idea that the strong Sapir-Whorf Hypothesis applies to programming languages, though its not exactly phrased that way: http://www.paulgraham.com/avg.html
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
"I’m not sure [the sapir-whorf] hypothesis applies to programming languages"
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.
It seems like the author is wrong about the weak Sapir-Whorf hypothesis not applying to programming languages.
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.
> And here’s why I don’t think the Sapir-Whorf hypothesis fully applies to programming languages. When we program we categorize the world in English (or Spanish, or any other natural language), and then we encode that into a program.
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.
> When we program we categorize the world in English (or Spanish, or any other natural language), and then we encode that into a program.
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.
> And here’s why I don’t think the Sapir-Whorf hypothesis fully applies to programming languages. When we program we categorize the world in English (or Spanish, or any other natural language), and then we encode that into a program.
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.
"And here’s why I don’t think the Sapir-Whorf hypothesis fully applies to programming languages. When we program we categorize the world in English (or Spanish, or any other natural language), and then we encode that into a program. So the programming language I’m using, is not limiting the way in which I see the world."
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.
According to Sapir-Whorf, what I think is affected by what the language I think in, that lets me express my own thoughts to myself. If there's no concept in English for an idea that occurs to me, it may remain muddled or I just might not become fully conscious of it.
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.
> If there's no concept in English for an idea that occurs to me, it may remain muddled or I just might not become fully conscious of it.
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.
I believe programming languages have few things in common with natural languages. Even though some experts in psychology claim that foreign language skills is a better indicator than math skills if someone will be good at learning programming languages or not.
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.
Well, language is a wide term. Even mathematics has been called "a language" many times (e.g. the language in which Nature "talks to us", the language used by physics, etc.). Indeed, a language is a system of symbols that is designed to facilitate communication, and one can certainly think of a programming language as a way to communicate programs to a computer!
Any turning complete language can only uphold the Sapir-Whorf hypothesis at the level of types, kinds or higher.
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.
I really like this talk from Splash 2016 by Amy Ko called "A human view of programming languages". It explores various metaphors on Programming Languages including PL as language. I think she makes a very good case for why it is important to analyze programming languages from different perspectives.
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).
> And here’s why I don’t think the Sapir-Whorf hypothesis fully applies to programming languages
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).
I don't think Sapir-Whorf (in a weak form) is just a case of inverted causality. Sure, matters of perception shape the language we speak; this happens all the time. But the key point is that the reverse direction happens too. Language is a perfect medium to transport preconceived notions and because we don't think so much about it (indeed, we think lots of things are natural, when they're actually particular features of a single language) it's particularly subtle. Examples of this include gender/classifier systems, colour perception, evidentiality markers, or one of my favourites, spacial recognition: one famous experiment shows that members of a particular Australian aboriginal tribe (Guugu Yimitthir) think in terms of absolute cardinal direction even in everyday situations instead of left and right; in fact they don't even have words for left and right. Of course, the reason for this development is originally due to the landscape around them, but now the language which lacks such terms serves to reinforce this worldview.
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.
Any object I could name seems ultimately arbitrarily defined at some point, it's "object-ness" simply a thought in my mind.. and even that only as long as I actively uphold it, since a thought isn't an object either, but a process. Sure, I also slice the worlds into things with words (or unspoken thoughts that do the same thing), I have quite the ego actually, and I find that fun; but when I recursively ask "what is X?" and then ask that about whatever it consists of or is affected by, it quickly ends up nowhere, in a cosmic shrug.
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.
is medium code for i've just read about something i haven't read before and here's some loosely related thoughts? the author is not even familiar with racket nor does he seem particularly familiar with what language oriented programming (LOP) is.
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).
>A LOP programmer who resorts to extra-linguistic mechanisms effectively acknowledges that the chosen language lacks expressive power.
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.
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.