Saturday, 12/10/2022

11:34 working heuristics

A valuable heuristic for assessing what is most worth the effort should consider hours [assuming other things, like reasonable quality of life, are taken care of]. For a consumer product I should decide to pursue a line of work by considering how much time that the finished work saves others (considering all the time they spend figuring out how to use the product, etc) relative to how much time I invest; the highest ratio of `others' time` / `my time` is best worth the effort.

I think this is reasonable as it measures both usefulness and ease of use. A lot of developer tools get trapped in these claims that installing and learning and using and debugging their software 'will be worth it'; this metric rewards effort spent to reduce time to use of the product as much as possible. Reducing time to install and time to actionable product is why web apps exist as a phenomenon, and we deserve to have it for native apps and linux extensions as well.

Only accept seamless setup processes, regardless of the level of complexity accepted by the user of the software. Work should be a one-click or one-command install without leaving behind dirt to be cleaned up. This is why I believe in Nix so strongly: `nix shell`, `nix flake`, and the ability to reproducible builds of software off of a git url is a superpower.

The language is obtuse, sure - and it's incredibly difficult to get going - but end users don't need to understand Nix. They just need to know what flake commands to run to get any output of any program off the web.

11:49 names

Names are important. I love the focus of Cairo's documentation on verbage - "First I'll describe the nouns: destination, source, mask, path, and context. After that I'll describe the verbs which offer ways to manipulate the nouns and draw the graphics you wish to create." The words ostensibly have nothing to do with the end goal - but they're more important. This theme of 'speaking the language' of a discipline comes up again and again - computers are designed to help people assign names to concepts and to experiment with these concepts, a view realized by Papert, by Felleisen, by so many people who work with computers. This is not unique to computers, or computer science, or anything; mathematics is obsessed with names, as is construction work, as is architecture, as there is no better way to speak about something in an effective way than to develop a vocabulary for it.

Different computing systems let you speak in different ways and use different vocabularies. C - or (arguably) better, Zig - let you speak the language of assembly, the language of Unix, the language of the kernel, the language of the computer. You inject your vocabulary into the language - by assigning names to variables, types and functions - but you have no ability to change the language of the system.

This also holds for Lisps; you speak the language of lists, of parentheses, but you embed your domain in them; this set of lists means this, and this symbol or tag indicates that, and some function allows you to transform your inputs from this to that.

ML languages like Rust are different, deeper. Taagged unions allow you to embed your vocabulary into the type system, the error messages, the mechanics of the language. The strong type system lets you embed your language into the target, to further restrict the user of your code to speak both the programming language and the language you establish for others to use.

Which is better? To me, strong type systems and mathematics go hand-in-hand. Math is so valuable on paper because its a constructed environment for a language; different types of proofs speak different languages, sometimes graphical, always constrained, and it's vital that the user of the system speaks both the language of the prover and the language of the mathematical domain that others have constructed for this user. Learning to speak an object language is difficult, and the type system exists to give the user this linguistic superpower.

Most of programming, though, doesn't interoperate with a single system. Programming requires glueing different code together, developing higher-level abstractions, and so forth, combining different libraries to produce end results. This… doesn't bode well for ML. Not only do libraries built for ML-like languages have to speak the system language, they also have to learn to conform to all of this community parlance and all of the object languages that others have embedded in the system.

Solutions to this mostly involve assuming parts of the object language as the standard library, but community consensus is incredibly difficult regardless - some people don't like the way the Rust Error type is structured, for example, so they make their own incompatible error types, so glueing together different rust Error types is a mess.

If the language is strong and gives the power of manipulation of the code language to the user, though, the user can interact with the system differently. This is where the row types of typescript and typed racket come in - now the user can use these types but still interoperate between type names, as what really matters is the (partial) contents of the type rather than the community parlance used to name the types. Maybe it's better to be free, though - if everything is a list, or everything is an `mmapped` segment of memory, then the programmer can easily and seamlessly peel some data apart and provide it to other libraries. Though the names might not be the same, typically similar data is conducive to similar abstractions; it's not uncommon for moving data from one library to another in Common Lisp for me to be a `cadr` or a `cons` away, and picking a good name for the function to make that transformation seals the deal.

Maybe it's okay to only make programmers learn the domain language and not the object language - the rest can come.

14:15 sick

Of course the day after I preach about wanting to do more I wake up sick as hell.

A lot of exploratory work today - Zig talks, some thinking, reading documentation, and flipping through books throughout my apartment - with some photos - but the brain feels too fried to be able to really operate and get deep into coding work. Looking at a big hurts, so I put on light music or talks off of YouTube in the background. Wondering if there are any podcasts that aren't about news or fads, that feel less ephemeral - it's hard to find.

Cold things and slimy things feel the same - my hands are so extremely cold that I thought I'd spilled water on my clothes when I touched my face. Oh, moisture can condense on something! But I don't feel like there is moisture on the thing - the touch just feels similar.

Content creation? Seems valuable for learning to visualize and present information. TikTok videos are fun.

14:32 document yourself through other people

on the internet. much easier than doing it yourself.