Jeremy’s notes on fastai coding style | Hacker News Reader

Jeremy’s notes on fastai coding style

docs.fast.ai

36 pointscolinprince8 comments

As usual, this will provoke the disagreement between the Iverson “notation is a tool for thought” camp (of which Jeremy and myself are members), and the opposing “code should always be easy to browse for the uninitiated” camp - at least, that’s how I understand that side.

Somewhat related - Stevan Apter’s remarks about style for K programming (circa 1995 - K1, I think).

http://nsl.com/papers/style.pdf

As someone you'd probably put into the latter camp, I find your thought really interesting; is notation actually a tool for thought? It's definitely a tool for communication, and it does so in an efficient manner for the initiated, but thought? I don't know many researchers who use notation exclusively (or much at all) in their thought and ideation processes, even if their final papers are full of it.

Regardless of that I think the problem with these guidelines is they just don't produce very readable code, even if I am initiated. The lack of an autoformatter also means that I have to adapt to a different contributor's code style every time I open a file. Why devote mental energy to interpreting yet another style instead of devoting it to parsing the actual content? Again this kind of circles back to the notation problem.

The concept of “notation as a tool for thought” originated with Iverson (father of APL and J, among other things), and I highly recommend reading his writings (all available in the jsoftware web site ang through google).

The main feature that terse code provides is that it lets you use your eyes and brain hardware for pattern matching. The magic of that is sometimes hard to believe if you haven’t experienced it, but for some of us it has become indispensable.

The right notation makes things evident. Compare e.g. Leibniz derivative notation (dy/dx) to Newton notation (y’); The former extends to partial differentials, whole differentials, divergences etc and often (but not always) hints at possible solutions and reductions - where as Newton’s notation requires that you remember (or continuously look up) everything.

While “sz” as short for “size” is not such a huge difference, it does let you fit more on screen and thus visually pattern match. It’s the logical extension of writing “x” instead of “horizontal_coordinate” and “i” for “enumeration_index”.

Similarly, the right indentation (lining up related items) exposes a lot of semantics in an easy-to-grasp and visually-grok way, that autoformatters ruin (those I’ve used anyway).

Your code might not benefit from this, e.g. if you do crud stuff. But I do mathy and video processing stuff and it makes a huge difference for me and my collaborators.

There is an underlying assumption that the people who actually write the code/notation actually know what they are doing and how to communicate that well - which is entirely non trivial - but I’m privileged enough to have that environment.

Apologies for typos, am on phone.

EDIT: Iversion's "Notation as a tool of thought" https://www.jsoftware.com/papers/tot.htm

Short identifiers, long lines, combining on one line. Seems to be oriented toward minimizing lines of code, or conversely maximizing code visible at a fixed vertical screen/window size. Is there a reason this is particularly useful or important for this kind of code, or is it more idiosyncratic than that?

This is an example of what is making ML so hard for uninitiated.

160 characters per line, avoidance of using spaces, abbreviations everywhere which are not explained anywhere, lack of autoformatter.

This looks like a recipe for write-only code for me.

My pet theory is that people which invent such styles are actually not a apt touchtypers, so they avoid typing many characters because it's kind of pain for them.

I love FastAI videos. I learned DL/ML thanks to their courses. But yes, sometimes in their videos, when Jeremy was showing FastAI code or a bunch of lines in a Jupyter Notebook, all these one-liners were hard to understand.

You are already trying to learn a field that you know nothing about and you have to try to understand at the same the code which is written in a "weird" way. Every time I opened their notebooks, I automatically reformatted their code.

If the abbreviations are standard across the domain space, they are fine imho. But as far as I remember from Jeremy's videos, that was indeed not the case.

I can agree if there are not so many abbreviations, but when almost every single line is full of them, that is what makes code incomprehensible.

Reply on news.ycombinator.com