I'd say we're doing all right.
Are you serious?
Yes. What's wrong with my D version? It's short and to the
point, works, and produces optimal code.
Your version is basically a very long-winded way to say "auto x =
5 - (3 + 1);" so it really has nothing to do with the example.
The point of the example was to represent a simple AST and store
it on the stack, not to represent + and - operators as plus() and
minus() functions.
(I must say though, that while ADTs are useful for simple ASTs, I
am not convinced that they scale to big and complex ASTs, let
alone extensible ASTs, which I care about more. Nevertheless ADTs
are at least useful for rapid prototyping, and pattern matching
is really nice too. I'm sure somebody could at least write a D
mixin for ADTs, if not pattern matching.)
1. If you write FORTRAN code in D, it will not work as well as
writing
FORTRAN in FORTRAN.
2. If you write C code in D, it will not work as well as writing
C in C.
Really? And here I genuinely thought D was good enough for all
the things C and FORTRAN are used for.
3. If you write Rust code in D, it will not work as well as
writing Rust in Rust.
I hope someday to have a programming system whose features are
not limited to whatever features the language designers saw fit
to include -- a language where the users can add their own
features, all the while maintaining "native efficiency" like D.
That language would potentially allow Rust-like code, D-like
code, Ruby-like code and even ugly C-like code.
I guess you don't want to be the one to kickstart that PL. I've
been planning to do it myself, but so far the task seems just too
big for one person.
