Badly-read literary snob
Is reading and understanding code the same as executing the code?
Yes
4.8%
No
95.2%
Poll ended at .
Feb 28 at 12:03pmWeb
Show threadCarlo ZancanaroFeb 28
@RosaCtrl If it was, we wouldn't need types or static analysis.
Show threadJannekeFeb 28
@carlozancanaro @RosaCtrl
If it was, a computer would be intelligent.
Show threadJannekeFeb 28
@carlozancanaro @RosaCtrl
And also, I have been known to understand a program and find it elegant and correct, while the computer disagreed...
Show threadJannekeFeb 28
@carlozancanaro @RosaCtrl
Which is, incidentally, why I dislike mathematics; you cannot generally execute it to be certain it's correct (as opposed to just elegant and seemingly/convincingly correct).
Show threadWynkeMar 1
@janneke @carlozancanaro @RosaCtrl There are ways to do this. I wrote my Master's thesis about a language designed for it. Talk to me about it when we next meet if you want (although it's multiple decades ago so I'm a bit rusty on the subject).
Show threadJannekeMar 1
@wynke @carlozancanaro @RosaCtrl
That sounds lovely!
Show threadJoost van Baal-IlićMar 1
@wynke @janneke @carlozancanaro @RosaCtrl lean and rocq are mathemical theorem provers, guess your thesis was about that or related?
Show threadWynkeMar 1
@joostvb @janneke @carlozancanaro @RosaCtrl Automath. I'll check if I have a (digital or paper) copy somewhere.
Show threadThe ol' tealeg 🐡Mar 1
@janneke @carlozancanaro @RosaCtrl I’m reminded of L. Peter Deutsch saying “Lisp ... made me aware that software could be close to executable mathematics.”
Show threadWynkeFeb 28
@RosaCtrl One could argue that in order to understand code, one would run through the code execution path in one's mind. But I don't think anyone would actually mentally execute the same loop a few thousand times or more, just reason what the outcome would be, so it's still not the same.
Show threadTomás LázaroFeb 28
@RosaCtrl I don’t like imperative code where I have to simulate the computer in my head, rather declarative pure FP style.
Show threadDavid RuffnerFeb 28
@RosaCtrl I said no, because that is not how I read the code. I guess I have mental models that give me a sense of what the code is doing without having to trace every step of the code path in my head. But I do write bugs sometimes, so maybe to truly understand the code you need to execute it. I guess that is part of the idea with test driven development.
Show threadpenryuFeb 28
@RosaCtrl On why no amount of thought is a substitute for actual testing: https://news.ycombinator.com/item?id=12761986
"Beware of bugs in the above code; I have only proved it correct, not tried it."... | Hacker News

Show threadRob RixFeb 28

@RosaCtrl yes, under an asterisk: literally anything a program does can be understood by abstract interpretation with a suitable abstraction of program values (“suitable” is load-bearing here), and to a given level of approximation. On one end of the spectrum, the concrete interpretation of the program is a degenerate instantiation of abstract interpretation. On the other end, you can absolutely pose undecidable questions like “will the program halt?” for example, but the answer will sometimes be “maybe.”

Furthermore, abstract interpretation is mechanizable (cf David Darais’ thesis, Mechanizing Abstract Interpretation), so we can compute these analyses.

So: “executing” is necessarily a complete lens on program behaviour, given the above abstraction of what it means to compute. We do this in our heads when we read and understand a program for example to debug it.

We also synthesize a higher-level understanding, connecting the program to concepts not immediate, or sometimes not even apparent in the syntax. Since this is (IMO) “just” another kind of semantics, it’s subject to the above as well.

But understanding what a program does is not the only way of understanding a program. Why was it written? Why was it written this way, or in this language? What was the intent, what are the social factors that shaped it, how has it evolved? Because of course source code is a program, but the whole light cone that led into its state at a given point in time is potentially relevant to understanding it through these lenses.

At the end of the day I think we care more, moment to moment, about understanding program behaviour than programmer intent, and probably that’s appropriate; the Purpose Of a System Is What It Does (POSIWID) is an extremely valuable model. But we also ask ourselves questions about what a program was, and what it could be, and some of those are less about program behaviour than about expression or form, and there are many equivalent phrasings of a program, in terms of its observable properties, that are nevertheless possess extremely different properties for the reader. Consider linters, formatters, minifiers, obfuscators, alpha renaming, refactoring, etc.

So I said yes because I wanted to share about fifty-two years of abstract interpretation (thank you Cousot and Cousot!), but also no. A waffle, but, I think, a principled one.

Show threadBeady Belle FanchannelFeb 28
@robrix @RosaCtrl I often find myself thinking about original intent more than about the actual code (see: Chesterton’s fence, elimination of complexity without removing important branching etc).
Show threadBeady Belle FanchannelFeb 28
@robrix @RosaCtrl So the extended question: Do you need theory of mind in order to understand code?
Show threadBadly-read literary snobMar 1

@Profpatsch @robrix this got me thinking and this is what I came up with: if we wanna understand intention, then yes, I think theory of mind is necessary.

Now, if we wanna understand how the code itself behaves, regardless of how it come to be, then no. However, I don’t think we use some specialised capacity for it. Theory of mind is a name we gave to an specific intelectual activity, but it’s not like well defined, so I’m inclined to say that the same thing that allows us to understand other people allows us to understand how abstract things behave

Show threadBadly-read literary snobMar 1
@robrix regarding abstract interpretation being mechanisable I would add that mechanisation is always better. After posting the poll I started to think on how well I could trace the behaviour of simple algorithms with pen and paper, but give me something with concurrency and I’ll keep making mistakes all over the place
Show threadcraignicolFeb 28
@RosaCtrl @onepict there are multiple versions of the code that, when executed, will produce mostly the same result. I would reject 99% of them at code review.
Show threadBeady Belle FanchannelFeb 28
@RosaCtrl I said no, but in actuality understanding code probably requires at least partial execution on behalf of the brain, based on intuition
Show threadXLBillyMar 1
@RosaCtrl Reading = Parsing + Understanding, not executing