"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.. 🤔
This entry was edited (11 months ago)
Devine Lu Linvega
in reply to Devine Lu Linvega • • •Tuxedo Wa-Kamen
in reply to Devine Lu Linvega • • •Maybe "smaller" isn't intended to mean "less characters" but "less complexity/structure" in this context.
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.
Are we allowed to have a library of common functions?
Does every function we use count against the "size" metric?
retroprom
in reply to Devine Lu Linvega • • •Doug Orleans
in reply to Devine Lu Linvega • • •Succinctness is Power
www.paulgraham.comJason
in reply to Devine Lu Linvega • • •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.
Devine Lu Linvega
Unknown parent • • •TröglödĂżt
in reply to Devine Lu Linvega • • •that's a very weird view of elegance
this person must be horrible to watch a ballet or opera with
mcc
in reply to Devine Lu Linvega • • •mcc
in reply to mcc • • •A related problem, maybe more directly relevant to your post:
Kolmogorov complexity / k-information is relative to a particular "programming language". You pick a language to express your turing machines in and for each basis language you'll get particular programs for particular output streams and so the k-complexity number for each output stream will be a little different… this is elementary, this by itself is a "standard" observation—
mcc
in reply to mcc • • •When we talk about *runtime complexity*. O(n^2) and all that. There are theorems that it doesn't matter what "programming language" you pick, that all deterministic formulations of the turing machine produce exactly the same asymptotic runtimes (up to a polynomial factor for translation)…
*Has anyone ever tried to prove the same thing for k-complexity?* That is, do all "programming languages"/TM formulations produce equivalent/related program-lengths? How different can they be?
Devine Lu Linvega
in reply to mcc • • •mcc
in reply to Devine Lu Linvega • • •Devine Lu Linvega
Unknown parent • • •418 I'm a Teapot
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to 418 I'm a Teapot • • •acb
in reply to Devine Lu Linvega • • •WimⓂ️
in reply to Devine Lu Linvega • • •Adrian Cochrane
in reply to WimⓂ️ • • •Usually I find disagreements over the concept of "elegance" comes down to disagreements over goals.
Defining it in terms of outputs helps get around that to have a definition that is more objective, but still: You might simpler software with different outputs.
Devine Lu Linvega
Unknown parent • •Devine Lu Linvega
Unknown parent • • •Devine Lu Linvega
Unknown parent • •Capital
in reply to Devine Lu Linvega • • •:: 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.
Devine Lu Linvega
in reply to Capital • • •Tagomago
in reply to Devine Lu Linvega • • •Jason
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Jason • • •Jason
in reply to Devine Lu Linvega • • •WimⓂ️
Unknown parent • • •418 I'm a Teapot
Unknown parent • • •@wim_v12e aha. i agree. i guess chaitin explicitly excludes that, basically saying: programs are meant to be run, not read (by humans).
@neauoire
Devine Lu Linvega
in reply to WimⓂ️ • • •Tuxedo Wa-Kamen
in reply to Devine Lu Linvega • • •Lisp machine
Jencel Panic
in reply to Devine Lu Linvega • • •"Kolmogorov complexity of an object, such as a piece of text, is the length of a shortest computer program (in a predetermined programming language) that produces the object as output."
Romain Delamare
in reply to Devine Lu Linvega • • •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.
Comparing Performance: Loops vs. Iterators - The Rust Programming Language
doc.rust-lang.orgRob Landley
in reply to Devine Lu Linvega • • •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...)
The design of toybox
landley.net