Hacker News Reader

Comment by netizen-936824 | Hacker News Reader

Theoretically, we could do the same with comments no? Make the code extremely compact and explain it, perhaps even in a format like literate programming?

View on HN

I think this is an interesting and promising idea. Code that doesn't exist can't have bugs, and when you're just fooling around rather than writing production code you can just write the formulas without the explanation.

To some extent the Scheme and Haskell communities do this already, because their favored languages are compact enough to allow them to include their programs in more or less conventional math papers.

http://canonical.org/~kragen/sw/dev3/paperalgo is a notation I developed for writing procedural programs with paper and pencil, extending mathematical notation with lightweight notation for classes, methods/functions, assignment, iteration, conditionals, and pattern matching. For many years I have used it whenever I'm writing code on paper or a whiteboard, but still find it harder to read than more traditional notations like Python and Scheme.

In addition to compact code and explanation, it's often useful to have example inputs and outputs (the way spreadsheets and Jupyter notebooks or R notebooks do), as well as proofs.

Yes. But it would be tough to change the culture. Math papers are meant to be read, so people pay attention to the explanations. Computer programs (at least if they garner users!) are run much more often than read, so it's natural to focus on the code and neglect the comments.

> But it would be tough to change the culture.

I think it would be tougher to find anyone willing to read programs written like this. Requiring an explanation to understand the variables is very similar to encoding the variables names and putting a lookup table below. Why force someones eyes to dart back and forth between the program and lookup table, just to get an idea of what the variable are, rather than also including a very rough explanation of what they variables are doing, in the program itself, by giving them meaningful names?

We only have so much working memory. Giving variables names frees up a significant amount.

I've personally written code that was immensely difficult to read. Branchless stuff with single letter variables. Even though I commented it thoroughly, its ridiculously difficult to read and modify.

This was a good lesson for me, I won't do that again and I'm far more verbose now.

My thinking is that maybe math should learn from things like that as well, perhaps expanding equations and being more verbose within the equation instead of an explanation next to it would make maths more accessible to a broader audience.

After developing equations through 100 lines and few pages or blackboards, you’ll see that dropping letters is inevitable.

You shouldn’t really read the equations before understanding what they are about.

They are usually written down to get rid of ambiguities of the natural language.

Source code isn't ambiguous either, and tends to get way longer than a hundred lines or a few pages.

It’s not a single equation though where you’d need to rewrite the same variables 100 times.

I guess it depends on how concrete the code is. For very general things there just are no good names. I see the point in calling a variable anualSalary, say, but in a function for reversing a list is elementOfList really better than element or than x (which would be my preference)?

This, by the way, is probably the main reason math uses single letters for names (with some rules of thumb that hint at the type, like n for an integer, X for a scheme, calligraphic F for a sheaf, etc.).

Another perspective: Working memory for equations becomes tricky once they span lots of lines or multiple pages and long variable names make this worse.

Same reason one often sees I1 + I2+I3+I4 in estimates. For the moment you actively don't want the mental overload of all the details. You just want to know that there are four terms to be discussed, now forget about all others and let us start looking at the first one.

Similarly long notation/names just do not work well on blackboards/whiteboards.

The problem is that code comments tend to skew from the actual code over time. Let's just stick with readable code everywhere.

I believe this is basically what programming with APL looks like.

Exactly. Just without the comments.

Reply on news.ycombinator.com