3 ms·

> that complex systems implemented in low-level languages cannot avoid reinventing and/or reimplementing (poorly on both counts) the facilities built into highe

> 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++.
- mbrodersen 4y ago
  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.
  - lispm 4y ago
    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.
    - mbrodersen 4y ago
      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.
      - lispm 4y ago
        Note: 'nowadays'. The 'rule' came up in the early 90s, when Lua and Python just were appearing.

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

mbrodersen 4y ago
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.
- lispm 4y ago
  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.
  - mbrodersen 4y ago
    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.
    - lispm 4y ago
      Note: 'nowadays'. The 'rule' came up in the early 90s, when Lua and Python just were appearing.