5 ms·

> 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

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

jasim 5y ago
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."
mhitza 5y ago
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.
- mbrodersen 5y ago
  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.
lispm 5y ago
> 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++.
- mbrodersen 4y ago
  > 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.
  - lispm 4y ago
    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++.

jasim 5y ago

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

mhitza 5y ago

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.

mbrodersen 5y ago
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.

lispm 5y ago

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

mbrodersen 4y ago
> 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.
- lispm 4y ago
  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++.