Hacker News Reader

Comment by daniel-levin | Hacker News Reader

Greenspun's Tenth Law [0] is a humorous aphorism that applies here.

>> Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

[0] http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming

View on HN

What would be some recent examples of this. (In the spirit of generosity I will accept a substitution of c++ for c and a reasonably-fortranish language for fortran).

glib offers much of what Common Lisp offers as part of the language (and more, of course).

I'm not horribly familiar with glib, could you expand?

glib[1] is a library for C which provides things like portable file I/O (in Common Lisp); error reporting (in CL); hook functions (part of CL); a reader (in CL); a lists, sequences, strings & hash tables (in CL) and so forth. Common Lisp mostly has a fuller implementation of all of these.

It also has some things CL doesn't provide as part of the language: threading primitives; URL-handling; advanced calendrical calculations; basic crypto and so forth.

[1] https://developer.gnome.org/glib/

Hm, I don't think you can say that an optional, third party library is a "part of a language". Each language has a some standard library, which can be considered "part of a language", but other libraries shouldn't be. This way you could say that all npm, pypi and gem packages are part of the relevant languages.

Other than this, however, it's a good example.

Scala the language ;). Or every time someone reinvents "programming in XML" (and yes, so-called "behavioral trees" in game development, at least in their basic form, also count).

How is scala a large c-ish or fortran-ish project?

Greenspun's Tenth Rule is a joke (there aren't even any other rules numbered 1-9). It's not meant to be taken literally.

The point is that low-level languages like C and Fortran (and today, Java) are underpowered, and any sufficiently large project will evolve to the point where someone builds a (often vaguely Lisp-like) scripting language on top of it to allow developers to raise the level of abstraction, maybe without even realizing that's what they're doing.

I have seen this in action, a lot of companies build internal, proprietary scripting languages on top of their low-level programs. They may start out as configuration files, a build system, preprocessor macros, or a DSL, but over time as features get added they accidentally become Turing-complete, and eventually someone writes an interpreter and now you've invented something that serves the same purpose as Lisp, only worse.

More here: https://sites.google.com/site/steveyegge2/the-emacs-problem

> will evolve to the point where someone builds a (often vaguely Lisp-like) scripting language

No, that's not what it is about. It's not about programs needing a scripting language.

It's about the program (its framework, libraries, architecture, ...) itself. It will acquire features like:

  * late binding
  * symbols
  * dynamic data structures
  * serialization format
  * a plugin architecture with loading of code
  * advanced error handling
  * first class function objects
  * automatic memory management
  * specialized numeric datatypes (large integers, ...)
  * a dynamic object system
  * more...

The implementation language will be extended by some framework, software layers, libraries with such features ... so that over time it will implement many of the standard features of Common Lisp

Note that platforms like the JVM, .net and others nowadays provide many of that (and much more). Also language on top of those do: Java/Scala/... See for example how for Java dynamic loading of code has been implemented on top of custom class loaders.

The yolo PHP framework deliberately invokes this rule:

http://yolophp.computer/

Reply on news.ycombinator.com