A couple of days ago, there was an article on Infoworld explaining that Rob Pike, at Go, is frustrated with the complexity of C++ and Java.
This prompted me to write a post on the Go language mailing list, to explain why I believe Go should be made extensible like XL is.
Here is the post:
A recent article in Infoworld reminded me that I wanted to tell the Go
community about XL and concept programming. I believe there are ideas
there that you might want to consider for Go. The primary web site is
Concept programming is the simple idea that programming is translating
concepts in our brain into representations in the computer. Whereas
there are things called “objects” in the code for object-oriented
programming, things called “structures” for structured programming,
there are no “concepts” in the code for concept programming, only
concept *representations*. Therefore, the focus becomes: how different
are the representations from the original concept?
One interesting consequence of taking the problem that way is that
language designers cannot know which concepts will matter ahead of
time. In 1970, it was hard to predict that objects would one day
matter so much that you will have to redesign languages like C or
Pascal around them. So one consequence of CP is that languages have to
be extensible, much like Lisp, with its homoiconic representation for
program. Indeed, Lisp digested object-oriented programming much better
than Fortran. However, Lisp is not an acceptable concept programming
solution for other reasons, e.g. its syntax, because what people
generally write 1+2 is (+ 1 2) in Lisp, something CP calls “syntactic
noise”. That’s why I created XL.
I believe that Go should take this kind of future-proofing into
account. This may just be my ignorance, but I don’t get the feeling
that meta-programming, for example, is anywhere on the radar for Go.
If I’m right, then I believe this is a mistake worth fixing.
Otherwise, I’m sorry for the intrusion on this list🙂
The way I did it in XL is interesting and may be a good starting
point. The XL parse tree consists of exactly 8 node types. Four
leaves: integer, real, text, symbol/name. Four structured types:
infix, prefix, postfix, block. The newline operator is an infix like
any other, for example. What really matters is that all compilation is
performed using tree rewrites on that AST, and that is’ really easy to
have “compiler plug-ins” in XL. It’s unclear whether it’s possible to
retrofit such a simple structure on Go that late in the game, but if
it is possible, then I think it’s worth a try.
Also, since the Infoworld article was about the complexity of C++…
XL is not complicated like C++, yet it does have a few features that
are above and beyond what C++ can do. Here are a few interesting
- Validated generics
- Generalized operator overloading
- Compiler plug-ins
- A user-extensible for loop
- A user-extensible “switch” statement
- Basic types like integers, pointers or arrays defined by the
- A generic complex type that is really easy to use
- A text I/O library that behaves like WriteLn in Pascal but is user-
defined and extensible
- And, naturally, inspired by Go, a multilingual hello world (with a
twist, follow the link).
Sorry for all the links. I don’t mean to intrude on this list, only to share ideas that I think are relevant for a language like Go that aims to improve the state of the art.