3 ms·
See also https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule "Any sufficiently complicated C or F
by jeffrallen 2y ago
See also https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
- anonzzzies 2y agoYes, that’s what I think off when I see ansible, not that it actually is a lisp. It’s a poor hack for something you can trivially do with lisp since forever. Like most of these things and indeed Greenspuns rule says we will find that; you need the solution for something complicated so you start building something simple, add more features and end up with something you should’ve done in lisp from the start. And of course now you miss most (all) of the benefits.
- sunshine-o 2y agoBlame the poor computer science education of most people nowadays (could be self-taught or university). Discovering that code is data and data is code is discovering the moon. And inferring that your sad configuration management system based on an ugly data language is kind of related to Lisp must be mind blowing. Also bonus fact, XML is a lisp too ! Actually maybe we could have written ansible in lisp directly to save us the trouble.
- saghm 2y agoThis quote has always seemed very strange to me. I feel like the implicit argument (that just using lisp instead of making a program that has more limited semantics that conform directly to the intended purpose) is not a great one. Obviously informally-specified, bug-ridden, and slow are not good things, but I'd argue those are also not specific to Fortran or C but just to any "sufficiently complicated program". People make a big deal about the Church-Turing thesis, but I think it gets taken too far sometimes because the important part of a programming language isn't always what's possible to do in the language but what _isn't_, and I'd argue most of the large improvements in languages over time are about that; not having undefined behavior, null-pointer errors, and runtime type errors are all huge improvements in programming productivity that only exist because we made languages that don't allow you to do certain things. At the end of the day, quite a lot of the work in programming boils down to ensuring that what you wrote does _exactly_ what you intend rather than behaving in some other way, and that means identifying and eliminating places where it diverges. There are a lot of common patterns for places where these issues occur, and a language that can identify those patterns and make it impossible for you to write a program that has those mistakes is saving you time up front.
- aitchnyu 2y agoWhich are the dramatic examples of lead devs looking at a system, decided half baked configs/guis will start falling apart in a few years, so they moved to a powerful programming language? Blender and Maya getting Python scripting may be one.
- SomeoneFromCA 2y agoYet another catchphrase made by someone who lived through Lisp's heyday. There is not much "magic" in Common Lisp, aside from homoiconicity; it is dated old language, which reeks the smell of 1970s and 1980s in every corner of it. Yes it still fun to play with even today, but it is not some magic unicorn everything evolves into eventually.
- jeffrallen 2y agoI agree that common lisp has "avocado tile in the kitchen" vibes. But Clojure is all stainless steel and engineered stone. So maybe if philg updated his aphorism to mention Clojure it would still fly.