It's only briefly mentioned, but learning to read music is quite similar in terms of brain function to learning programming. It's symbolic, logical and structured.
My university went so far as to allow students with a bachelor's degree in music to directly enter the computer science master's program.
In the early days of computing (that is, when computer companies and universities were finding the first people to learn programming) music experience was a strong signal for programming ability! Playing music prepared them for focusing on the low-level details while holding the big picture in their head. [0]
Fascinating! Any chance I could know which school it is?
I have worked in both computer science and classical music, and found many crossover talents. Two previous Director of Music at my school (UBC in Canada) in the last few decades are both musicians and engineers/physicists.
The one thing I think is different about reading music is sight-reading, where you're reading it at speed while playing it. I can do that with music and text, but not computer code, even in a language that I'm super familiar with.
I can read a screen-full of code at time -- sort of like speed reading -- in most of the programming languages that I know.
It took me a while to realize that I was doing this; I only figured it out from when it doesn't work. I can't do it when I'm looking at code that's dark-themed if I normally work with that code light-themed. In that case I have to read the code line by line. It's actually a strange feeling.
Some of my environments are dark themed for certain languages/environments so it's not the dark-theme itself that throws me off but something about the unexpected visual difference.
I think the programming analog of sight reading might be following along with assembly language or other low-level or simple imperative code while mentally tracking basic stuff like register/variable usage and control flow. Sight reading music doesn't involve real-time analysis of the broader abstract structure of the piece. That's not really applicable to high-level code making heavy use of nested abstractions or non-imperative paradigms.
That's right. The level of analysis during sight-reading is along the lines of: "I hope I don't screw up in the next 500 milliseconds, and who's that person who just came in the front door?"
That seems plausible. Music is written to be read in that way. Writing and sight-reading are a sort of symbiosis. There are no subroutines or abstractions. And a good reader recognizes a lot of patterns by familiarity. There's stuff that goes straight from my eyes to my fingers while I'm thinking about something else. But if you write some completely random note pattern or rhythm (or both at the same time), I might be in trouble.
The pattern recognition (and muscle memory that comes with it) is a huge difference between sight-reading music and programming, IMO.
I'm sure if we tried hard enough we could come up with a pretty good analogy between data structures / algorithms and scales / arpeggios / etc... but I've never felt quite the same when recognizing a familiarish algorithm in code as I would when sight-reading some music and having my fingers perform the right kind of movements out of almost unconscious muscle memory.
I wonder if editing a piece of written work would activate some of those same problem solving areas as reading computer code does. It that case you're more concerned about structure, grammar, correct wording and such. I find personally i'm in a different frame of mind that reminds me, at least, more of a coding frame of mind than a reading frame of mind.
A lot of the time editing, I'm not really paying attention to the meaning of what's written, but whether the meaning is conveyed properly and clearly in any given sentence or paragraph.
That sounds reasonable, I've helped edit a few things and need to decide on each pass whether I'm reading for content or structure. Totally different mindset.
I've also found when I'm deep in a problem solving mode like coding I tend to be far less empathetic. So it seems to mess with my people skills too until I come up for air.
> I've also found when I'm deep in a problem solving mode like coding I tend to be far less empathetic.
My experience as well.
This is a side effect of a forced WFH. My kids are regularly at the receiving end of my outbursts when they interrupt me when I'm deep in work, more so when I'm debugging. In office on the other hand such 1-1 interruptions are rare.
I think many programmers often lose empathy from too many long hours of deep problem solving and never really get it back. A therapist for instance once said that John Carmack had little to no empathy for other human beings.
Apparently this is from a psychiatric evaluation when he was caught perpetrating a burglary at age 14. That's definitely an unusual and disturbing thing for an adolescent to do. But do you have reason to think Carmack got that way at that age specifically because of his interest in programming, or that his interest in programming kept him that way thereafter?
I'm skeptical of this because he went on to be a successful, respected computer scientist and business leader, as well as starting a family. While of course many people who've done each of these things may be bad at empathy (or worse!), I'm not aware that Carmack has somehow continued along the course he was on at 14.
He apparently put his desk in the hallway so he could see when everyone left, and fired a guy for not staying late enough (even though that guy was coming in early).
I had the same thought—reading computer code seems more analogous to editing, especially editing something like a technical manual where you're concerned with how others will interpret the instructions.
Reading through the research methods of this study, it says the participants read a single line of English text or Python/Scratch code at a time. (Example English sentence of "NOBODY COULD HAVE PREDICTED THE EARTHQUAKE IN THIS PART OF THE COUNTRY"). So this study was looking only at the very granular level of "reading".
But seriously, by recalling and introspecting the thought process occurred just before an interruption, I think coding is moke akin to navigating a landscape -- it has a substantial spatial component.
Simply put, it's like thinking about consequences and dependencies at every given line/statement. Something that we don't do (or do rarely) while speaking or reading.
On the other hand, "natural language aptitude" as measured by
Modern (modern = ca. 1960s) Language Aptitude Test, which they used in that study, doesn't actually predict success in language acquisition. The test scores correlate with ability to perform well at _early_ phase of language curricula – but this is exactly the phase when the learners are still using the "general processing mechanisms" to process language, and not the mechanisms specialized for language that get engaged when they gain fluency years later.
Sadly, this is underappreciated in the general psychology and linguistics community. Some researchers in Second Language Acquisition research community are more concerned about this kind of mis-interpretation and confusion of different meanings of "language skills/aptitude".
>And yet natural language aptitude highly predicts programming ability
Its all correlated with g.
>[0]
They contrast "language learning ability", ie intrinsic intelligence, with "math knowledge", ie amount of schooling. For reference, you can take (a version of) the math knowledge test used here: https://www.idrlabs.com/numeracy/test.php
If the article wanted to give a more honest interpretation of the paper, they would have focused on the leading predictor of programming ability, "fluid reasoning and working-memory capacity". One supposes this to be quite useful in math and engineering.
It's important to note the methodology employed in the original paper used "did not have meaningful structure or variable names" [1]. If the code's like that, then yes it's less like reading a language and more like cryptic puzzles.
But limitedness of the methodology means the conclusion can't apply to software development at large, something that the title misleads us about.
I'm not intending to make some grandiose point here, only that I suspect natural language aptitude is highly correlated with success in various different domains, not just programming.
When I'm coding, I often listen to music, and when I listen to music, I often end up singing along.
One thing I've noticed is that I can type out code at the same time I'm singing a song aloud. If I tried to do that while writing English, I'd start typing whatever I'm singing.
I do this too but when I'm struggling with something particularly difficult, where I don't feel I'm making any progress, I often have to turn off all sounds and contemplate in silence.
(Which is btw not really possible in the office, even with noise cancelling headphones. Thank God for remote work.)
Ditto! I can also listen to a podcast or have a video playing in the background and still write code. Definitely can’t do that when trying to write English.
Listening to music with lyrics is already hard for me when I'm writing code, but listening to a podcast is unthinkable--what kind of podcast? Don't you get distracted by the people talking?
I can't imagine anyone can actually listen to a podcast and actually program at the same time. Perhaps if the podcast is uninteresting and the programming is copy-pasting.
Much like the other comment - I can't really listen to music while learning to code, but if it's something I alredy know how to do then music sometimes seems to be helping.
Actually when I write blogs I listen to music. So I dont think it matters a lot whether we are writing code or English. The songs and music just sort of goes in the background.
Interesting, it's the opposite for me. I can write or code while listening to music without lyrics (especially electronic or classical), but whenever there are words in the music, it's like 100% of the language-processing part of my brain focuses on that, and I can't really focus on anything I try to read (or even worse, write).
For me I can handle it if the lyrics are in another language, even if it’s one I speak. It’s not activating the same words so it’s easier to tune it out, maybe.
I just tested this for myself. I was very surprised when I started writing with my pen what I was singing instead of what I'd intended. I then tried coding and was still able to do that while singing. However, I was also able to type natural language while singing.
This may be the reason why you can still learn programming even when you are 40 years old, but its very hard for you to learn a new language the older you get as you language acquisition skills fade away.
Also the experiment was "The researchers showed them snippets of code and asked them to predict what action the code would produce.".
This may not be the best way to prove the thesis conclusively. Because when I read code I check the syntax fast and then I try to figure out logic.
"The researchers saw little to no response to code in the language regions of the brain"
This may mean that the participants quickly scanned the sytntax(language part of brain is used) and then they tried to figure out the logic(multiple demand network of brain is used)
First: that language acquisition at a later age is so much harder is not true. It takes a child 6 to 10 years to get fluent in their first language, and they don't spend 3 hours per week studying it, but 80. For adults, there are language schools with an immersive program. They are expensive, but successful. You probably won't get as good as when you'd have been immersed from day 1 in your life, but you can get quite far.
> This may not be the best way to prove the thesis conclusively.
It certainly isn't. For starters, it does not provide a comparison to normal language.
> The researchers saw little to no response to code in the language regions of the brain
And I say: screw that logic. It's faulty beyond comprehension. That a brain region doesn't light up doesn't mean anything. It could even mean their scanner was broken.
Do you have a source for that? It’s something I’ve always believed, but have never seen actually rigorously researched. I’ve long suspected the “adult language learning difficulty” is simply due to having less time as you get older (not to mention an often ossified/obstinate attitude towards learning something new from scratch and feeling clueless).
Have you never met any immigrants before? There's a very stark cutoff age before which learning a language results in no accent and after which the accent is almost impossible to eliminate.
"Language acquisition" is quite different from "no accent". My manager is a non-native speaker of English, but the only way you can tell is by his accent -- he's perfectly fluent, both in construction and in comphrenension.
And I myself prefer "notation" because with notation we tend to look at the underlying thing, not the notation :) E.g. there are different notations for chess parties, but their peculiarities are not that important, it's the party that matters.
Given that words like "language" and "notation" both come with a set of expectations, I wonder if APL and similar languages that we might as well call "notation-oriented" would have become more widely adopted if we had used "programming notation"
To me that phrase of Wirth certainly opened new lines of thought. Notation is clearly a tool. One can be better than another, but there's no reason to become fascinated with the notation itself and strive to perfect the expression (e.g. to write "pythonic" code). If the notation doesn't fit the task, it's the notation that should change. And so on.
With recipes, I suspect it depends on how the recipe is written. Usually they're quite prose-heavy, and require a lot of linguistic parsing before you start to get the meaning out of them.
It's interesting to think about, and makes me suspect that this is why I tend to prefer writing my own recipes out as tersely as possible, particularly if I know the general procedure. At this point I don't need to be told to preheat an oven or to scrape down the sides of the stand mixer, so I'll just write down things like "Creaming method, 350° in 8x8 cake pan." I might even start writing them in pseudocode now.
My partner takes it a step further with her cranberry sauce recipe; the instructions just say "C'mon."
Short code may seem unclear, but it does do exactly the same thing as longer code (if written correctly). It's exact opposite of natural language, where short sentences heavily rely on context and supposedly shared knowledge to beget correct understanding. And as such short sentences are prone to misinterpretation.
A program can also be seen as an awkward natural language, conveying programmer's intention to other programmers, of course. But it's a different modality of the code.
Which is why I compared to legalese rather than arbitrary natural-language.
My argument would be that legalese with its strict "May" "Should"s and all that could be sufficiently similar to a (verbose) programming language.
Anecdotally, I certainly have entered "debugging" mode when trying to check if a specific clause of a contract was applicable to my situation before, rather than trying to interpret it liberally.
Of course, anecdote, and only demonstrates that the (my) brain _can_ operate "programmingly" when reading legalese, not that it does so "naturally".
The human brain has specialized hardware for encoding and decoding language. That is why even a child can pick it up. No grammar lessons required, just lots and lots of exposure. It is also why speaking and listening are as easy as falling off a log. You put about as much thought into it as you do touch-typing.
Learning a second language, likewise, is best done the same way as the first: through immersion, if you can swing it. The high school student who spent a summer in Mexico came back far more fluent than I was even after three classes in high school and one in college. The plasticity, though, of this area of the brain will decrease over time. It is easiest to pick up a new language before adulthood.
Most people don't appreciate this or don't believe it. For more information, read The Language Instinct, by Steven Pinker.
Programming? Yeah, I guess it spins the CPU more than any specialized chip. I hate how I can't be interrupted while doing it, and for a few moments trying to come out of it, I am in some kind of daze.
Well code reading is executing or interpreting some sort of abstract machine, at least for me, and it's the way I push my interns to learn. You get context and specify system 1 global, unsound pattern matching set-up by familiarizing with the language, runtime, system&software design, and you use system 2 for no-false-positive-or-negative drilling. The more system 1 is 'trained' the more you're 'efficient' at code reading and I'm guessing that's one of the things that separate 'senior' from 'junior' programmers or software engineers. You look at some code on your colleague's computer screen in padding and it feels... Not right... Stopping in your tracks and sitting down to discuss.
As someone who has over 15 years of coding experience with many different programming languages, I'm not surprised to learn that coding uses many different parts of the brain.
I've noticed that people become more logical in all aspects of their thinking as their programming skills improve. Also, I've noticed that a lot of religious people become atheist or agnostic as their programming skills improve.
It trains you to become good at holding a lot of information in your head and being aware of how they relate to each other and how they conflict.
When it comes to coding, I prefer dynamically typed languages because they don't have any constraints and that makes them more effective at training your brain because you can't outsource or put a boundary on any part of your thinking.
Somewhat opposite experience for me. I can’t listen to anything with words while coding. TV, podcasts, songs with lyrics all torpedo my ability to parse code. Instrumental music especially with a strong beat seems to help though.
I've noticed that I make more errors while listening to any kind of music. But, upon further reflection, it's probably because I tend to listen to music when I'm in the flow, writing large amounts of code.
It was interesting to read. There aren't many google results for 'multiple demand network' that I could easily parse, but I did happen to find this paper on it in primates[0] (also happens to be from MIT) when I was trying to find an image that showed what parts of it are activated. I found this slide from a lecture very interesting[1].
You are right, that slide is very interesting indeed. I wonder what it is about the different languages that triggers the brain to use different regions?
As someone who is fluently bilingual and speaks a third language and is also proficient or better in a half dozen programming languages along with having written code in many more, this is completely obvious to me. Learning a programming language is much closer to learning a complex board game than it is a natural language.
I feel exactly the same, I've been learning a second language and it's nothing like learning programming, in fact arguably the opposite, I've found that obsessing over grammar is almost detrimental to making progress with a new language.
The confident students who aren't concerned with getting all the specifics of grammar exactly perfect are the ones that are making the most progress toward being conversational, they're able to express themselves and actually have something resembling a conversation, despite using the wrong prepositions here and there or conjugating verbs wrong sometimes. The more "academically" minded students who obsess over getting the grammar correct like a math equation are still struggling to form even basic sentences outside of solving homework problems on a piece of paper. I've noticed that I've been making much better progress now that I've been focusing on just trying to express myself even if I'm making mistakes.
Which is obviously the complete opposite of using a programming language.
Weirdly I make the same observation as you about second languages and detail in grammar, but I came to the opposite conclusion. I thought natural language and computer language were pretty similar.
One issue in the study is what a reasonable comparison is. Our ancestors would have talked about "there is a lion over there" and such mundane things all the time, so we shouldn't be surprised if we're just "nexting" those kinds of things with a specialized circuit.
Obviously that doesn't exist for coding, but the question is whether there is natural language that can't be nexted. I'm thinking of James Joyce's Ulysees or Shakespeare type stuff. It's weird even for the native reader. Does that activate the math network?
Also, isn't that a better analogy for how you program machines? You're telling the computer what to do in a language that isn't assembler, and doesn't have the same machine model as your coding language, with a heavy dependence on shorthands established only in the context you created (by writing functions, classes, etc). I thought the reason why a lot of people find it hard to read code is because you're inherently doing something awkward, translation.
I've been learning a new language as well, with the wrinkle that it's quite closely related to one I already speak. Mandarin is lovely, it makes me wonder why there are languages where the verbs and nouns are changed. It also means you can jump into saying useful things pretty fast, you are just restricted by vocabulary. WRT coding, this is similar. Coding languages tend to have very few things you must know (except C++ lol) to get started, but with a lot of reading libs necessary to do anything in a given domain.
Ulysses (and even more so Finnegan's wake) is not written in a natural language. It is a constructed artificial language. Many of Shakespeare's works are also written in a constructed language because of their need for rhyme and rhythm, albeit closer to the natural language of his time. I've also noted that rhymed text, even if otherwise using natural syntax, is harder for me to follow as my brain tends to get lulled by the rhyme itself and stops paying attention to the content, it's just trying to predict the pattern.
Now that said, the idea of comparing programming languages with natural languages or even constructed languages seems very strange to me. Natural languages are tools for thought, expression and communication. Programming languages are tools for, well, programming. Even the relationship between the grammar of a PL and the grammar of a human language is distant (we often intuitively think of identifiers as similar to nouns and verbs in human languages, but in fact all identifiers are equivalent to proper nouns in human languages, and the actual equivalents of nouns and verbs are stuff like block openers, significant white space, function application, maybe the keywords).
It is a well-known fact already that humans can only naturally learn human languages, which have a specific kind of grammar. Even some clumsy attempts at standardizing human language end up introducing un-natural grammar that children can't pick up until later in school when it is drilled into them. It would have been truly surprising to find out that we can use our natural language capacity for something as alien as a PL.
>The confident students who aren't concerned with getting all the specifics of grammar exactly perfect are the ones that are making the most progress toward being conversational
One of my Danish teachers said that the move towards making people conversational is a fairly recent invention, and approximately a century ago (my memory is spotty on when the change happened) teaching was more geared towards making people literate in the new language.
Interesting. I feel like coding is not that dissimilar.
In the early phases of learning a new coding language, I learn how to write lines of code. Sometimes it compiles, most of the time it would cause errors.
At some point it works, but a more seasoned engineer could easily find places to refactor it in order to make it more extensible/flexible, easier to read, less brittle, and most importantly to this discussion on coding language, more idiomatic.
Now, you could say surely I could've seen these by reading the docs and learning about certain library features or patterns specific to the language. But in my experience, I tend to learn faster by first exercising my brain and trying it out on my own take before having someone (be it a mentor or a tutorial/book) correct me so that I have a bit more context about why an alternative approach is better.
The thing is, computer languages are extremely simple compared to human languages. Even the more arcane ones, like C++, probably have on the order of 1-200 'words' that you ahev to learn to 'speak' them fluently.
Of course, you also need to learn large amounts of library functions and their semantics, but that's more like learning who the people at court are and what their roles are than like the language. You could speak perfect French, but you still have to learn that you must call the Comptesse de Barry before calling the King if you don't want her to be upset. Even patterns are often more in this area of cultural/local context rather than the actual langauge - more like learning the difference between overly-descriptive prose and good prose is (which is why the knowledge about it also tends to translate better between different languages).
I don't understand this. If your code has wrong syntax it doesn't compile. If wrong grammar you can get very wrong results. But in english you can say "I go store" and it's understandable (which btw, can be a direct translation from several languages)
> If your code has wrong syntax it doesn't compile. If wrong grammar you can get very wrong results.
In both cases, when you get it that wrong that your meaning doesn’t come across correctly, it’ll usually get pointed out to you, either by the compiler or the person you’re talking to, so you can go back and try again.
Eventually, you’ve potentially gotten it right when the compiler stops throwing errors or the person you’re speaking to understands. Unfortunately, in both cases you may still not end up with the desired outcome as your compiler is “stupid” and cannot understand intent, only what you’ve written. Similarly, but different, the human you’re speaking to may bore of your broken language eventually and just move on.
There’s no perfect system for everyone, but it never hurts to remember the saying: perfect is the enemy of good enough. It doesn’t matter if your language skills are perfect, just that they’re good enough to convey your meaning effectively for the environment you’re in.
In my experience, when you're an adult, people are too polite/reserved/caring/uncaring to correct spoken language errors for you. They'll be much more likely to infer what you meant silently, and react as if you'd spoken the sentence perfectly. In that sense, people are much more like a web browser in how they process your language than a compiler.
Apologies, I realise the way I wrote this wasn’t clear enough:
> Eventually, you’ve potentially gotten it right when ... the person you’re speaking to understands
I can see that I wrote poorly here myself, and here you (and child) are correctly correcting me, while simultaneously arguing against that happening, which is kinda ironic!
What I failed to adequately express was that human languages are a lot more forgiving of errors, and as long as the message is understood, you’ve gotten it “right”
They aren't just polite, it's exhausting to play the pedantic compiler and generally degenerates or requires an agreement with an equivalent exchange.
Perhaps having an automatic compiler changes our perception much as an auto-tickling device doesn't work, but surely early levels of math and languages have similar learning paths.
Which is fine, you can learn a lot by immersion when you hear other native speakers talk. I only ask a person to repeat when I don't understand or if it's unclear and I need to be sure about something. Not breaking the flow of conversation is much more important to me
I disagree with this. How many people do you know that have been speaking English for years but still miss articles ('a', 'the')? It is still very easy to understand these people. We could say the same about tones, diction, and accents. Plenty of people that don't sound native can easily be understood. You'd actually be surprised how much you can butcher a language and still be able to communicate (this is really helpful to language learners!). There's so much fuzziness here that it I haven't seen any compiler (plugin, shell, etc) anywhere near this level of fuzziness.
Tldr: Compilers you need to be fairly precise, natural languages you barely need to be in the ball park.
The important part for the fuzzy understanding is shared context. This is what lets humans who have no languages in common communicate basic things in ad-hoc sign language bits as well.
And if the context fails, things can go just as badly as with computers, in the short run. In the longer run, people notice that something went wrong and are likely to go back to an earlier point and try to clarify, whereas computer systems are not great at it.
The people you're talking to are just incredibly intelligent compilers. We could make a compiler that takes something that resembles a for loop and changes it to be correct, but to do so would strip a programmer of the power to make something similar to but not quite a for loop, which would generally be undesirable in a programming language.
"I go store" is reasonably close to correct: you have a subject, predicate, and object and there is one meaning that fits far better than all others. However switch it up to "I store food" and now you have some ambiguity: are you saying you are storing food for later or are you saying you want to go to a grocery store or are you trying to talk about the food you purchased at the store? Again, a human being incredibly intelligent might be able to tell from context, analogous to how someone reviewing a block of code might recognize what a block of code is supposed to be doing, but in general you could expect the interpreter to raise an error, either of the form "bad syntax" or "sorry, I'm not sure what you mean."
If we consider "human languages" like legalese or diplomatic language, where the goal as with programming languages is to limit ambiguity as much as possible while maintaining the speaker's ability to potentially say as many things as possible, syntax becomes very important, and typically it's preferred that the interpreter raise an error rather than try to guess at the speaker's intentions.
The difference is in natural languages you can make tons of errors and be extremely fuzzy and it won't harm the interpretation. Compilers make you update, language doesn't (this does actually cause people to speak a language for decades and never sound native). Often times we can use grammar of another language and the words from another and still get concepts aligned (useful for language learners who will tend to use the grammar of their native language). "Pineapple store I go get" can be a perfectly understandable sentence when context is involved. You can also use direct translations of words from other languages "I put on my... uh... finger shoes." (contextual clues always help, especially in writing).
Humans are "fuzzy compiling" to such a degree (and giving no errors or warnings to the writer) that it is hard to compare the two.
> If we consider "human languages" like legalese or diplomatic language, where the goal as with programming languages is to limit ambiguity as much as possible while maintaining the speaker's ability to potentially say as many things as possible, syntax becomes very important, and typically it's preferred that the interpreter raise an error rather than try to guess at the speaker's intentions.
Such a concept is not even possible in natural languages. Natural languages are so full of ambiguity that even native speakers from similar regions often confuse one another. Because frankly many don't realize there's: what you intend to say, what you say, and what is heard (times number of listeners). When listening to a non-native speaker we focus a lot of trying to understand intent from them. When listening to native speakers we focus a lot on what is said and what we hear (often ignoring intent). There is just so much fuzziness to natural language that it is a bit ludicrous to compare them. The fuzziness of natural language and strictness of programming languages are necessary features too.
> The difference is in natural languages you can make tons of errors and be extremely fuzzy and it won't harm the interpretation.
> Natural languages are so full of ambiguity that even native speakers from similar regions often confuse one another.
These two statements are contradictory. There's a difference between not caring that an error is present and being robust to error. Natural language represents the former. Yes I might not shout "Error: finger shoes not recognized" but that error nevertheless occurred, I don't actually know what they meant. I'm going to assume gloves, but if their life depended on me getting them mittens they'ed probably wish I had said I don't understand. Luckily, we live in a world where getting things wrong is typically harmless, but history is full of disastrous misunderstandings. If you are doing something important like drawing up a legal contract, your lawyer should have no problem telling you "that wording is unacceptable." which is conceptually no different from a compiler's syntax error.
Natural language and programming languages are different in many ways in terms of degree. Natural languages need to be used in vastly more circumstances, they have been in use for vastly longer, and they generally represent an ad hoc development cycle involving millions of independent contributors. They thus have much more deprecated functionality and conflicting user conventions. But while different in degree, the two aren't really different in kind - every fundamental trait of one is shared by the other, which is why the fuzzy compiler for natural language will accept the terms for a programming language as a substitute without raising any error.
They aren't contradictory. You're working backwards to make humans like computers/interpreters. The fact that human interpretation 'doesn't care' is not so much a feature but a necessity. Ambiguity is inherent to natural languages, not a failure of them, nor a feature. On the other side, programming languages are strict my nature and it is a necessity. In programming we have a limited vocabulary and that limits our expressiveness, which is a feature. We don't want probabilistic outcomes for standard means.
So let's look at the two parts you quotes from me and give some examples. We've conversing quite well, wouldn't you say? You understand me and I understand you? So #1 must be true, right? But have you ever played the game telephone[0]. With the general outcome of every game that must mean that #1 cannot be true, yet here we are. Like I said before, when communicating there's: what is intended, what is said, and what is heard. Usually these align pretty well. But small fuzzing adds up quite quickly. But it should also illustrate to you that what you hear (or read) isn't what the speaker (or writer) intended. Their job is to convey as best as they can to you while your job is to interpret as best as you can. Language being of this form allows us to express wildly abstract concepts, especially ones beyond our capacity to even understand. This is the usefulness of natural languages. But it is also why we created mathematical and programming languages, but why they will never be able to have the same expressiveness. You cannot program what you do not understand. But you must be able to talk about what you do not understand, if you are ever to hope to one day understand it.
I'd encourage you to read both more about linguistics and compilers. If you're feeling lazy, Tom Scott has some decent linguistics videos and are aimed at STEM audiences. For more technical maybe see NativLang. For a book, checkout The Unfolding of Language.
In the first you say that ambiguity will not harm interpretation, in the second you say that it will cause confusion. I interpreted these statements to be contradictory because my compiler evaluates "harm interpretation" == "cause confusion" to be true.
I don't know if by "we've conversing" you meant we are or we have been conversing. Those two possibilities are close enough to one another that substituting the wrong one will probably not cause a catastrophic failure, but perhaps you meant to use the pluperfect to imply that the conversation was done in some "drop the mic" moment that was completely lost on me.
Telephone is not a game of ambiguity, but of noisy communication. If you start with cat you might get bat at the end, but you wouldn't get feline. You could easily win at telephone by speaking the same meaningless statement repeatedly and you can lose at telephone with a grammatically correct statement which is nevertheless phonetically similar to some other statement. "Blue blue blue blue" is going to make it, "blue crew flew you" probably won't. A fault in transmission is fundamentally different from a syntax error, more analogous to a letter getting lost in the mail or a mistyped letter on the keyboard.
There is a fundamental difference between getting your point across and getting a point across that's similar enough to accomplish your goals.
Consider the following statements:
"I want you to feed my cat
"I want my cat fed"
"I want feed cat"
"You food cat"
"Cat food"
"Weird Dog Rice"
"seltsamer Hundereis"
I am certain you know what I mean in the first sentence. I would be amazed if you could deduce the meaning of the last without further clarification. Between these extremes there is some point where your compiler's heuristics fail, and likely long before that you start losing nuance and details. Natural language error tolerance has its limits.
Now consider the following javascript expressions:
for (let cat in catstofeed) {feedCat(cat)}
var i=1; while (i) { try { feedCat(catstofeed[i-1]); i = i+1; } catch (e) { i = 0;};
var i=0; while (i) { try { feedCat(catstofeed[i]); i = i+1; } catch (e) { i = 0;};
while (i) { try { feedCat(catstofeed[i]); i = i+1; } catch (e) { i = 0;};
If you substituted the second for the first, you'd accomplish what you were setting out to do. The third would lead to a wildly different result but is still valid. The final case is ambiguous, a smart compiler could guess the programmer intended for statement 2's functionality, but asking for clarification is the safer option.
You are right that trying to have a human conversation with only a few dozen words and a very limited sentence structure would be very difficult - a vast vocabulary and complicated grammar is a hard requirement for a natural language, and ambiguity is thus unavoidable. Dealing with such a high level of ambiguity is thus also a requirement of a natural language compiler, and such a compiler is beyond the capability of any existing silicon computer. But just because a language has more words and more valid expressions does not fundamentally change what it is, any more than adding more processing power to a computer eventually makes it stop being a computer.
If you wanted to make a programming language with 50000 keywords and an extremely forgiving syntax, you could do so. It would be extremely impractical for programming a current computer, which is only capable of a few distinct operations and thus has no need for nuance, but it would still work, and damn wouldn't it be great at self documenting.
Wrong syntax is more like using the wrong words in human languages than it is like what we normally call bad grammar.
If you write in C 'foo(a;', that's equivalent to saying 'ball foo with a' - the compiler really can't understand what you mean.
The equivalent of 'I go store' is something more like writing 'int p; printf("%d", p);' - the compiler understands what you mean, but it's bad style, and possibly wrong (you're supposed to initialize a variable before you read it).
I’ve found that reapproaching language when things don’t make sense to be very valuable.
Gender in German, for instance. It seems to be completely arbitrary save for one detail: whichever “sounds” best. I compare this to using “a/an” in English (albeit the rules in English are somewhat more “strict” in this regard.)
The only time I'm going to correct your grammar if you haven't explicitly asked me to is if there's some ambiguity and you're saying something important for me to know e.g. making a specific request. Otherwise, if I think I get what you're going for, imo you're doing fine. Talking good is mainly useful as a class indicator.
One thing I think I've noticed among a lot of people who have lived in English-speaking countries for a very long time is that, after their accent reaches general intelligibility and their grammar reaches a point where they're always quickly understood, they stop progressing and leave it at that. I knew an Iranian-American guy in his 50s who had been in the US since his 20s who would drop every article except when it was important.
For your compiler, everything not stated explicitly is ambiguous and potentially important. Talking good may not be necessary for every day conversation, where the stakes are typically low, but you'd go out of your way to avoid grammar mistakes in something important like a legal contract or a published article. Presumably if someone were talking you through modifying your computer and a single wrong move would brick it, you'd ask for clarification should they say anything even remotely weird.
> Which is obviously the complete opposite of using a programming language.
I think learning programming by learning all the rules upfront and then trying to do sth isn't the best way to do it. Much easier to try to do something and iterate quickly learning what's needed to do the job. That's how people learnt programming on 8-bit computers - type a sample program and change stuff to see what it does. Then find something you want to achieve and try to change the sample program to do that. Eventually you understand how basics work and can learn everything else.
That attitude is actually how I program—with scripted languages I write code and see what happens, if it didn’t work I write it again. I’m relearning C++ now and am doing it a similar way (albeit I have to be a little more careful because compilation makes it a lot slower).
At one point, I wondered if this same strategy would make for a good (human) language learning app. Kind of like you described... rather than something like Duolingo where you have to memorize answers, it might help to have a conversational app where you see the results of your attempts in real time.
> That attitude is actually how I program—with scripted languages I write code and see what happens, if it didn’t work I write it again.
This is an incredibly harmful attitude towards learning, but it feels nice because it's a lot less effort than actually trying to read or listen to something to learn. It's just laziness.
Learning C++ this way is how someone would end up with a buffer overflow every 30 lines of code they write. It's the reason some self-taught developers can't give you the fuzziest definition of the difference between O(n) and O(n^2).
The closest approximation of this is how kids learn to speak, but this is incredibly inefficient, and they receive many years of formal education anyway.
It isn't only guesswork -- there is a lot of reading and researching involved too. I figured that was obvious but perhaps it was not. The point is that it is learning by doing rather than rote memorization and recall. It is easier for me to do something, see the result, and figure out what went wrong if it didn't work. It allows me to understand the function behind something, versus just being told "this is how to do something and you should always do it this way" without an explanation as to why.
What works for you isn't what works for everybody. And I'm absolutely not denying the importance of learning theory.
I have to chorus GP. Learning by doing before I have a great understanding or perhaps sometimes far earlier (of course talking about studies on my own time) makes me think through the how and why more thoroughly partly because there is a tanglible goal of getting the piece of code to function as intended versus a more nebulous guess at having understood or not.
Yes, it seems like spoken languages can have a rather pronounced Ballmer Peak when you are learning them and are not very good at it. And the peak is much further out than with programming languages.
> obsessing over grammar is almost detrimental to making progress with a new language
If you skip over the hard parts, then you're not exactly learning a language. You might as well just learn from one of those "Hello, my name is Bob, where's the toilet ? " cartoon books.
Its a bit like those people who learn programming informally. Most of them end up writing spaghetti code for the rest of their lives.
Its the same with languages. Skip the hard bits and your attempt fluency will hit a wall at some point relatively early on. Grammar is tough, but stick at it, it will eventually become second nature. Don't be lazy.
If you master grammar but can't pronounce anything, or your vocabulary is too small, or you have no confidence to speak, or you don't learn the way natives say things through trial and error, then all your efforts are completely wasted.
Language isn't just some word for word translations and a new sentence structure, it's much much deeper than that.
The only thing that is required to learn a language is tens of thousands of hours of practice.
>If you skip over the hard parts, then you're not exactly learning a language.
That's not true. Most native speaks have little knowledge of the grammar and syntax beyond intuitive. They have forgotten most of what they've been taught at school, plus, they could speak quite well before going to school and being taught grammar in the first place. We acquire language by osmosis, not by studying, and even less so by studying the syntax.
> Most native speaks have little knowledge of the grammar and syntax beyond intuitive.
The fact that they don't know the scientific names of the grammar rules doesn't mean that they don't know grammar. As somebody how's native language is very dissimilar to English, my intuitive language rules are no help speaking English. The grammar you are taught at school is descriptive of English and not a prescription. The distinction s very similar to "laws in physics". Nature doesn't really care about the rules we impose on it.
Learning grammar alone is not enough. Learning vocabulary alone is not enough. Immersing yourself to a language without a guide (like your parents guided you into language) is completely ineffective.
Grammar, vocabulary and pronunciation are equally important if you want to get fluent in both spoken and written communication in a different language.
>The fact that they don't know the scientific names of the grammar rules doesn't mean that they don't know grammar.
Similarly the fact that they don't study grammar and skip the "hard parts" doesn't mean that they don't pick up/know grammar, so the original argument is moot.
Apparently knowing grammar acts as a filter for bad speech, but it doesn't actually generate speech itself. Learning to speak is based on direct experience, not abstract rules.
I like that example of "learning a board game." When I read text I "hear" conversations, and when I read code I "see" structures. Definitely different parts of the brain being activated.
I find this mirrors my experience. Although written language does eventually call upon highly visual parts of the mind, the structures and mechanisms I visualize when reading code are more highly dimensional than the initial mentally vocal interpretation of text. A program small enough to hold entirely in my mind that I know well, such as a piece of demo-scene code I'm golfing, is a sort of multifaceted non-visual abstract sculpture with features and values that interconnect in a seamless manner that I can interact with and predict the effect of my modifications on. I highly enjoy being utterly engulfed in the flow of this simultaneously logical and artistic activity.
That is how I have thought about code as well. I sort of grasp the "shape" of it, and the analogy to a board game is a good one. I think it supports why it is hard to talk about code, if we thought of it as speak-able units we could paraphrase it.
This is also why visual low-code programming might actually succeed: it's closer to how you think about code than the actual code. It has the opportunity to visualize the structures you want to see, so you don't have to make that translation yourself.
Visual low-code programming sounds good until you try to express actually non-trivial stuff in it, and you start appreciating text-based flow control again.
My take is that since code and data are highly dimensional "ideas" living in a one-dimensional address space, the two dimensions of visual programming that don't match any of the two are more of a distraction.
For visual low-code programming to align with how I visualize code, it would need to have one modality for when I'm writing, and a much richer, more complex modality for when I'm troubleshooting. There is a lot of emphasis in visual low-code programming on the first but not the second modality. There is a third modality for reading as well, which is very similar to troubleshooting but usually can be mostly a subset of troubleshooting.
YMMV, but the way I reason through while I read/write/troubleshoot code are mentally visualized and mapped in very different ways. When I compare what I visualize with the junior engineers I support, their visualizations tend to stop at a much higher granularity level. I strongly suspect that I engage in techniques that would be extremely familiar with and be on far more elementary level to those who practiced building "memory palaces" [1].
I have tried to teach this to the junior engineers, but the vast majority are simply wired differently it seems, and the few who "get it" do not sufficiently make it a habit to internalize it, much of which at first involves tedious pencil and paper.
I remember as a kid while blundering about a PDP-8 drawing on paper what I thought was going on at first with labeled boxes and lines (most of which was laughably inept and naive), then gradually transferring that to memory. Over many years of practicing that, it eventually became a reflexive habit. For more difficult problems I encounter today, I still sit down with pencil and paper and diagram it out to talk myself through it and build up a mental model.
For me personally, engaging spatial, motor, visual, verbal, and auditory senses together makes up my "visualization" in an iterative process that gradually internalizes into a pure mental model. That's why I prefer to look like a mental patient in the confines of my private office than at a co-working space or coffee shop.
This. And the more programming languages you learn (especially across paradigms), the more each new language is more of a tree search of basic fundamentals. Certainly some paradigms fit oddly in others, but even then familiar patterns emerge[1].
[1]: For example it’s occurred to me a few times that early Node interfaces were an opportunity to introduce monad types to idiomatic JS development. Sure, it was callback hell, but basically everything that touched IO had an Option type, just in the form `type Callback<T> = (error: Error, value?: never) => void | (error: null, value: T) => void`
Edit: I’m sincerely disappointed the sibling reply got downvoted and dead, it was a valuable contribution. To resurface, the sibling commenter distinguished the cognitive experience of code versus human prose from the perspective of someone who’s autistic. It’s a distinction I share (diagnosed ADHD, undiagnosed but strongly suspect ASD spectrum).
Edit 2: no longer dead so I'll defer to the sibling comment.
I was originally surprised by the study and your comment, since I generally find no difference between natural languages , math and programming languages. (I am a math major).
However, most of the people I interact with find my exposition methods curious in sense of structure. So, I shared this study with some of my friends, and they agreed with the study too. When I pointed out my surprise to them, they told me that I speak like a computer program in the sense of structure of exposition.
So, I guess I agree with this study in general, and actually would love to know what's going on in my brain.
For what it's worth, I am fluent in 4 natural languages from two different families and I'm learning a fifth language. Also, I'm fluent in multiple programming languages.
I have the exact opposite experience. For me, part of the problem is that in math, you have options. If you forget the quadratic formula, you can:
- Re-derive it by completing the square on the general quadratic
- Solve a specific quadratic you're interested in by factoring or graphing
- Try to find zeros with numerical methods
The point is, everything's connected to everything else, so it doesn't matter if you forget any part of it as long as you remember some critical mass.
To be fully fluent in a programming language, you have to memorize two or three dozen keywords and a handful of operators (mostly the same as standard math). To be fluent in a natural language, you have to memorize two or three dozen words a week for years. Not to mention understanding all the insane grammatical stuff.
With human languages, sure it's easy enough to remember that "nec-" means "dead" (especially if you consume fantasy novels / games where necromancy is a school of magic), but you're still totally screwed if you can't remember whether the word you need is "necare" or "necire," "necobitis" or "necabitis" or "necibetas". There's no rhyme or reason to any of it, your knowledge won't help you figure out whether that letter's supposed to be an "o" or an "i", or the difference between past tense and future tense and perfect tense and imperfect tense and tensile strength and gaaah why is this all so complicated!?
It's like if a programming language had 20 different versions of each keyword, and they were all spelled with one or two letters different, usually only the vowels are different. And they all compile, getting the wrong one just creates subtle semantic bugs at runtime. And there's a maze of rules telling you which version of the keyword you use if you're inside a loop body or a function body or a conditional statement body. Oh, and there are six different versions of the "if" keyword, and they're all two letters long, good luck getting the right one of those. And if your code's going to be executing two or more times, all the names of your variables will suddenly be different. And when you refer to a struct outside of the function that created it, all the field names are transformed. And whoever was writing the compiler put ten different special cases in the code for transforming your variable names, just because they could.
That is such an interesting and...low-level way to think of it.
To me it feels a little deeper than just there being a "maze of rules". Your earlier mention of "everything's connected to everything else" resonated with me more.
In a sense, the expressive power of programming languages, and mathematical notation, feels very small. I liked the board game metaphor brought up in the top comment: programming languages and mathematical notation merely feel like arrangements of board game pieces (from an infinite box, and the rules of how they can be arranged are "context-free"). They don't have meaning except what we impose (ideally, assisted by comments).
A metaphor I brought up in another comment is that it feels "easy" to systematically translate an arbitrary program into an equivalent diagram, such that the diagram would contain 100% of the operational information in the program, and could be runnable as-is. (Would be cumbersome to input into the computer, ofc.) Whereas the idea of systematically translating an arbitrary natural sentence into a diagram just seems...nonsensical to me. I wouldn't even know where to begin.
> Whereas the idea of systematically translating an arbitrary natural sentence into a diagram just seems...nonsensical to me. I wouldn't even know where to begin.
we actually literally did this in high school. It was very informative for me.
This is really an interesting thought. Would it surprise you if I said that for me, it works in an opposite manner? I first think in terms of diagrams and the construct sentences for it, whether it be programming language, natural language or math.
Others here, and presumably your friends, have talked about how they think of programming "visually", but they don't think visually about conversing in natural language.
I thought of a concrete way to describe it: it "feels obvious" to me that any programming language could be "easily" replaced by a systematic diagramming method, with programs translated systematically into equivalent diagrams. If anything, a diagram would be clearer and more readable to me than the same program in plaintext. (Of course, it would be much more cumbersome to input such a diagram into a computer than plaintext.)
Whereas the idea of systematically translating arbitrary natural language sentences into diagrams is...nonsensical to me. I mean I wouldn't even know where to begin.
I'm curious if for you, do you feel like you could easily systematically translate a natural language sentence into a diagram? Or, because you don't think as visually as people like me, translating a program into a diagram is not "obvious" to you at all? Or maybe this distinction just doesn't feel significant to you, one language being diagram-translatable and another being diagram-untranslatable doesn't cause them to feel different, they feel equally language-y to you?
Context-free grammars were originally invented by linguists for analyzing natural language. You can see examples of phrase structure and dependency diagrams e.g. here: https://en.wikipedia.org/wiki/Dependency_grammar
For what it's worth, I agree with OP, and have a very "language-oriented" thinking style. I certainly don't visualize anything while programming or doing math (except for geometry and the like). My thinking feels like it's more based on constraint solving and seeing analogies between domains.
I do feel that I could easily translate natural languages into a diagram as well. I am a very visual thinker, but that visual seeps into natural languages as well.
Whoops, missed the comment window on all the replies to me except for this one!
I clearly completely failed to communicate what I meant about "diagramming" a programming language, as evidenced by all the people pointing out that syntax tree diagrams work fine on natural languages, and indeed were originally created for natural languages, which is totally missing the point.
What I meant was that the semantics of programming languages are so limited and constrained that they could easily be translated into an "executable diagram", such as a control-flow graph for imperative code, or a dataflow graph for functional code. The syntax of natural languages is indeed more-or-less similarly constrained as programming languages, but the semantics of natural languages seems completely nebulous and ill-defined to me.
To use the board game analogy from earlier, you could conceivably learn to play chess entirely in terms of chess notation ("1. e4 e5 2. Nf3 Nc6 3. Bb5 a6"), without ever learning about the 8x8 chessboard or the 16 pieces. Chess notation shares no syntactic structure whatsoever with the "syntax"/diagram drawing rules of a chessboard and pieces, yet their semantics are exactly equivalent.
In the same way, the "syntax"/diagram drawing rules of control-flow graphs has no syntactic structure in common with imperative code, yet exactly equivalent semantics. Could you imagine a diagram system that has no syntactic structure in common with natural language, yet completely captures the semantics?
I cannot begin to imagine that. The semantics of natural language defy description.
I'm curious what's your first language. I'm learning Mandarin and find that it feels much closer to a computer language than English or Latin based. Though I don't think I'd say learning Mandarin (or any language) is anywhere near what it's been like learning computer languages. I find mathematical language different from both as well. They do feel like 3 different parts of my brain. Though math I'm highly visual (not this way in programming or English, but visual in Mandarin).
That could be because Mandarin grammar is actually relatively simple, the difficulty is in “naturally” expanding your vocabulary (since characters take an order of magnitude longer to learn).
It wouldn’t surprise me if a lot of it feels like brute forcing syntax and keywords - there’s no way of reasoning through it, you just have to knuckle down and learn it.
It’s also part of the driving force behind my app (link in bio) - it can take a long time (i.e. years) to get comfortable carrying on a conversation, so I want to help people practise in a less intimidating environment.
Similar situation as you. I view programming more like seeing patterns, structures and constructs for solving problems, which is completely divorced from natural language grammar.
The "language" part in programming is really just a vernacular term for describing differences in syntax, and has no parallels with human spoken languages.
Whoa, the complex board game analogy is new to me but it rings so true. Like you I’m bilingual. Like you I know many programming languages (dangerous level or above). To equate learning “syntax” of the language as learning a complex board game is such a great analogy.
science isn't when you just decide that things are obvious and leave it at that lol. They probably have data and an experimental methodology and stuff now that future authors can build on to try to answer more complex questions.
On the one hand, the design of Python implies that they think the natural language parts are important. On the other hand, yes we should confirm things that are our intuition says are completely obvious, otherwise when our intuition fails (as it frequently does, see the point about Python) we end up optimizing the wrong thing.
As a total monoglot who regrets not learning languages properly when he was a kid, this still seems pretty obvious to me that at least I don't read code in the way I read natural language, or maths.
However it's always good to have intuitions like this confirmed or refuted by actual investigation, and putting them on a more solid footing within the broader context.
My personal experience of reading code has always felt more like looking at a mechanical mechanism, or perhaps solving a paper maze where you see the whole thing at once but can focus on parts as well. It isn't something I look at one line at a time, I read it in structural blocks, almost a breadth-first reading. I see the if/else statement and structure before I see any of the details of each branch. It's a deeply non-linear process of going up and down levels of abstraction where necessary, and ignoring details at lower levels that are irrelevant to the task at hand.
Not just writing code; reading code is different too. Often I page thru code, looking around, getting the size and shape of it. I don't read every word; I'm not sure what I am doing but it isn't the same as reading. Absorbing, maybe.
Or perhaps we should accept that programming a computer is more like playing a board game and less like speaking, and optimize languages along those lines.
I don't think making a programming language more like natural language would be helpful. It's much harder to learn a natural language than a programming language.
No, not at all. Natural language is imprecise, ambiguous and heavily contextual in both its structure and semantic meaning. All those qualities are sources of bugs or undefined behaviour in programming.
As others have said in this thread: programming "languages" are not like natural languages for a reason, and conciseness is a big part of that. The two fill a completely different role, and it should be obvious that the brain structures involved are different too.
To illustrate that: the only reason people are surprised that programming languages and natural languages are dissimilar is because our natural language is ambiguous: it calls them both "languages" even though they serve entirely different functions.
This was attempted using COBOL with a varying degree of success depending on who you ask. I myself have not used it but it seems to me the verbosity would be a major drawback for most tasks. Perhaps one can learn to read it quickly but I believe having shorter yet self documenting names for variables, functions, objects, etc leads to being able to store more in our limited human working memory, which is vital for more complex operations. Code structured more like natural language takes longer to compile, and takes up more disk space. Perhaps these are not such drastic drawbacks for the use cases it was developed.
This has failed in the past (AppleScript). Another way to do it would be to make the language “vague” in the same way a poorly formed English sentence can still be understood, but I think this would fail too - the most important thing for a tool is to be predictable, not clever.
Ruby’s syntax does seem to be informed by Japanese word order, so that’s nice.
This have been tried. Languages like Perl and AppleScript was deliberately designed to feel more like natural languages. It turns out this lead to a worse programming language.
I agree, this is probably because we never 'speak' (although write) in programming languages trying to convey something. This goes same for 'hearing' (although we read and understand, hopefully). We always use human languages for those purposes, well, except for those times we speak in pseudo-code.
These are borrowings or coins into a natural language. A word from bash does not mean you are speaking bash any more than saying macaron would mean you are speaking French.
As someone who is a lot less proficient in coding languages and speaks a bit of Spanish. It’s still really obvious. Not sure why anyone would think of them as equivalents aside from both being named a ‘language’
But for two completely different audiences: One extremely precise and extremely stupid, the other is a computer. Just kidding! The other is a creature like you and me.
I am autistic.. I read code and "interpolate" across lines quite well.
On the other hand, finishing one basic written sentence can sometimes be a surprising struggle.
It was pretty popular when Ruby and JS came on the scene. I think it’s receded now but there are still tools like Homebrew that are worse than what came before, but people switched to them because they were written in Ruby instead of Perl, and somehow that made it cool.
Having fumed for years about the too-often poor state of software documentation and program comments, I was not surprised by the result, although it was nice to see it proved.
What did surprise me, though, was the lack of similarity to mathematical thinking. Was, this, though, because they used fairly simple snippets of Python, a programming language which is not very mathematical in its notation? Would a different result have been obtained had they asked the subjects to reason about a multithreaded C++ program which copiously used autoincrementing pointers and polymorphism?
And, can personal preferences in programming languages be partly down to which parts of their brains people like to use?
And, as the problems were simple, the study doesn't say anything about expert programmers. Is the often-quoted 10× difference between the best and worst programmers associated with the best ones also involving the mathematical and linguistic parts of their brains?
It's probably not practical to measure programming at a high level (or indeed violin playing at a high level) inside an MRI machine, given the cramped and noisy conditions, so we may not have answers to the interesting questions raised any time soon.
> What did surprise me, though, was the lack of similarity to mathematical thinking
I've noticed that many programmers hit a wall when dealing with Haskell or mathematics because notation that I parse effortlessly they have to puzzle over symbol by symbol, so I suspect it is a different system.
> a multithreaded C++ program which copiously used autoincrementing pointers and polymorphism
I'd hazard a guess that the results would be the same. It all boils down to (multiple) sequential processes, which can be analyzed by spatio-temporal reasoning.
Functional programming, on the other hand, may be different. When "execution" of your program is driven by beta-reductions and control flow can be abstracted away, it becomes less certain that spatio-temporal reasoning is the right tool for the task.
And, yes, I hit the wall madhadron mentioned in the sibling comment.
I find this to be true only because learning a language is not just writing – there's also the speaking and listening component of it.
I find that I'm able to start writing a language and learn its grammar fairly quickly, but once I have to listen and converse in it it's like a whole different ballpark.
So this may mean that language models like GPT-3 are not best suited for code generation tasks. And networks trained on languages may not learn the feature embeddings needed for programming languages.
Wouldn't the empirical success of GPT-3 in simple programming tasks itself be evidence against this interpretation?
Furthermore, GPT-3 is only a language model because it is trained on textual data. Transformer architectures simply map sequences to other sequences. It doesn't particularly matter what those sequences represent. GPT-2 has been used to complete images, for example: https://openai.com/blog/image-gpt/
Empirical success shows that the GPT-3 model has seen the sequence before(maybe many times).
Transformer architectures do map sequences to sequences. What is not known is that the task of programming is a sequence problem. This experiment seems to suggest that maybe its not a sequence problem.
There was a time when 'a set of computer instructions' was called a 'routine'. Computer 'languages' are extremely restricted, and are primarily logical.
Unlike human languages: English (and probably most others) has hundreds of words that can be used to nuance, imply, suggest, refine, gradate, distinguish, obscure, conceal, intimate, impute.
If we don't know what they mean we can often skip right past them. (Computers don't do 'gist'.) Illogic is not only permitted, it's often essential.
I think it's closer to legal work, like drafting an agreement or a contract. You have to define the behavior of all the actors the ways they will interact with each other etc.
Totally agree with this. A weird hobby of mine is reading through dense legal contracts, government acts and things like double tax treaties. I enjoy it like I enjoy programming. The mental process I use for understanding these docs and thinking about how I would modify them maps very closely to the "board game" analogy made higher up in this thread.
In general the law is absolutely not so rigorous. It's more like general philosophical literature in terms of logical rigor--diverse, disjoint, etc. But certain subdomains of the law can be closer to a formal system.
The French tax code is peculiar (though I'm not sure its unique) in literally being defined by the rules encoded in an official program. A recent paper on a new language for compiling those rules, "A Modern Compiler for the French Tax Code" (https://arxiv.org/pdf/2011.07966.pdf, via HN a couple of weeks ago), contains a blurb at the very end,
> Closer to the topic of this paper, the logical structure of the US tax law has been extensively studied by Lawsky [18, 19], pointing out the legal ambiguities in the text of the law that need to be resolved using legal reasoning. She also claims that the tax law drafting style follows default logic [24], a non-monotonic logic that is hard to encode in languages with first-order logic (FOL). This could explain, as M is also based on FOL, the complexity of the DGFiP codebase.
EDIT: I once took a class in law school taught by a Professor of Systems Engineering from the parent university. I forget why, but long ago he took an interest in the rules of evidence in the common law. While the rules evolved organically over more than a thousand years, they actually strongly reflect a formal system of abductive reasoning: https://en.wikipedia.org/wiki/Abductive_reasoning. And there's significant, hidden rigor. In one project he had everyone in class create a tree consisting of evidence (e.g. size 7 shoe) at the leaves, with the branches as inferences all the way up to the top, which was the core legal claim--1) Jim did 2) break and 3) enter into 4) said building.... Anyhow, being a programmer I decided to create my tree using the DOT language and render it using Graphviz. While I was doing that it occurred to me that some of the more esoteric, technical rules of evidence, such as that any piece of evidence can only be used to prove a single element, actually ensures that the tree is an acyclic graph. I'm not sure precisely why (perhaps the professor had more insight), but I believe it's because the rules are in part crafted to ensure that the finder of fact is presented with a tractable problem to solve. The process would get too confusing (and possibly logically inconsistent?) if you didn't keep the tree of evidence and inference simple. No judge or lawmaker likely ever had in mind the literal shape of the evidence tree. In fact, AFAIU nobody thought to represent it as a tree until the late 19th century, when the famous scholar of common law evidence, John Wigmore (https://en.wikipedia.org/wiki/John_Henry_Wigmore), developed a system for analyzing and preparing trial evidence in that manner.
Anyhow, a proper and infinitely more rigorous treatment of this is presented in the book, "Analysis of Evidence, 2nd Ed." by Terence Anderson, David Schum, and William Twining. (Schum taught the class.) A large part of the book explores and explains the law of evidence as a system of Bayesian reasoning. (Oh, that's why! I think Prof. Schum first stumbled into the legal realm after he got the idea of using Bayesian statistics to resolve historically famous and contentious legal trials.)
> Yeah, laws and contracts are basically pseudocode;
Are they? Do you say this as someone who is familiar with actual laws? Genuinely asking. Because I know that engineers (my past self included) like to imagine formalizing laws and turning them into code, which is extremely naive, once you see actual laws and how much human common sense judgment is needed to decide on them, including inferring intent, judging potential consequences, interpreting imprecise terms, etc.
Perhaps a part of the tax code is like code. But a lot of laws are far from it. It's more formal than novels but it's firmly natural language that you need to understand as a human.
"Basically" was sharing some heavy lifting with "psuedo" on that sentence. Tell ya what, I've got gobs of experience with pseudocode, and much of it requires tons of common sense judgement, inferring intent, judging runtime and memory management consequences, interpreting imprecise terms, etc.
Agreed. Vague pseudocode and fairly narrowly focused laws are quite similar in nature.
I'd also compare these two to mathematical proofs written in natural language in textbooks or academic papers. They have recurring structures and patterns, but are not formalized proofs, leave things explicitly or implicitly as an exercise to the reader or assume cases as trivial. (The gap to a formal representation is often nontrivial effort and has never been totally done for most of math)
But then again, we have lots of similar things. Household equipment user manuals, revenue reports, soccer match descriptions in newspapers, stock market updates, phone calls to make an appointment at the dentist, etc. Lots of things on various points of the structured/formal/closed -- unstructured/informal/open spectrum.
In programming the variables are saved in RAM and RAM is limited and has scopes (e.g. global scope, local scope). You also have linked lists, arrays etc. I imagine spatial navigation is very useful to handle all of these. In math you don't care, your variables are defined globally and if you have multiple with the same name the context decides which one is used.
Math is not concerned with implementation details.
This is hardly surprising. The only reason "programming languages" are called that is because early computer scientists borrowed from linguistics research at the time which defined language as a set of strings. Programming is general purpose problem solving, the fact that it is expressed in mostly English words is arbitrary e.g. Brainf*ck.
It's irrelevant how a language is implemented. Math notation is also a language and it barely uses any English words.
I don't see meaningful differences between languages whether they are computer languages, human languages, math notation, except how the human brain processes them.
>linguistics research at the time which defined language as a set of strings.
Fundamentally there is nothing wrong with that. You can have trivial languages that follow simple rules. In practice humans tend to use more complicated languages but that is just their personal and cultural preference.
People here are too hung up the message that is being communicated rather than the general idea of language as a communication method. Programming languages usually express algorithms and trigger logical sections of the brain but nothing prevents you from using a human language to express the same algorithm and trigger the same sections of the brain. The reason why people associate programming languages with logical thinking is that they were exclusively designed to communicate logic and nothing else.
Seems like a weird conclusion to draw. If programming languages are arbitrary why didn’t we stop abstracting or creating new ones?
The language is often a reflection of the problem it was intended to solve. Would you really argue that Brainfuck can solve your problems just as well as Python?
Not that programming languages are arbitrary, but that the choice to use words (Python) rather than, say, punctuation (Brainfck) or emojis is because is easier for our human brains, thus arbitrary. But the task at hand is still problem solving, not language processing (at least not in the capacity of a typical conversation). I think a good example of this is the popularity of code visualizers. The only thing stopping Brainfck from solving your problems as easily as Python is the ease of human understanding, not some fundamental property of Python being more “language-like.”
I wonder if REPLs would be processed closer to a spoken/written language. I really like "conversational" command lines, and I'm curious whether that subjective feeling of conversationality is because I am using linguistic brain structures, or if it's something else.
>The subjects in the study were all young adults proficient in the language they were being tested on.
They name Python and ScratchJr, but no hints on what spoken languages were examined. I've been told Chinese and Japanese are much closer than Romance languages to code.
That's a very strange statement, since Chinese and Japanese are not at all similar languages. There are some loanwords, the shared writing system and a lot of historical and cultural, err, interchange, but they have no shared linguistic ancestor and grammatically are just about as different as languages can be. Linguistically, Japanese and Chinese have about as much in common as English and Navajo.
They are similar because they are both logographic languages. The MIT team should of added logographic languages in their experiment for the same reasons in this blog post:
Chinese script is logographic, Japanese only partially so.
But a language is not its script.
By approximation all modern languages that have been written have been written in the Latin script. That doesn't make them "similar languages" in any real sense. And conversely, many languages use several different scripts for the same language in different regions/groups depending on politics.
I wonder if that also applies to legal writings. When I'm reading legal agreements, my mind tends to be in programming mode as well: I see lots of defined variables, if-else boolean statements, and error handling (quite literally).
Using the term “computer language” was an unforced error. Made perfect sense intuitively yet one could argue it’s a disservice since, as others have pointed out, it lights up completely different sections of the brain.
I have never liked the term “programming language”. Niklaus Wirth said somewhere that a better term is “programming notation”, and that has always stayed with me.
That said, I like to understand a program (especially my own) by explaining it in English. There, I'm using generative, rather than recognition, processing. There might be some fruitful research in asking people to explain how programs work, rather than what they do, under fMRI.
Are the algorithmic (Leetcode style) questions asked in many coder interviews more like coding, mathematics, or neither more like one than the other; and, whatever the answer, is this relevant to anything important?
The relation between programming and math or natural languages is well known, but the link to spatial navigation is novel to me. I assume it's conceptual-space-navigation for programming.
I’d say it’s more akin to reading the directions for solving a puzzle, like the moves list for a chess game or something, while imagining the board in your head.
We could use a longer for thing like coding system (codesys)? And then you could say I'm working on the Rust coding system, or the Rust codesys, or the Rust code itself (lazy version).
based on my own experience and intuition- programming is most akin to machining or woodworking. its a craft, and its only because its highly paid do people think you are smart because you are good at it.
I wonder what kind of computer code was shown. I find there are times when reading boiler plate code/code that has more to do with API calls or the likes one does not need any kind of logic/problem solving but just shallow understanding
My university went so far as to allow students with a bachelor's degree in music to directly enter the computer science master's program.