Bystroushaak's blog / English section / My Greenspun's counter

My Greenspun's counter

Every time I find Greenspun's tenth rule in the wild, I add a link to the project and update a counter. This node is not a comprehensive database, just a personal notes.

Counter: 5

Wtf is Greenspun's tenth rule?

Greenspun's tenth rule states:

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

The rule notes the tendency of people to build shitty Domain Specific Languages (DSLs) out of stuff, that's just not meant for that.

For example, someone uses some configurations format, and then thinks - oh, what if I added simple conditions? So he adds conditions to the configuration format. And then functions, for loops, macro processor, variable expansion, and before he knows it, new language is born.

But the language was never meant to be a language. It doesn't have a debugger, profiler, its performance is bad, error messages cryptic, and there is no support in existing tooling, like editors and IDEs. Syntax is usually something horrible, because it is a configuration language, not a programming language.

Today, there are dozens of embeddable scripting languages. Scheme and other lisp are embeddable. Python is embeddable. Lua is embeddable. JavaScript is embeddable. Almost every scripting language is embeddable. Yet people still create their own Frankenstein domain specific languages, usually because they just organically grow from the initial simple requirements for a configuration languages.

People have this weird tendency to even protect[1][2] their abominations, usually because they think that they are easy to learn.

I don't see anyone else mentioning that the selling point of using YAML in Ansible is "human readable."

I see no practical benefit to requiring devops people to use one scripting language over another, when there are so many equivalent choices to accomplish the same tasks.

They usually don't realize, that the serialization format may be indeed readable, but the underlying structure is just random, ad hoc shitty programming language organically grown without any reasoning behind it.

The thing is you don’t really write syntax in yaml. On the surface you kinda do.

You use yaml to write code to some hidden programming language that doesn’t have any kind of formalized syntax.

Want to add a value to a parameter in your function call? Since there is no specification your IDE can’t help you look up parameter or function names.

Want to do a for-loop? Maybe some functions will support looping and other won’t, because looping is just a - loop-while: “a = b” (or maybe it is double equal signs, who knows, because there is no actual IDE support.

Examples of the Greenspun's rule in the wild

JSON schema

OpenShift Templates

No if conditions yet, but you have a templating system which can be used to write conditions.


PlantUML is a markup language, that is compiled into UML images.

Variable declarations, conditions, functions.

Redhat's Spec files

Spec files are a metadata declaration files for a .rpm packages used in RHEL / CentOs linux distributions. They are evaluated at the time user is creating, installing or uninstalling the package.


Conditions, loops and functions built on top of YAML. Everything of course with weird names and weird corner cases.


philosophy, programming, quest_for_structure

Become a Patron