Feeding Baby Penguins.

Rethinking the MPS II compilation chain

During summer I’ve spent a lot of time looking at how Qi compiles to Common Lisp.

The thing is that I’ve written the MPS II macros to expand into something that looks like it’s been hand coded. That’s been sort of a corner stone in the idea behind MPS and MPS II. The reason is because I wanted to allow easy inspection of the generated code to allow finding bugs and other irregularities easier.

This Qi code study however, changed everything. The generated code is butt ugly but fast as hell and more importantly, the “pretty” Common Lisp code is slow. Goto considered harmful? Sure. No problem, as long as it’s fast.

Obscure Programming Languages Exploration Group

A couple of days ago @niclasnilsson and I started talking about starting an Obscure[1] Programming Languages Exploration Group here in Gothenburg. Earlier today we met for lunch together with @jorgen99 to discuss how to go about it.

There’s nothing much decided yet about form or content but a few things are worth mentioning anyway. Mostly because I’d love to hear your thoughts on how to go about this.

First of all, we agreed on using GitHub for all the code that we write.

Secondly, we will try to set up a number of problems that are large enough to make a decent code base (we’re thinking slightly larger than a typical code kata) but small enough to be possible to solve alone in a few weeks time without super human powers.

Last, but not least, most of the work will be done homework-style, meaning that we won’t spend much time at the meetings actually writing code. Instead we will focus on discussing differences and similarities between solutions and languages.

There are a few reasons, hopes and assumptions behind these choices:

It allows people to join the fun from anywhere. All you need is a GitHub account and to promise to commit often and to take extra special care when writing your commit messages. We have this idea that if we write really, really detailed commit messages describing not just what has changed but also why and how you think about going about your solution, then going through the commit log should be a decent substitute for attending a meeting where that solution is presented.

Also, since GitHub allows comments on commits, the most interesting discussions about the code won’t necessarily happen at a meeting.

And, if the author doesn’t understand your questions and suggestions or, if you feel that code speaks louder than words, you can fork the repository and implement the solution that you think the author should have done in the first place!

Today we decided to meet again (the three of us) on the 23rd of June and at that time have solutions to a Reversi problem (I’ll post details when I get them) in Scala (Jörgen), Ioke (Niclas) and Prolog (Johan).

And that’s about as far as we’ve discussed things. So. What’s wrong with the above? What will so obviously not work? Which of our assumptions and hopes are completely ridiculous? What else would it take to make the above work for you?

Comments, thoughts, criticism, questions and suggestions welcome.

[1] Obscure might not be the most descriptive word for what we’re looking for. We’re not that interested in languages designed to be obscure, rather languages that haven’t gotten the attention they deserve for some reason or other.

Finishing up MPS II

Today I added the last of the missing functionality in MPS. With the last commit I’ve got 11 functions in the public API. They are (in alphabetical order): agenda, assert-facts, clear, deffacts, defrule, facts, halt, modify-fact, reset, retract-facts and run. Some of these could have been left out and some should probably work differently from how I’ve implemented them now but that’s all details.

All in all, I’m very pleased with the result. The code base is smaller (roughly 500 LOC, almost half the size of MPS I) and a lot clearer and easier to read and understand. I’m particularly pleased with a few of the public functions. Here’s how the agenda function turned out:

If you know your way around production systems you’ll hopefully agree with me that there’s probably not a simpler description of the agenda functionality (using the conflict-resolution-strategy depth).

The next couple of weeks I’ll try to weed out as many bugs as I can by running a bunch of benchmarks (mostly Ms Manners) and I will hopefully come up with a way to add meta data (for example salience which I’ve left out for now) to rules.