One correction. Her surname is Elbakyan.

Install nix? Already done. What's the second step?

Exactly that is mentioned in the article.

To be fair, the article mentions reading via which elements are 'full', and I mention by the 'crease point'.

When I started parachuting, I struggled to quickly read windsocks, because the definition of 'full' can be somewhat ambiguous (Is it mostly / somewhat / completely inflated, what if it's full now but wasn't three seconds ago..)

I'd found: See where it 'breaks' provided a much better point of reference.

Perhaps this will help others that shared my confusion :)

Caspian sea monster had a static ceiling around 3000m. Just enough for a rebase to Mediterranean Sea.

That's a quite unobvious consequence of the software progress. Making software be "a bunch of bricks for creating applications" do come with costs. And the main cost is performance.

Thank you, Niek, for sharing that story. Such cases should be maximally open and transparent for people to learn the real risks.

As I see on the demo, it evaluates the expression itself. There is a ton of possibilities to misinterpret the domain of operations involved. Moreover, how should we control the details to which it should unwind the undergoing calculations?

That way of work seems a bit too optimistic to me.

Jupyter, and ultimately Python, evaluates the expressions. handcalcs just displays the resulting information with variable values from the Python locals dict.

Fair point. It also provides the %%tex magic that gets you the source LaTeX snippet. May save you 80% of the effort, the rest you can tweak manually.

Oh, having full ipython during debug investigations is much better than using pure pdb.set_trace(). Thank you.

You might find this useful: https://github.com/gotcha/ipdb

Fun fact about fortran: its creator (John Backus) was fond of functional programming, but that was after the fortran creation.

Guessed 10/10, but that was much harder than 5 years ago.