The Physics of Readability
loup-vaillant.fr
loup-vaillant.fr
If we have a linear process with a large number of steps, it can help to group them hierarchically via functions, just as a play is divided into acts and scenes.
Functional decomposition was once taught as an important technique in program design (related to the "top down" approach). I believe it still remains important.
Here is an example of a function called only once: a module initialization function. If we take the advice literally, we shouldn't have an init function that calls numerous other init functions one by one. Since they are called once, we should pull them all into that init function. Well, what is that going to do to the cohesion and coupling.
We can think of each function (those make up our program) as a channel in information theory - input values are input symbols and output values are output symbols. Our "not understanding" of what the function does is modeled as the noisiness of the channel, so the higher the understanding, the higher the information gain between inputs and outputs of the function.
But I never got around to compose the channels and their associated entropies, which would be the goal of this formalization.
https://twitter.com/willrftaylor/status/1686769507048546304?...
Certainly a non-exhaustive list, and I'm always keen to hear others' takes.
A simple example would be cellular automata (not necessarily "automata") which make clear use of space. But for this to happen, we would need new CPU design that doesn't only attempt to become a C interpreter.
I am sure when I scroll down there will be people being upvoted for such profound insights as 'readability is good'. checks yep.
I especially agree with the idea around "code locality". I find the easiest code to deal with are those that doesn't require me to understand how everything works, to understand how one thing work.
It's only infinite if you scroll for infinitely long time.
I think the author's point was about how much code you have on the screen at any given instant. Without having to scroll or jump.
Great! Now I have to travel through 100 small classes spread across 1000 files in a 10000 nodes directory tree in order to understand 1 high level class. Great readability improvement!
> if you have a class that solves a difficult problem with, say, only 2 methods with no more than 3 arguments each, you’re in good shape
Keep your APIs small, but poweful. This is the opposite of short function people which keep their APIs huge, but weak.
Also if you can keep that much context in your head when reading code that's great for you -- most people can't.
You'll see down below a case for inlining functions that are only used once, and the quote "As for one liners that are called only once, just inline them. The small functions guy can take a hike."
Nowhere does he say that you should have 100 small classes across 1000 files. He says the opposite: your modules should have a lot of functionality but a small interface.
Perhaps I am too used to having to scroll, and never had the joy of not needing to at all, but this is the weirdest part of the article to me.
Unfortunately auto-formatting is a better for other reasons so we don't have much wiggle room here but left alone I adopt the authors style
Not always.
I'm a developer that likes a lot of whitespace. My style is exactly the one the author hates.
I struggle with full walls of text. As in, my brain just simply cannot handle whitespace-free, or nearly whitespace-free, code.
Whitespace makes it easier for me to read, exactly the opposite of the author.
And that's okay. But it's certainly not an impediment of knowledge transfer to my brain.
We really shouldn't ever have to think about where to put things.
Each function should be stored in its own text file.
Then these files are indexed in a database.
Then they can be tagged: manually or by parsing its AST / types.
Then using the tags you can organize the code any way you want.
Better yet, maintain a dependency graph to see all callers and callees, and view code like that.
Even better yet, instrument your code, and at runtime let the stack trace determine the organization of your code in your editor.
Some problems I can see though is that humans seem to like things to belong in one place. That's why folders win over tags usually. But...your existing folder/file structure of code is simply one "view" from the database. Some people use module names, some people use file types (components, helpers, etc.)
Existing IDE's and text editors (and runtimes) are holding us back!
Prior art: SmallTalk Browser, Intentional Programming, Literal Programming.
It's so much easier to just see a directory structure which reflects the module structure of your project and be able to quickly open any file in any tool and not just in the IDE of your chosen programming language.
You describe solutions for specific problems a programmer has from time to time (and some implementations that aren't relevant to anything), but we don't think like that. Not about programming, nor about writing prose or conducting experiments. We don't need arbitrary flexibility, but support that matches our cognitive make-up. Many memorization techniques rely on location, probably because we're hard-wired for that. So folder structures probably work better than tags.
We forget tags. I've seen it happen. Our system supports tags in certain contexts, and now the same tag is there in multiple variations, just because people couldn't remember it was there or what is was called, and there is only a handful of them. Now imagine a system that has tens of thousands of tags...
IDE's aren't allowing us to use our full potential, but the path towards that is not logical and straightforward.
Works for me with email, too.
Mutually-exclusive folders for-the-lose. Wellll…for my usage, anyway.