lambdaxymox

F# always struck me as one of the most terribly underrated languages. I'm a lover of MLs in general, but F# lands on one of the sweet spots in PL space with ample expressive power without being prone to floating off into abstraction orbit ("pragmatic functional" is the term I believe). It is basically feature complete to boot.

I don't know about superoptimization, but JetBrains does have a HoTT-based language and proof assistant called Arend for doing mathematics in.

For sure among the hardest problems in software engineering are versioning dependencies, and managing dependencies. At least those are the two I find the most aggravating. It seems like almost nobody can get it right even though component-based software engineering, SoA, etc. I think are generally extremely good ideas. The execution is pretty crummy pretty much everywhere.

With all that said, my sense is that hardware engineering has its own heap of Sisyphean problems and complexities. I definitely would not go back to working on hardware engineering problems like I did super early in my career (a mix of embedded firmware, device drivers, PCB design, and web development). I shudder at the thought of ever working with anything Verilog/VHDL, Xilinx, or SPICE ever again, or debugging PCB designs on the bench top in the lab with an oscilloscope and a logic probe. At least in school I ran more than a few bodge wires to patch a mistake in a PCB design iteration. Maybe in some sense, it's a blessing that those linear systems theory abstractions fall apart utterly in RF engineering problems, and one has to contend with the fact that all circuits radiate. At least circuits that still contain the magic smoke.

Maybe I'm different, but I used Kleinberg/Tardos and CLRS in my undergraduate algorithms class, and I preferred CLRS to KT and the other alternatives (Algorithm Design Manual, etc.), though KT was great too. I've heard from others that KT was better for them for learning how to actually design algorithms as well.

Interesting, I must have lucked out quite often and got the first printing back in the mid to late 2000s since back then virtually all of my print Springer books I bought back then were sewn-bound.

The construction of MIR titles reminds me a lot of older Springer GTM and Grundlehren der Mathematischen Wissenschaften series titles. I have a number of Springer titles I've picked up over the years and the older printings were beautifully typeset and bound with very good paper. I try to find the older printings of Springer books when I can when chasing down a copy for my personal library.

I find coffee products to be a frustrating product category. At least for me, I have adverse reactions to certain blends of coffees--particularly nausea, coldness, and headaches--while other ones don't cause trouble at all, so I have to try different coffee blends with a bit of caution. I notice that any amount of coffee past the second cup in the morning doesn't really add anything to my alertness, productivity, or ability to pretend to be a morning person--with the bulk of the benefit being from the first cup--but anything past the second cup makes it harder to fall asleep later at night. I can only imagine how one gets so far as to put down a pot of coffee a day (and then some!) for years on end.

Jean Yves-Girard's thinking evolved from analytic philosophy to continental philosophy over the course of his life, and in this book in particular, some of his asides and polemics critique how we conceptualize truth, knowledge, and logic, and how other fields conceptualize that stuff, from a continental perspective. The fact that this kind of stuff turned up in a mathematical logic book of all places really struck me. It put me on a path to taking a more serious interest in the continental school, and reading more of it (currently chewing on Gilles Deleuze and Bruno Latour). It's a very unusual and difficult book, that led me to very different (compared to what I am used to, anyway) modes of thinking.

The Blind Spot: Lectures On Logic by Jean Yves-Girard

