I just completed "Rain Risk" - Day 12 - Advent of Code 2020 https://t.co/0wRPluJVeL #AdventOfCode

Today I learned that I really need coffee ☕️ to operate properly. Made a trivial mistake and it took me forever to catch it. This would have been obv. with a statically typed lang.

Also, I'm using a notebook-style env. to play (like https://t.co/JgFUNSSRuD, here it's https://t.co/XrswSxjjwk). My take away from this fun experience + observations at work is that such notebooks are poison to the mind, fostering bad practices while not bringing much value.

I get that notebooks provide a nice environment for tutorials - you get a literate programming + a printf-debugger on steroids, which is very useful when suffering through tensor shape mismatch errors. It's useful for data science or ML 101.

But then I see people using Python notebooks to do actual work and it's horrifying to me. The natural tendency is to write notebooks as a series of cells mutating global state. So each cell has an implicit API defined by its interaction with the global state. 2/9

The API is implicitly a function of cell exec order, but then you can purposely (or mistakenly) exec cells in any order 😬. And this is on top of the usual issues you get with dynamically typed languages. No one can write maintainable code this way, but notebooks get a pass. 3/9