3 ms·

Yeah absolutely. My personal measure for a the "cohesion-prowess" of a society is how much they screw around with plain text, opaque binary data, etc. vs take t

Yeah absolutely. My personal measure for a the "cohesion-prowess" of a society is how much they screw around with plain text, opaque binary data, etc. vs take the time to properly create rich data structures for interfaces. Taking the time and deep breath to write nice interfaces rather than scrambling and putting all the effort into implementations ignoring the larger picture of how human endeavors compose seems very fundamental. It reminds me also of the slogan > A developed country is not a place where the poor have cars. It's where the rich use public transportation.

jolux 5y ago
> > A developed country is not a place where the poor have cars. It's where the rich use public transportation This is brilliant, stealing it for my transit advocacy.
- Ericson2314 5y ago
  It is! Credit to https://en.wikipedia.org/wiki/Gustavo_Petro https://en.wikipedia.org/wiki/Gustavo_Petro
mananaysiempre 5y ago
I’m not sure it’s quite as clear-cut, for three reasons: - Text (or binary) streams are the ultimate unnormalized representation, and you don’t always want your data to be normalized. When storing it, maybe (though I’m sure the DBAs among us will disagree even on this point), but the intermediate values during processing, almost certainly not. - Most representations of structured values are all or nothing, whereas in reality most types of structured data are usually more conveniently viewed as having a hierarchy of supertypes, possibly with things like “chunk of text” on the top, maybe “list of chunks of text” below that, and so on; otherwise your tools are much less reusable. (Compare “generic programming” in the Haskell/Scala not Java/C# sense, i.e. metaprogramming over algebraic datatypes not parametric polymorphism. See also the “nanopass” approach to compilers.) These two (largely overlapping) points are how I explain to myself the (empirically if not theoretically evident) advantage of Unix’s “getta byte” approach to IPC (as Cutler sarcastically put it) over the myriads of structured approaches that came before and after. By not structuring your data exchange, it doesn’t force you into a framework that’s more rigid than it needs to be. People barely understand how to make structured data amenable to processing by composable tools now, back in the 80s I don’t think anybody even knew to ask the question. 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. Finally, in this specific case, - We’re talking about programming languages, about making a computer understand the programmer’s intent to some degree. This is a maze where making even the slightest wrong turn has Gödel and Turing together slapping you across the face with a giant NOPE sign. 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. But we are hardly smarter than them, so we should probably remember the bitter lessons they’ve been forced to learn and keep in mind the possibility that there might not be a good solution to our problem.
- Ericson2314 5y ago
  > 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.

jolux 5y ago

> > A developed country is not a place where the poor have cars. It's where the rich use public transportation This is brilliant, stealing it for my transit advocacy.

Ericson2314 5y ago
It is! Credit to https://en.wikipedia.org/wiki/Gustavo_Petro https://en.wikipedia.org/wiki/Gustavo_Petro

mananaysiempre 5y ago

I’m not sure it’s quite as clear-cut, for three reasons: - Text (or binary) streams are the ultimate unnormalized representation, and you don’t always want your data to be normalized. When storing it, maybe (though I’m sure the DBAs among us will disagree even on this point), but the intermediate values during processing, almost certainly not. - Most representations of structured values are all or nothing, whereas in reality most types of structured data are usually more conveniently viewed as having a hierarchy of supertypes, possibly with things like “chunk of text” on the top, maybe “list of chunks of text” below that, and so on; otherwise your tools are much less reusable. (Compare “generic programming” in the Haskell/Scala not Java/C# sense, i.e. metaprogramming over algebraic datatypes not parametric polymorphism. See also the “nanopass” approach to compilers.) These two (largely overlapping) points are how I explain to myself the (empirically if not theoretically evident) advantage of Unix’s “getta byte” approach to IPC (as Cutler sarcastically put it) over the myriads of structured approaches that came before and after. By not structuring your data exchange, it doesn’t force you into a framework that’s more rigid than it needs to be. People barely understand how to make structured data amenable to processing by composable tools now, back in the 80s I don’t think anybody even knew to ask the question. 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. Finally, in this specific case, - We’re talking about programming languages, about making a computer understand the programmer’s intent to some degree. This is a maze where making even the slightest wrong turn has Gödel and Turing together slapping you across the face with a giant NOPE sign. 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. But we are hardly smarter than them, so we should probably remember the bitter lessons they’ve been forced to learn and keep in mind the possibility that there might not be a good solution to our problem.

Ericson2314 5y ago
> 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.