10th Rule of Programming (2003) | Hacker News Reader

10th Rule of Programming (2003)

philip.greenspun.com

70 pointsgggggs22 comments

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.

I once worked on a project with someone who wrote Lisp in the style of Occam!

Edit: I later converted his work into Lisp that wrote C++, which in retrospect was perhaps a bit unnecessary.

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.

https://en.wikipedia.org/wiki/Occam_(programming_language)

https://en.wikipedia.org/wiki/Communicating_sequential_proce...

Edit: Occam is probably closer to Go than Lisp.

Java is working in different constraints.

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.

Worth noting Robert Morris's addendum: "Including Common Lisp".

I have always wondered about this rule.

It is tautologicallly true; if no such C or Fortran programs exist, the law stands true with a level of complexity above anything written.

But otherwise... how does it hold true? Via some ad hoc string/config parsing logic?

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.

Reminds me of Ansible. YAML is quite certainly the worst dialect of Lisp I ever encountered...

YAML even has the worst form of macros I've even encountered in the form of go templates.

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.

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."

Nice!

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.

Then you need some tool to coordinate and apply the data driven configuration such as Terraform or CloudFormation or you use DHALL or Cue.

This blog post talks about what happens with configuration evolving into a DSL and then a rule engine.

https://mikehadlow.blogspot.com/2012/05/configuration-comple...

See configuration of Istio, service mesh, Traefik.

And Kubernetes.

Every system eventually becomes Kubernetes. (Ansible, CMake)

The system to tell the computer how to do the work is more complicated than the work itself.

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.)

- - - -

Just use Lisp.

(That's my new slogan.)

I think you're missing step 0):

0) Completely misunderstand the tool you can't use and you're about to re-write, such that you hate it, it sucks, and you can do better...

And see GNU Guix, whose configuration is written in Guile Scheme, as a positive example:

https://guix.gnu.org/en/manual/en/html_node/Defining-Package...

"...Sorry, but there aren't 9 preeding laws. I was just trying to give the rule a memorable name."

It clearly worked! Admirable honesty and humbleness in the answer.

why in that era was it common lisp, or common business oriented language?

Were there uncommon languages? Was is a naming hack to make it more accepted, maybe like basic was used when naming visual basic?

or was it something like "common" as in common denominator?

Reply on news.ycombinator.com