
Jeremy’s notes on fastai coding style - colinprince
https://docs.fast.ai/dev/style.html
======
beagle3
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](http://nsl.com/papers/style.pdf)

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

~~~
beagle3
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](https://www.jsoftware.com/papers/tot.htm)

------
notacoward
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?

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

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

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

