 "Let's call a program elegant if no smaller program written in the same programming language has the same output." I keep thinking back about Chaitin's Unknowable, and can't really appreciate the quote due to golfing being most often synonymous to obfuscation. But I'm also of the mind, that maybe the sort of golfing that results in obfuscation is a side-effect of the language for not being able to express meaning both concisely and explicitly at once.. 🤔 20 comments
 @neauoire That way you can still have readable variable names, even local variables to make steps more explicit. The "LISP elegance" in the text seems a bit loosely defined.  @neauoire reminds me of Paul Graham's measure of succinctness, based on AST node size rather that byte-length of the code. http://www.paulgraham.com/power.html @neauoire I have a super hard time accepting programming advice from mathematicians. I've recently tried re-implementing numpy/jax stuff in other languages and their `choice` to use single letter character names and really dense functions is pure pain. As someone who's reading their referenced paper AND their code and still not able to make the connections. Mathematicians focus on elegance has probably slowed the engineering of computers and software more than any other single cultural norm. @neauoire I think it's fine if you define "smaller" as meaning "with fewer semantics"? e.g. replacing a large variable name with a single letter has _no meaningful impact_ on even the code's tree, whereas rewriting a 100-line function as five functions across 40 lines is Not sure a good formal definition, here, but I think the idea makes sense? that's a very weird view of elegance this person must be horrible to watch a ballet or opera with  @neauoire Chaitlin's constant, chaitlin's other "unknowable" conundrums, Busy Beavers / k-information are interesting because they are *objective*, there's a specific number for each of these things and it concretely exists, but you can't ever know what it is, because it's not feasible to brute-force all possibilities… there's an ocean of possible escapes all around you and it is opaque to you  @neauoire there is a kind of theoretical elegance to it. it is kind of a paraphrase of kolmogorov's definition of complexity -- the main difference being that, for kolmogorov, it's any language. it is a measure of information content. (it is also not computable, but it can be approximated). so, I read this ias Chaintin saying that "elegant" means "containing only information, no redundancy, to the extent possible in some language". You could relax this further and insist on meaningful names. @chainik absolutely, I always have a photo of kolmogorov in my talks when complexity index arises. solomonoff narrowed AIT to string-based representation, and chaitin brings this into exploring halting/incompleteness problems, but still with solomonoff's string based approach.    @neauoire :: I feel like trying to define a grand over arching definition of "elegance" is like trying to define the mean of True Happiness. For some people the terseness of functional programming is elegant. Others find simple procedural programming to be elegance. A group of friends I'm in tend to find Factor code baffling and impenetrable. Elegant code should be what you find best express you intent. @CapitalEx there might be a component in appreciating elegance that is familiarity, or understandability or context too ;)  @neauoire Don't have context, but I think it alludes to the concept of Kolmogorov complexity: @neauoire my first reaction was to strongly disagree, mainly for the reasons you explain. But I kept thinking about it and I realized the reason I like #rustlang so much is that the most explicit way of doing something is often the most concise and has better performance (e.g., https://doc.rust-lang.org/book/ch13-04-performance.html). I still think that it's a very tricky thing to do with a general purpose language. For a DSL though, I think that's something one should strive for.  @neauoire I wrote about the tradeoffs between size, speed, features, and simplicity on the toybox design page more than 10 years ago: https://landley.net/toybox/design.html#goals Seriously, the smallest code, simplest code, and easiest to understand code are not always the same thing. You've got to sort of 80/20 all of them at once. (I learned that maintaining busybox coming up on 20 years ago now. Wow I'm old...) |
Gregory's Server
LISP seems like an awfully bad example to express what he's trying to say here, point-free tacit programming is probably able to do a better demonstration of his meaning than any language naming parameters and functions, because doing so inevitably leads to single-character names in the name of "elegance".