overwatering.org

blog

about

PLT = Programming Language Theory, btw.

Programming languages have always appealed to me. Right from the beginning on the Apple //e I could tell that there was a substantial difference in their expressive power, though I didn’t know that was what I was thinking at the time. I started to get more seriously interested interested when I did the unit in compilers (SIT311) at Uni, and realised that a compiler was a very useful approach to solving a lot of problems. But there were really three things that got me thinking in depth about PLT.

  1. When rewriting ERT as Expert 6 we made a conscious and concerted effort to use all the language and library features of C++ that were appropriate. Initially this was about not re-inventing the wheel: if there was a good string class in the standard library then use that instead of writing our own. Overtime we realised that we could go further: using the language and library features as ’Barney’ intended meant that we could occasionally prevent incorrect code in the runtime from compiling. This didn’t happen anywhere near as often as I would have liked, so I started thinking about ways that a language could have saved us more.

  2. Expert itself is actually a runtime to execute compiled programs written in a specialised logic language. Being exposed to and working closely with this sort of special-purpose language was an interesting experience. I could quickly see that using this kind of special-purpose language for rules was far more effective than trying to write the rules in a general-purpose imperative language. I even had arguments with other employees about how the runtime was not just ‘a big switch statement.’ There was one other developer who wanted to use Expert to write complex business rules other than legislative rulebases. I was very excited by this, but it never happened. While working on the Expert runtime and in particular debugging rulebases, I really noticed how the typing was inconsistent and extremely weak. Functions and in particular user-defined functions were also hopelessly constrained. I started to think about how typing could be done properly.

  3. Strangely enough this is the main point that really introduced me to formal programming language theory. I read jwz’s critique of Java (java sucks) and I really wanted to understand everything he said there. Mainly, what was a ‘long-lived closure’ and why did he miss them so much? Or a ‘downward funarg?’ So I started reading and searching. Eventually I stumbled upon Lambda-the-Ultimate and found a huge world of other terms and concepts. By this time emtap had evolved from a framework into a language and while reading LtU I discovered that a lot of these concepts would immensely help with the design and implementation of emtap.