It shows how programmers get buried in a paradigm. When I wrote lots f functional programs, my procedural programs started to look functional - even though it didn't make a lot of sense for the language. That's how C or Fortran programs can start looking like bad Lisp.
It's the same for other paradigms. When I was writing lots of logic programs, I tended to write lots of logical functions in procedural languages, even though it didn't make a lot of sense. Lots of recursion, which tends to be really inefficient without tail-recursion optimization.
Right now, my primary language is Java. And I really, really dislike lambdas in Java, because they are a poor imitation of actual lambdas expressions in pure functional languages.
Occam and Lisp are both developed from the Lambda calculus and quite close relatives. The main difference is that Lisp is strong-dynamically typed (like Python), and Occam is statically typed (like, say, Java).
Occam was based on Hoare's CSP rather than Lambda Calculus and the relationship between your average Common Lisp program and Lambda Calculus is pretty distant.
Java shops don’t move at the pace of JavaScript shops. These developers are looking for an actual work/life balance. Not looking for shake shit up.
So Java lambdas, being little more than syntax sugar over an already existing concept in Java, works well for them. They get new sugar and don’t have to rewrite a bunch of old code for it.
Anyway. Personally, I tend to get really annoyed with developers trying to use a language outside of its paradigm. Trying to write functional C is moronic just like trying to write procedural Haskell is moronic.
The contrapositive is enlightening: "Any C or Fortran program that does not contain an ad-hoc, informally-specified bug-ridden, slow implementation of half of Common Lisp is insufficiently complicated."
Works for the famous Arthur C. Clarke quote too: "Any technology that is distinguishable from magic is insufficiently advanced."
The rule is referring to application plugins and extensions. In the early 90s, there was an antipattern in lots of large applications to evolve an extension language that was originally just a dialect of a config language of some kind. Then the developers would try to add if/else without changing the syntax of the config language, and then add functions, and before long, you have an overcomplicated yet poorly specified and slow implementation of something almost but not quite entirely unlike Lisp.
This same phenomenon is the reason why John Ousterhout wrote Tcl and the GNU project started Guile.
Think in terms of enterprise apps. Jira, say. But with enterprise stuff, you can't totally insist that the company do it your way. Too many companies have custom steps at points in their workflow. So you need the ability to do some custom process at some points in your enterprise app.
So you needed more than just a configuration file. You needed a configuration file that could contain code. That's what brings you to Lisp - the ability for a data file to contain code that could be imported and executed by a running program.
> This same phenomenon is the reason why John Ousterhout wrote Tcl and the GNU project started Guile.
Except that Guile is an implementation of Scheme, which is essentially a somewhat minimalist variant of Lisp. So in this case, a real programming language was included intentionally as configuration language.
And this is the same concept as why GNU Emacs is an editor written in Lisp on top of C routines - very similar how data science is often done in Python on top of Numpy and several other packages.
It's referring to metaprogramming. Lots of large programs end up full of DSLs and config files with bespoke parsers and code generators, which are largely inferior (in that they are bloated, bespoke and less expressive) to the metaprogramming tools available in Common Lisp.
structs de/serialization(e.g. JSON) and complex
initialization/modification routines at runtime that rely on
these structs/objects, data-oriented architecture and
internal script interpreters at some level.
Lisp itself can embedded in C, but at that point
the program likely has a more efficient scripting DSL at place.
I have, over the years, developed a theory, to wit: we keep reinventing basic system administration tools over and over again for three reasons:
1) It's fun.
2) Most programmers are naive. (This point bears expansion: most programmers have less than five years of experience and this has been true for decades because of the exponential growth of the field. I don't have the exact numbers, but the shape of IT is Eternal September.)
3) People make a lot of money from these microcosms. You can't make money selling old shell+SSH+make, so you wrap it in e.g. Python and create an "ecosystem" and then people are getting jobs and selling books and courses and even certifications if it goes that well.
(Point 3 is mostly due to point 2 (naivete) but there are certainly people who consciously and deliberately try to create new things just to get in on a hustle.)
It's the same for other paradigms. When I was writing lots of logic programs, I tended to write lots of logical functions in procedural languages, even though it didn't make a lot of sense. Lots of recursion, which tends to be really inefficient without tail-recursion optimization.
Right now, my primary language is Java. And I really, really dislike lambdas in Java, because they are a poor imitation of actual lambdas expressions in pure functional languages.