> and you don’t always want your data to be normalized. I think "normalized" is doing a lot of work in this sentence. In the context of data keeping, normaliza

> and you don’t always want your data to be normalized. I think "normalized" is doing a lot of work in this sentence. In the context of data keeping, normalization usually doesn't mean something like "like give a unit vector", where they both have value and the normalization is lossy, but rather cleanups of messy stuff that ought not to occurred in the first place. What I am saying is not the original input has no value, but we should take the steps to make those problems actually not happen in the first place. Rich interfaces do that, and are an investment that pays for itself eventually so this isn't manifestly unreasonable. > ...metaprogramming over algebraic datatypes not parametric polymorphism... I worked on a little toy "tree editor" where we did just that. The use of a good type system to both operate "generically" without "upcasting" and loosing the structure for ever is key. > See also the “nanopass” approach to compilers. I do like that a lot :) but I also like that there is an IR for every pass, like with CakeML. I thought those went hand in hand? > (empirically if not theoretically evident) advantage of Unix’s “getta byte” approach to IPC I would argue the (over-)prevelance of HTTP is effectively empirically the opposite, namely that people do prefer structured things in a vacuum, but coordination failures have repeated gotten us stuck in local maxima of already widely established things like Unix's various binary streams and then HTTP. > This is why I mentioned Paredit and Dylan’s “skeleton syntax trees”: they are, respectively, a structural editor and a macro system that work where others fail by the virtue of being expressed in terms of more than text or even tokens, but less than a full syntax tree. I do agree the jump from text to sexprs / json / token trees (Rust's name) etc. is the most important step. Fist get rid of flatness, then worry about higher invariants. > We’re talking about programming languages, about making a computer understand the programmer’s intent to some degree. And surely text doesn't help with that. Too much structure makes some edits hard if the user can't temporarily mid-edit ignore the rules, but computer should love it. > It’s kind of endearing to see the luminaries on the Algol committee (essentially all of CS at the time) state that they want, like, pseudocode, from their papers, except, y’know, with a compiler, and not suspect anything can go wrong with that. This is about Algol 1968 not Algol 1960? My understanding was that was too many features, not too many invariants.