For context, Girard is a mathematical logician, philosopher, and co-discoverer of the type system System F (Haskell, ML, etc.). The book is a monograph on proof theory, and I was interested in learning more about affine and linear logic to deepen my understanding of Rust and other language ecosystems focused around the ability to explicitly model resources. However, along the way, I learned some other great things: (1) continental philosophy is deep and cool; (2) mathematical writing can be simultaneously rigorous, clear, and hilarious; and it reinforced (alongside Alain Connes's Noncommutative Geometry, and various French philosophers) (3) French academic writing is both frustratingly and delightfully idiosyncratic. Girard writes polemically about other aspects of knowledge, mathematics, etc., and there's heaps of dry humor and anecdotes throughout the book. It's a hard book to read even by pure mathematics standards--a topic not exactly known for being a brisk read--but it was worth it just for the side discoveries alone.

I discerned a similar ontology as the OP over the years in different hobbies too. My sense is that what quadrant one leans into can change in time and space too. In my case, I've had a whole heap of nerd hobbies in my life, among them being game collecting and retrogaming.

I was a game collector even when I was a child back in the heyday of console generations 4 and 5 all the way into my mid twenties, and also a game player since then up to the present as well. When I was much younger I used to love collecting original hardware and media complete in box and everything, and I kept everything I got when it was new in absolutely pristine condition (I was a very atypical child) but as I got older I grew tired of the collecting aspect of video games and sold everything off. At some point it dawned on me I was just buying stuff and putting it in a box (falling into the kit quadrant) and not really playing the games at all. After realizing all that, and when I had acquired everything I wanted (I tended to collect a mix of only games I liked + genre instead of by system, so my collecting requirements were much smaller and easier to achieve), the fun was over and I cashed out some years later. With retrogaming I now vastly prefer a Raspberry Pi and a gamepad in the living room. Fortunately I was able to get in and get out of the game collecting hobby when it was a fairly cheap hobby to participate in (i.e. when CIB copies of classic games were like tens of dollars at most).

I was also an avid tabletop gamer who was into the playing and collecting aspect of Magic: The Gathering and other TCGs, particularly Legend of the Five Rings, Vampire: The Eternal Struggle, and VS System. I started playing MTG way back in the ancient days and had a particular taste for vintage. I also played standard, booster draft, legacy, and extended, but vintage was always my favorite. Back then vintage was accessible on a high school budget with planning and dedication, and wasn't the rich man's game it now, at least if one is not using proxies. For a long time I was both into the competitive side of the game, as well as the collecting side of the game. Over time I grew tired of the playing aspect of Magic: The Gathering and vastly preferred the collecting aspect of it, before life priorities changed entirely and I lost interest in TCGs completely.

I don't really do the collecting/kit hounding side of any hobbies anymore, I prefer the actual doing of the thing instead, but I am grateful I was able to get in, enjoy it fully, and get out of the collecting aspect of both video games and MTG long before both became impossibly expensive to participate in, though it is fun to dip in and see what is going on with those things from time to time.

Not stated in the article, but I suspect that another big reason a lot of hobbyists obsess over the gear and kit aspect of a hobby is because buying kit is a substitute for not having time or energy to actually do the hobby itself. In some sense, buying kit is materializing fantasies about actually doing the thing, but not having the time or the place to do it.

Type inference occasionally bites one's hand when pushing data across an FFI boundary. In one instance I was writing some graphics code for a project and for some reason the colors in the rendering model were coming out all wrong on the screen (TL;DR it ended up looking like two of the color channels were missing from some texture maps) and it turns out that Rust inferred the type of the buffer as a vector of f64s instead of a vector of f32s. Putting the type in specifically fixed the problem promptly.

Lesson learned: Sometimes type inference fails, and always annotate your types at FFI boundaries!

I know two people who worked through SICP. One of them had so much fun with it they worked through it twice cover to cover in their free time. In both cases they reported to me that SICP was quite a revelation to them, since Scheme is about as simple a practical programming language as one can get other than maybe stack languages like Forth. That is, while [un-|simply-]typed lambda calculus and Turing machines are simpler models of computation, I wouldn't exactly call them practical models of computation. In one case they said that it really gave them real purchase on what computation really means. That is, what is it really about when one strips off all the type theory, build tools, and dependency hell. My sense is that SICP is better left to after getting a couple years of experience doing computer programming to appreciate though for most people though.

Are the enterprise versions of Windows 11 also filled with bloat?

I got some keys second-hand for Windows 10 Enterprise LTSC a few years ago, installed it on some ten year old hardware at the time, and I was honestly surprised how responsive Windows could be absent (to the best of my knowledge) the telemetry software, Cortana, etc., and how fast it could boot. It's almost like the true blue good Windows experience without all the nonsense is secretly reserved for only business customers and pirates.

Some problems are good problems to have. If different groups of people are taking the time to substantively and constructively complain about different shortcomings of Rust and its ecosystem, it shows that there's a wide enough audience of serious users out there. My take is that the Rust devs are doing something right, even if it seems like they can't win.

One of the great parts about linear algebra is that there is almost always a simple geometric idea underneath.

The geometric picture underneath is one of the things that keeps me in awe of the subject despite its seeming simplicity, and I keep getting something out of it every time I come back to it. It's a bummer since finite-dimensional linear algebra is one of a handful of mathematics topics where one can answer all the questions posed at the beginning of a course in it by the end of a course in it, so it is a pretty self-contained topic.

After learning e.g. exterior algebra (differential forms), Clifford algebra (geometric algebra in these parts), and so on, the geometric picture of the determinant as the size of an oriented volume makes deriving the algebraic formula super duper slick. Like in Clifford algebra, the formula can be proven in two or three lines. It's unfortunate that it seems like e.g. exterior algebra never get introduced sooner in the pedagogy of linear algebra or multivariable calculus because when used right they make the underlying ideas shine through beautifully. It's a bummer since exterior algebra is much simpler than it looks, though like many things in mathematics, it's takes a lot of work to make that simple idea rigorous. But unfortunately algebra in general given it's abstract nature can absolutely lobotomize the real deal geometric ideas underneath a lot of this stuff when used poorly.

I learned Haskell around 2010 starting with LYAH followed by Real World Haskell. I too wouldn't recommend LYAH for actually learning Haskell in $CURRENT_YEAR now that there are manifold and much better resources on the topic now, such as Haskell From First Principles. LYAH was quite hilarious and entertaining, but I think its time has passed. I don't use Haskell a whole lot these days, but to this day Haskell is still one of my Blub languages.

I think I have kept a high level of interest (passion as a word has been abused into meaninglessness) in computing as a whole, but what keeps things interesting has definitely shifted over the years. I don't have much love for the current technological state of affair. I find one has to reinvent oneself periodically to keep anything fresh. Software Engineering is a peculiar field because really every developer has two skill sets. In this way, software engineering isn't freestanding in that it is always alloyed to some other purpose as well.

(1) Computer technology and computer programming. This portion does not fundamentally change much. At the end of the day, all our code is running on some kind of Von Neumann architecture hardware, with a C-like ABI, on a 1970s paradigm Unix-like OS based on identity-based access control, that pipes and transforms, displays, and persists data. Given how fad and fashion driven computing is, the vast majority of the change isn't innovation, it's just surface-level change (Change != Innovation). There's very little real deal change in computer technology these days. Refinement yes, step change no.

(2) Domain knowledge. The great part about the second part is that whereas (1) does not fundamentally change very much, software is applicable to pretty much anything, so there is always ample room to explore interesting topics. I like to use side projects as a way of exploring new topics and finding new fields to try my hand at. Even e.g. game development with all the technological wizardry that goes into game engines and tooling is ultimately about creating compelling interactive experiences and entertainment at it's best. At it's worst it's about creating attention-thieving rent-extracting Skinner boxes.

On part (1), I think a big source of the complexity of modern software is the fact that we're trapped in a local maximum that's no longer fit for purpose. But in keeping with established things, big players in any industry--including the tech industry--hate nothing more than real innovation or invention. Couple this with massive amounts of inertia, it makes it really hard to meaningfully explore alternative software systems paradigms. It's a rotting pile of awful, but a pretty darn useful one for a lot of people, so here we are.

In particular, there is a quadfecta of ideas I am thinking of things along the lines of: (a) Capability-based operating systems. (b) Interactive software systems. Things along the lines of the LISP machines of old, Smalltalk, Self, Luna, Erlang, Elixir, and Unison. That is, the idea of software systems as living interactable artifacts. (c) Content-derived code versioning and (binary) reproducible builds. (d) Programming language designs based on linear logic, affine logic, or other kinds of separation logics (Rust, ATS, Austral, and others).

The set of four ideas above have the kernel of some very different paradigms for interacting with and creating truly robust and resilient software systems. Unfortunately the first three ideas also have a very long history of failing to gain traction going back to the 1980s. My sense is that software engineering as a field is in a gnarly state of arrested development (that makes most of us miserable at least some of the time), and the quadfecta above is a big thing that keeps me passionate about it. It's a deep well of idea to explore, and one that keeps me out of apathy over the current state of affairs in computer technology. There is a huge amount of latent potential in software engineering and computer science that feels like is just being left on the ground, even when it feels Sisyphean to bend over and pick it up for the umpteenth time.

On part (2), given the circumstances around part (1), my interests have on another axis shifted towards computers as media for creative expression. In other words, computers as a tool for doing other things. I tend to lean more digitally vegan (in the sense of Andy Farnell's 'Digital Vegan') in my daily life, so I can get to the business of using computers for creative purposes. Of course I still end up doing a lot of tinkering anyway, but that's how things go sometimes. In that sense much of what I like about computers has evolved from the technology itself, to what I can do with it or create with it instead. The beauty of the essentially universal applicability of computer technology is that one's career can always stay fresh by changing business domains. Skill set (1) is pretty stable, so one has a nice stable place to stick a foot while exploring around with skill set (2).

TL;DR it's natural for one's interests and passions to ebb, flow, and evolve. It's called being alive.

It's interesting that the black art of analog design never really goes away even from computing. I was reading Geoffrey Hinton's "Mortal Computation" where he briefly speculated towards the end on low power (in watts used, not capability) neural networks being embedded in hardware via something like memristor networks. It makes me imagine neural networks being distributed as a template (i.e. a blob of XML describing the topology and the weights) and then the network weights get tuned a little different to each device or device model to get the best performance per watt out of them. Since every device is physically a little bit different from the next, in precision analog applications with discrete components the components have to be matched. This is often the case in assembling differential pairs in analog audio circuits. Similarly with the control system parameters with hard drives. Since each DC motor is a little bit different from the next, the control loop gets tuned at the factory to each drive. So in this case, the neural network gets matched to the circuit it's embedded in. Mortal computation indeed, each neural network becomes truly unique. I could be full of it, but it's fun to imagine at least.

I had a TI-89 I got in 9th grade and had through the end of college, but I found I had the opposite experience with it. A goodly number of my engineering classmates used their TI-89s as a crutch and forgot most of the details of solving e.g. differential equations and computing integrals. In my case I found it faster to do most of the problem solving by hand, and I just used the calculator to punch in the numbers to get the final answer. I found after a while that my TI-89 just sat in my backpack doing nothing most of the time and all I needed was a scientific calculator for most things. About the only time I found it really useful was for solving for stability characteristics and tuning tedious PID loops for control systems problems. Solving characteristic polynomials for poles and zeros was just a pain in the neck.

It had a nice side effect of saving my bacon several times on final exams. On my engineering electromagnetics final I forgot to change the batteries in my TI-89 the night before and the calculator didn't work. I ended up having to re-derive a small bit of transmission line theory from scratch in order to solve the problems. I somehow managed to be one of the first people done anyway. I did have fun making arcade game clones and custom boot screens in assembly on it though.

For end user workstations, my favorite Linux distros have converged on either Pop!_OS or Arch Linux (and Manjaro).

Pop!_OS is a remarkably stable and usable Linux distro. At least from a UX and aesthetics standpoint I find it competitive with macOS (I am also a longtime mac user, though macOS has lost its edge in recent years on the UX front). Overall I would say it's my favorite Linux distro these days. I am a big fan of the Debian family of distros in general. I used Arch Linux for almost ten years before switching fully to Pop!_OS and I never had an update go pear-shaped. Rolling release with pacman is amazingly robust indeed. I would say it's my number two.

I was an Ubuntu user from version 7 to version 16. Two things did it in for me. The first one was when Canonical submarined Amazon search queries into the OS's search feature somewhere around version 12 or 13. The second problem I had was major version upgrades reliably crashed my workstations. Every single major version upgrade meant a Busybox prompt after rebooting. After a few too many of those headaches (frustrations with apt upgrades causing trouble aside), it got to the point where I'd just do a nuke and boot to upgrade major versions instead of doing it in situ. After that happened for the last time sometime around Ubuntu 16.10 I said enough and dropped it going fully over to Arch Linux until around 2020, when I switched to Pop!_OS for a change of pace. Pop!_OS major version transitions have never caused problems for me. Arch Linux obviously doesn't have a notion of versions to begin with being rolling release.

I find the term "low-level" to be an ambigious one. In my experience it partitions into two forms that I call low-level, and low-high-level. Low-level is anything directly touching the hardware, such as device drivers, OS kernels, firmware, and microcode. Low-high-level is anything just a level about that, including the lower levels of graphics programming, compiler backends, linkers, systems libraries, software runtimes, network code, and so on. I think low-high-level is an appropriate characterization in e.g. computer graphics since even using say Vulkan, one programs against an abstract model of a GPU, instead of touching the GPU directly. My mental model of the lower levels of computer graphics in that sense is that the platform APIs are different compiler backends for implementing rendering models, and the domain ontology is buffers, shader binaries, and locking primitives, with the system being built on those two or three ideas.

In either case, in low-level code and low-high-level code, the number of ideas one deals with is many fewer than in the higher levels of the stack. At the end of the day, computers are really fancy calculators, and the ontology at that level of the stack only consists of a handful of things. A consequence of it is that one reuses the same handful of ideas in myriad different ways. It's part of what makes the lower levels of the stack both fun, and monotonous at the same time for me anyway.

I cannot say whether low-level software or low-high-level software is easier than higher level code. One deals with fewer ideas, but the picky details matter a lot more. Hence why e.g. systems languages generally do not have the abstraction power that higher level languages do, but they allow you to directly manipulate data. With the higher levels, there's an explosion of ideas (far more different problem domains and business domains to consider up there) but one gets to take advantage of good abstractions and good infrastructure to help. I do find that the difficult/time spent per LOC ratio is a lot higher with low-high-level code than high-level code, but low-high-level code is also a tiny fraction of the entire ecosystem. One side benefit of experience in the low-high-level region in particular is that I have yet to run into a software system where having a sense of how that stuff works wasn't hugely beneficial. Since there are relatively few ideas that turn up everywhere in computer software, grokking them has a massive power to weight ratio for working with the higher levels of the stack, especially when debugging and stuff. At least I have yet to find time spent down there to be time wasted.