> "Which works great, as long as those DSLs are complete, standardized, and mostly not leaky. In the spirit of your comment, I'll let you discover for yourself

> "Which works great, as long as those DSLs are complete, standardized, and mostly not leaky. In the spirit of your comment, I'll let you discover for yourself why that doesn't seem to happen." Two reasons: 1. Computing is a relatively young field, and not all of the best practices have made it to the mainstream. 2. The quickest way to develop is to bolt additional code onto the side of a project rather than considering how the overall requirements for the software application may be better served by designing reusable helper functions and refactoring. Also, I think you've dismissed Red a little too quickly. The GUI DSL is not the only factor that keeps the codebase compact. I'm using the word "compact" rather than "small" as I recognise that Red is still in its infancy, but with the word "compact" I'm trying to emphasise that Red does a lot with not a lot of code. > "EDIT: As an aside, the Java 1.1 JVM was only about 15MB." How big was the JCL (Java Class Library) at the same time? Also, 15MB for a VM on its own is not that impressive. Even Oracle have managed to make small (feature complete) VMs, for example: https://blog.plan99.net/graal-truffle-134d8f28fb69 https://blog.plan99.net/graal-truffle-134d8f28fb69 "The resulting runtimes have peak performance competitive with the best hand-tuned language-specific compilers on the market. For example, the TruffleJS engine which implements JavaScript is competitive with V8 in benchmarks." "To give a feel for how easy it is to write these engines, TruffleJS is only about 80,000 lines of code compared to about 1.7 million for V8." http://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate-vm.html http://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate-... "The Substrate VM addresses those deficiencies by producing a static binary of a Truffle language runtime. It performs an extensive static analysis of the runtime, noting which classes and methods are used and stripping away the ones that are not. The AOT compiler then performs some up-front optimizations such as trivial method inlining and constructs the metadata necessary for Graal to perform its runtime optimizations. The final output is a version of the Truffle language interpreter fully compiled to native machine code; i.e., there is no Java bytecode anywhere. As an added benefit, the binary size is considerably smaller than the JVM’s because all the unused classes and methods are excluded."