The Mathematical Hacker (2012)

OK, so on one hand I love this point, and I'd love for it to be more broadly understood and appreciated, especially since my educational background is Mathematics and my CS has been practical, half self-taught, and frankly patchier than I'd like.

But:

> Fortran-school programmers view the computer as an advanced tool for doing mathematics.

If we're understanding "mathematics" as numerical/analytical work + engineering (maybe applied mathematics) I can see this.

But the Lisp programmer talking in terms of recursive fibonnaci definitions is doing something that can quite adequately be described as mathematics, though it's also mathematics to figure out the closed form and understand why you might or might not use it. Not sure if it's mathematics to simply know a given closed form, though it's something mathemeticians sometimes do.

And I'm more skeptical that Lisp programmers don't do all this stuff: recursive demonstrations of fibonacci numbers are usually in textbooks to teach recursion rather than present an optimal way of computing fibonacci numbers, because it's simpler than starting with dynamic programming, and you're gonna need recursion to effectively solve some problems.

Not only that but a higher level, I think that a lot of developers (Lisp included) are already reaching into the very mathematical skills of domain modeling at one level or another -- often first with a different set of tools than a mathematician might bring, but a similar kind of work. If Miller's overall point is that we all could do a better job with more of a mathematician's tools, I agree, but then again as someone who came into industry with a math undergrad's tools the utility of those might be overemphasized here.

Or maybe I just don't appreciate what I already have.

A prime idea behind using recursive techniques is that for many complex problems you do not have to know the "special case" as you can break complex problems into simpler pieces that can be solved via recursion.

Consider:

* "Writing software" means arranging symbols (bits in a machine language, UTF or ASCII characters in a high-level language) in certain permitted ways, to transform an input sequence of symbols (e.g., a stream of byte values representing user actions from a video game controller) into an output sequence of symbols (e.g., byte values representing pixel RGB colors for display on a screen).

* "Writing down math" (e.g., to prove something, or to solve a problem) means arranging symbols ('x', '2', '+', etc.) in certain permitted ways, to transform an input sequence of symbols (representing mathematical notions) into an output sequence of symbols (representing other mathematical notions). Turing, Church, Curry, Gödel, and many others realized this in the 1920's and 1930's.

That said, most self-described "software developers" are typically working to solve relatively simple problems for immediate practical application, whereas most self-described "mathematicians" are typically working to solve highly complex problems, often highly abstract in nature, without regard for practical application.

I get to use these skills every so often though. When I was designing one of our early two-level caches at $WORK, I wrote an analysis of chosen TTLs and jitter values by looking at microservice latency distributions. I've debugged a nasty concurrency issue by modeling it in TLA+ and then fixing the bug (full disclosure: once I thought through the TLA+ model, the bug was fairly obvious to me, but the modelling itself was the valuable exercise.) I've used MILP solvers for capacity planning our boxes. I've designed queue backpressure through probabilistic analysing. Each of these things has been crucial in designs I've used, but I only encounter a problem like this once every some years. (And these days I often write more docs than code.)

https://lee-phillips.org/lispmath/