pull down to refresh

Common Lisp. It is a very powerful programming language that, despite it's age, still has many features that most other programming languages don't have. The fact that so many programs still need some sort of scripting language is proof that most languages will never achieve the power of Common Lisp.
If more software, especially operating systems, were written in Common Lisp, there would be significantly less problems with computers, especially in regards to security and time spent maintaining code.
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
Ok, now I'm intrigued. Can someone ELI5? I'd dive deeper into this statement, but I need to go to work.
reply
ELI5-ing this topic is tough without also ELI5-ing a bunch of obscure parts of computer science. But I'll give it a shot anyways.
If you are writing a big program in a language like C or Fortran, it will get harder-and-harder to make changes as the program gets bigger-and-bigger. Common Lisp provides powerful ways to manage complexity in an efficient way.
C/Fortran requires you to do a lot of things manually. As the program gets bigger, a C/Fortran program requires more work from the programmer. Common Lisp automates certain kinds of programming tasks, and it provides ways for the programmer to automate many other programming tasks.
C/Fortran requires you to stop running the program entirely in order to change the program's code. Common Lisp will let you change your program's code without stopping your program.
But C/Fortran programmers will not re-write their program in Common Lisp, when their C/Fortran code becomes too complex. Instead, they will add a scripting language to their complex C/Fortran program. Such scripting languages are what Greenspun's Tenth Rule summarizes:
  • ad-hoc: Those scripting languages are intended to be used for a narrow range of tasks.
  • informally-specified: There is minimal thought put into their design before starting work on them.
  • bug-ridden: They are written in C/Fortran, so all the problems of writing complex software in C/Fortran apply to making the scripting language too. A bug in the scripting language will seem like a bug in your scripts, so the bug becomes tough to fix.
  • slow: They are always made using an interpreter, which means they are inherently slower than using a compiler (e.g. C, Fortran, and Common Lisp).
  • half of Common Lisp: Common Lisp is a large, complex language; and it was written by experts in the design of programming languages. When you are making an ad-hoc scripting language, it isn't worth it to re-create all of the features of Common Lisp. Half of Common Lisp usually feels like it is enough, but eventually you realize you need more, which requires even more complex C/Fortran code.
I don't know if that's ELI5. I can explain each part in more detail if you'd like. But I can't guarantee that those explanations will be ELI5.
reply
That was awesome. Above and beyond ELI5. Thank you.
reply
50 sats \ 1 reply \ @ek 24 Aug 2023
Mhhh, another area of computer science I didn't even touch yet.
reply
another area of computer science
That is a very apt way to describe Common Lisp. The Lisp family of languages are a true branch of computer science, because many things discovered via Lisp are only feasible to discover/learn via Lisp. As an example, consider this book:
Alan Kay called it "the best book anybody's written in ten years", and contended that it contained "some of the most profound insights, and the most practical insights about OOP", but was dismayed that it was written in a highly Lisp-centric and CLOS-specific fashion, calling it "a hard book for most people to read; if you don't know the Lisp culture, it's very hard to read".
The key bit is "Lisp culture". There are certain concepts learned by Lisp programmers that cannot be learned without learning Lisp.
One last example, consider LambdaLite, which is a database written in 250 lines:
what LambdaLite does would be impossible in most languages.
reply