Live data from Hacker News

To the brain, reading computer code is not the same as reading language

news.mit.edu

31–40 of 232 posts

Re: To the brain, reading computer code is not the same as reading language

#31
post #26

Earlier quoted context omitted.

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…

That’s not what arbitrary means. If we make languages in a certain way because it’s easier for our brains then it isn’t arbitrary by definition.

Re: To the brain, reading computer code is not the same as reading language

#32
post #28

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.

This. And the more programming languages you learn (especially across paradigms), the more each new language is more of a tree search of basic fundamentals. Certainly some paradigms fit oddly in others, but even then familiar patterns emerge[1].

[1]: For example it’s occurred to me a few times that early Node interfaces were an opportunity to introduce monad types to idiomatic JS development. Sure, it was callback hell, but basically everything that touched IO had an Option type, just in the form `type Callback = (error: Error, value?: never) => void | (error: null, value: T) => void`

Edit: I’m sincerely disappointed the sibling reply got downvoted and dead, it was a valuable contribution. To resurface, the sibling commenter distinguished the cognitive experience of code versus human prose from the perspective of someone who’s autistic. It’s a distinction I share (diagnosed ADHD, undiagnosed but strongly suspect ASD spectrum).

Edit 2: no longer dead so I'll defer to the sibling comment.

Re: To the brain, reading computer code is not the same as reading language

#33
post #20

So obvious next question is how does reading the law compare?

Yeah, laws and contracts are basically pseudocode; I'd expect it to be much more similar to code than literature.

> 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.

Re: To the brain, reading computer code is not the same as reading language

#34
post #14

This would explain why I can listen to music or TV while coding, but not while reading a book.

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.

Same. I play some 90s Goa trance on my headphones if I really want to get stuff done, but anything with lyrics completely throws me off.

Re: To the brain, reading computer code is not the same as reading language

#35
post #20

So obvious next question is how does reading the law compare?

Yeah, laws and contracts are basically pseudocode; I'd expect it to be much more similar to code than literature.

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.

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. Schum first stumbled into the legal realm after he got the idea of using Bayesian statistics to resolve historically famous and contentious legal trials.)

Re: To the brain, reading computer code is not the same as reading language

#36
post #18
post #6

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 t…

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.

Re: To the brain, reading computer code is not the same as reading language

#37
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.

Re: To the brain, reading computer code is not the same as reading language

#38
post #20

Earlier quoted context omitted.

Yeah, laws and contracts are basically pseudocode; I'd expect it to be much more similar to code than literature.

> 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 potent…

"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.

Re: To the brain, reading computer code is not the same as reading language

#39
post #28

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 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.

Re: To the brain, reading computer code is not the same as reading language

#40
post #38

Earlier quoted context omitted.

> 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 potent…

"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.

Post reply on HN