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.
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
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".
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."
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.
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".
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 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'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.
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?
> 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 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. S...
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.
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.
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.”
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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”
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.
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).
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.
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).
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.
>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.
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.
> 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.
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.
> 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.
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.)
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.
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.
> 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.
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.
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'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.
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 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.
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.
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.
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.
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 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 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.
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.
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’
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.
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.
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.
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 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?"
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.
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]
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.
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.
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.
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.
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.
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.
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.
230 comments
[ 2.8 ms ] story [ 221 ms ] threadBut 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.
Oh well. Time to go code golfing!
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.
Exactly. That's why laws or contracts written by lawyers are so verbose. Think of a rent contract or a software license like GPL.
Contrast with WTFPL and similar...
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".
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."
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.
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".
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'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.
https://science.sciencemag.org/content/342/6156/377.abstract
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.
[0]: http://web.mit.edu/9.s915/www/classes/duncan.pdf [1]: https://i.imgur.com/xdYzbev.png
https://en.wikipedia.org/wiki/Logogram
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.
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.
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.
See https://en.wikipedia.org/wiki/Default_logic and https://en.wikipedia.org/wiki/Non-monotonic_logic But note that it's written in that "style", not that it's done consistently or correctly. Unfortunately I couldn't easily find a copy of the cited papers, but I made a note for later reference.
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. S...
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?
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.
In human language, you can play with idioms, metaphors, double entendre, etc.
In writing code, you miss one symbol and it breaks.
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.
[1] https://en.wikipedia.org/wiki/Method_of_loci
https://en.wikipedia.org/wiki/Structuralism_(philosophy_of_m...
Have you told anyone to grep, cat, mount, fsck, or sudo?
I'd say the more experience one has with a programming language, the more reading and writing it feels like a natural language.
This was my reaction as well: what, they needed to do a study to figure this out?
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.
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.
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.
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.
> 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”
Tldr: Compilers you need to be fairly precise, natural languages you barely need to be in the ball park.
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.
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 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.
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.
> 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.
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.
[0] https://en.wikipedia.org/wiki/Telephone_(game)
Edit: btw, you did get the meaning of finger shoes (German) even with the extreme limitations of only text based communication.
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.
That's because that's not what I said nor what I meant.
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).
If your English grammar is wrong, I will catch you.
Make progress.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
His students were objectively less skilled than the other spanish teacher that focused on vocabulary and conversational skills.
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.
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.
What works for you isn't what works for everybody. And I'm absolutely not denying the importance of learning theory.
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.
The "language" part in programming is really just a vernacular term for describing differences in syntax, and has no parallels with human spoken languages.
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.
West Germanic: English
Indo-Aryan: Hindi, Bengali
Dravidian: Kannada
And currently, I'm learning German.
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.
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?
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 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.
- 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.
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.
Does that resonate with you?
we actually literally did this in high school. It was very informative for me.
Yes, if you try to apply it to some parts of "Moby Dick" it will be rather painful. :)
Basing a computer language on a subset of English was done for several query languages, ranging from SQL to Attempto Controlled English (https://en.wikipedia.org/wiki/Attempto_Controlled_English).
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.
Ruby’s syntax does seem to be informed by Japanese word order, so that’s nice.
You take ideas in one form and express them in terms idiomatic to the other.
Sort of like computer viruses and biological viruses.
Legos with the all the rules of AD&D 2nd Ed.
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.
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.
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.
(though it's been.... a while... since I graduated.)
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.
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.
[0] The Dream Machine by Waldrop
[0] https://cacm.acm.org/careers/243179-forget-math-language-ski...
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".
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.
I saw a paper that argues that there are two factors: g and math. But that's tangential.
But limitedness of the methodology means the conclusion can't apply to software development at large, something that the title misleads us about.
[1]: https://twitter.com/wcrichton/status/1339235494102753280
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.
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.
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.
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 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.