Hacker News Reader

Comment by mhitza | Hacker News Reader

Greenspun's tenth rule seems applicable here [0]

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

I write a lot of Ansible playbooks (yaml as well), been doing that for almost 10 years and I still have to jump to the reference manual. YAML DSLs are a pain to work with. Jetbrains software might have a plugin for GitHub Actions, Ansible(, and what have you), etc but that only makes slightly bearable.

I think you might be to close to the core of the project to see that YAML without some autocomplete (intelisense) support is a though environment to work in.

[0] https://github.com/lowdefy/lowdefy-example-case-management/b...

View on HN

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

I call BS on that “rule”. 25+ years of experience here working on very large C/C++ code bases used by large commercial companies. And I have never ever seen this happen in practice. I know that the often cited “rule” makes some Lisp fans feel all smug and superior. But it doesn’t seem to be based on reality.

The rule, for a YAML-based no-code tool, would be:

"Any sufficiently complicated descriptive-declarative programming language contains an ad hoc, informally-specified, bug-ridden, slow implementation of a Turing-complete programming language".

In Concepts, Techniques, and Models of Computer Programming, Roy and Haridi define descriptive-declarative programming as:

"The declarative 'program' just defines a data structure. This language can only define records! For example, defining graphical user interfaces. Other examples are a formatting language like HTML (Hypertext Markup Language), which gives the structure of a document without telling how to do the formatting, or an information exchange language like XML (Extensible Markup Language), which is used to exchange information in an open format that is easily readable by all.

The descriptive level is too weak to write general programs. So why is it interesting? Because it consists of data structures that are easy to calculate with. HTML and XML documents, and declarative user interfaces can all be created and transformed easily by a program."

I find that quote true regarding the linked example yaml.

Applying it globally might as well be BS. Where I've seen it in practice is in software that allows end-user configuration.

At the intersection of classic directive oriented configuration and the dynamic configuration file, but not quite an embedded language.

Another example is when you allow users to input rules, or have rule builder systems. You're going to build something similar to a lispy evaluator fir those rules.

I think Ant (the Java build tool) might be a good example of what you are talking about. As I said above, I haven't experienced it in any software I have worked on myself, but Ant might actually be a good example of the "rule" in practice. Except that (AFAIK) Ant doesn't have Lisp style macros for example.

> I call BS on that “rule”.

Maybe because you don't understand what it is about? It's not about including an actually instance of a Common Lisp subset (that that has been seen, too), but that the application programming language (C++ was popular in 1993, when this came up) of complex applications will be enhanced by all kinds of dynamic features incl. custom higher-level languages on top of it. At some point in time it was popular that the projects invent this stuff by themselves. There are really zillions of examples for that.

Vassili Bykov explains: "...that complex systems implemented in low-level languages cannot avoid reinventing and/or reimplementing (poorly on both counts) the facilities built into higher-level languages. Like garbage collection in OLE or keyword arguments in X."

Other examples: dynamic loading of code at runtime, serialization of data, a built-in scripting language, complex error handling, configuration languages, a dynamic object system (dynamic = extensible/introspective/...), meta-level features, extensible syntax, ...

Many larger programs needed this facilities: A CAD program in C++ will usually add a multitude of these features incl. a scripting language to C++.

> that complex systems implemented in low-level languages cannot avoid reinventing and/or reimplementing (poorly on both counts) the facilities built into higher-level languages. Like garbage collection in OLE or keyword arguments in X."

Nope. Not true at all. Games for example implement “garbage collection” all the time but it is not the garbage collection typically used in “higher-level” languages. It is instead carefully tailored to the task at hand to achieve the kind of performance players expect from games. This is something you can not do in most “higher-level” languages. Which is the reason why most high performance complex software is not written in “higher-level” languages.

So there is a reason why smart experienced developers start new complex high-performance projects in C/C++ every day. They simply use the best tool for the job.

That's still misunderstanding the point. It's not about implementing ALL and EVERY high-level language feature on top of C++. It's that large projects (note when the quote was made) OFTEN implemented something like HALF of the features of a language like Common Lisp in an adhoc way in that project. There a multitude of examples for that. Many of them were written in C++ and many of them were later re-implemented in Java (or similar).

That's even seen in games: Many games have high-level sublanguages or use them in deep in the game production process. Stuff which was implemented in Scheme (a Lisp-like language) for "Uncharted: Drake’s Fortune" which was otherwise written in C++: Particle definitions, Animation states, Gameplay scripts, Scripted in-game cinematics, Weapons tuning, Sound and voice setup, Overall game sequencing and control, ... Other game studios use other high-level languages in or for games, even self-invent them. Earlier versions of their games engines even were implemented in C/C++ and were providing a Scheme-like runtime with special memory management.

This does not mean that all of a game or any game is written in a high-level language. It also does not mean that every game has a garbage collector like in, say, Java. The Java GCs are also often not written in Java themselves. But JVM usually have one or more different garbage collector implementations for a wide variety of task - even for server applications with complex performance needs. It's a feature of those JVMs. There are zillions of server applications which are not written in C++, but in Java (or Erlang, Python, Ruby, ...) , but still using C++, since parts of the runtime can be written in C++.

I agree with what you are saying. So I am not sure what it is you think I am not understanding. My objection was to the “rule” claiming that implementations of higher-level features in lower-level languages are always inferior (“poorly on both counts”). That is simply not true. For example, a high-performance AAA game typically use a number of different custom garbage collectors all optimised for specific purposes. Solving a hard problem that higher-level languages can’t solve. There is nothing inferior about that. So that part of the “rule” is wrong. And if we remove that smug incorrect parts of the “rule” then all that remains is a claim that complex systems often implement higher-level features in lower-level languages. That part is obviously true. But not very interesting.

An example was Gosling Emacs written in C by James Gosling (who later developed Java). He added his own adhoc scripting language: Mocklisp.

Instead of using a real Lisp, he invented his own, poorly.

Stallman later rewrote Gosling's Emacs: he added a Lisp runtime with real GC and a Lisp, which was based on Maclisp.

That's now GNE Emacs.

Yep those are good examples of how not to do it. Games typically instead link in Lua or Python and get on with it. That’s a much better approach. Another good example is the Unity game engine, using C# as the scripting language and then compiling it to C++ for high performance. That works really well.

Note: 'nowadays'. The 'rule' came up in the early 90s, when Lua and Python just were appearing.

Reply on news.ycombinator.com