3 ms·
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 whe
by lispm 5y 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 5y agoI 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 5y agoAn 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 5y agoYep 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 5y agoNote: 'nowadays'. The 'rule' came up in the early 90s, when Lua and Python just were appearing.