This article shows a lot of the silliness in both a) writing compilers in C++ and b) re-creating well-worn compilers tools like parsers from scratch.

1. Their definition of values in the language (unfortunately called "Variables") is a product (class) over all possible types:

  class Variable {
    ...
    double numValue;
    string strValue;
    vector<Variable> tuple;
    string action;
    string varname;
    Constants::Type type;
  };

This means each value at runtime has a large memory footprint, as each instance of a value contains slots for all possible types even though only one will ever be filled. Sum types solve this problem.

2. The author intermixes parsing and code generation. This makes it difficult to implement any kind of optimizations, even for an interpreter. For example, in order to do function inlining in the author's language, you would have to manually inline calls in every single part of the code generator instead of having IR transformations as separate modules (see: LLVM). It also tightly couples the two pieces of the compiler, making it difficult to change parsing strategies without rewriting the code generator for instance.

3. It took the author nearly 5000 lines of C++ to write an interpreter for a simple Javascript-like scripting language. Some of this is due to the verbosity of C++, and some is due to the needless effort of reimplementing parsing from scratch. I implemented a similar language in <1k lines of Rust [1], and I'm sure that others could do even better in Haskell or OCaml. On top of that, the author's claimed benefit of extensibility requires writing large amounts of boilerplate.

[1] https://github.com/willcrichton/lia