Monthly Archives: November 2010

The minimal system

My husband and I just spent the end of the afternoon doing our first sprint planning, and we are both thrilled about it. So far, he was working mostly on research, documentation, and the code he wrote was done without planing. The pre-design document (aims and design rules) is almost complete, the next step is to send it to some friends in order to get their feedback, and iterate from there. He also discovered tons of things doing the research, but now it is time start working on the real thing.

In order to kick-off the first sprint, we used an agile method to define the minimal system. The minimal system is the version of our project that has as few features as possible, but complete the whole sequence of the project. In our case, we have a compiler that takes a source file as an input, and output the matching program. Once we have a very basic compiler, we can iterate on it until it is perfect i.e. forever!

Making a compiler is very complex, and in any ambitious project, it can be very hard to know where to start, and how to organize your work. Since we don’t have a lot of experience in the matter of compilers, we will make lots of discoveries along the way, and the earlier we make them, the more effective we become on the long run.

The trick is to divide the project into smaller tasks/features. For high priority features, we aim to have tasks under 16 hours. The smaller the task, the more precise the time estimate. It is much easier to compare a small task to something you have done in the past, than the package as a whole. Task of lower priority are kept as a bigger tasks, to be divided later.

We organised the tasks on two axis, from left to right, it was the chronological order of the feature, the order in which they happen when the program is used. For example, on the right was the the grammar, then the parsing, then the code generation. The second axis is the importance for the system. At the top, the feature that the system cannot exist without, at the bottom, stuff that are optional. The minimal coherent system is the first line at the top.

The first surprise, for both of us, was that the minimal coherent system was much more “minimal” then we though it would be. But at the same time, it is very logical, every task will confirm that the previous one was correct, so it is more effective not to go too deep just in case the following step shows you how you were wrong in the first place.

We have decided on the goal of the first four sprints, and all tasks for the first sprint are defined and evaluated.

  1. A compiler that compiles a function of a single add instruction of int32.
  2. A compiler that compiles a function of multiple add instructions of int32.
  3. Add support for the other basic instructions on an int32
  4. Add support for the if instruction

Alex also realized that a friend was right when he said: “You know, there are lots of boring stuff to do when creating a compiler for your language, it will be very hard at some point to keep your motivation”. He has some amazing innovative ideas, but he has to start with the very basic things before getting there. He calls this project C³0, a very basic compiler, similar to C. But we believe the exercise we just made is a big part in the solution to this problem. With a clear goal, and a clear planning, it is more motivating to see how the little things fits in the bigger scheme of the project, and how much time you are going to spend on such things. Seeing what is coming up is also a very good motivator, I like to put the spotlight on a very interesting task that needs less interesting things to be completed in order to get started.

Working alone is a big challenge, for motivation, to keep the focus on the right things. So we talk about how he could organize his time. He wants to reach the sprint goals, but he wants to keep on reading and learning, he also would like to write more on his blog to get the input from all our fantastic readers! We came up with a list of “rules” to have the good balance of everything.

  • Usual business hours are spent 100% on the current sprint tasks.
  • Reading of books or other documentation not directly related to a sprint task are done on lunch hours, evening or week-end.
  • One post on twitter per day, it can be an update about the project, a joke about programming languages, a picture, a link, anything!
  • One post on the blog per week-end (unless we are out of town).

The exercise went really well, and my husband felt it helped him a lot, figuring out how he will implement his compiler, and setting the objective of the next few weeks. I feel there is a lot of learning ahead, but we are on the right track! Alex is very nervous about this post, it is very open on the fact that all his ideas are on paper and not coded yet, (aside from the spirit prototype parser)… but it is part of the experiment to raise his motivation to a new level!


I keep seeing a huge trend of nostalgia all around. The last few years have seen the return of 8 bits music, old movies and tv shows rereleased on DVD, pac-man and space invaders overuse in design, the rebirth of roller derby, vintage is now the main influence in fashion. Everywhere I look, I see the impression of the past, and my biggest surprise in all this: I totally dig it! I had an amazing time watching Scott Pilgrim, I play on my Sega master system once in a while, and I love going to work on my quads. Seeing vintage programming languages concepts making a come back surely fits this trend!

A bit of background history
When I started programming, the big thing was object-oriented programming. If you were doing anything else than that, you were either unlucky, forced to maintain some old COBOL stuff, or stupid, not seeing the “great greatness” of OOP. On my end, I had a thing for assembly languages, learning as many as I could, even VHDL. In those days, I justified myself by saying that low-level languages were more suitable for embedded programming.

Not so long after that, web programming became the big trend. Rapidly, the necessity of having a powerful and effective developping tool was outed by just having the right idea, at the right time and be the first to put it on the Internet. Being good at marketing seemed more important than writing beautiful code; fast and dirty code more useful than complex and large scale architecture. Meanwhile, I finished school, started working on games, the “blockbuster” type, using C++, and never really went into web programming.

I never was a complete rebel, but mainstream never was my thing. My mom and I have the habit of spoting the ugliest thing in a clothing store and making fun of it. I feel proud when I do something because I love it, and not because it is fashionable. But I wouldn’t refuse myself something trendy just for the sake of it, if I truly like it. I had mixed feelings when I realized the proportion of stuff I like in store suddenly increased recently. I was even more surprised when I saw the same pattern emerge in computer science.

When I first heard about functional programming languages, I was amused at the large amount of parenthesis, and didn’t gave much attention. During our wedding vacation, we had a long conversation about programming languages’ grammars. Alex explained to me the simplicity of the LISP grammar, and how it affected the mindset of the programmer using it. He told me that there had to be a way to make functional programming language possible in C³ in order to make it truly complete. On the other end, he didn’t want to let go on all the other programming styles he loved so much, imperative, generic, etc.

Soon after that, I started seeing functional programming everywhere. It had been there for more than fifty years, I just opened my eyes. People arguing about how Haskell was the best language ever, D introducing functional programming, Scala… well… existing! Many other people seemed to have seen the “divine” light at the same time I did.

Evolution vs. Revolution
So what is different with this, compared to the previous trend? I feel that previously, things would be fashionable because they were new and shiny. Functional programming is different, it is attractive because it actually solve problems that we currently care about – optimization, parallelization etc. This is evolution, instead of revolution.

In order to make it a true evolution, we cannot simply reuse the old things from the past. There are fundamental problems that kept LISP from being more popular in the past. If functional programming languages are perfect for certain types of problem, they are totally horrible in other situations. The obvious idea would be to mix it with the other programming styles, to make functional more convenient, or to add the possibilities of functional to an already good but incomplete system. But the problem is that functional programming style doesn’t play well with others, the very basics of the paradigm rely on purity, on the assumption that “side effects” are not possible. But someone found a trick.

When my husband started reading about LLVM, he stumble upon “SSA is Functional Programming” (which was part of my Christmas reading list last year). The trick is to have an intermediate form, the Static Single Assignment form, for the imperative code. If the grammar allows the imperative form to be compiled into a functionnal form, then the two can coexist and you can get the best of both worlds: easier writing and understanding of the code, and effective optimization and parallelization. I’m oversimplifying things, but it gives an idea of the mindset!

Learning from the past
When I started dating Alex, I remember he was reading tons of books on starting business and management philosophy like Peopleware and Guy Kawasaki. The “cult” of the start-up has been very trendy in the past few years, and is still very big. But slowly, his buisiness model research is replaced by a quest for pure knowledge, things written by programmers, university papers, technical stuff. I mean, he was reading a lot of programming books before, but he now digs farther in the past, he calls it “archeology”.

Computer science has a very interesting history, many phenomenal minds have searched and discovered so much. And yet in school, we teach only the “new”, the things that you will use in the industry. Students learns OOP without ever being told about pointers. This is enough if you want to make yet another business application. But if you want to make a true revolution, you have to know where things come from, learn about the roots of your field.

Compared to other fields, computer science is very young, making it more “accessible” to know “everything there is to know” about the field. Most of the main actors in the development of computer research are still giving conference around the world. On the other end, computer science is not complete without a deep knowledge of mathematics, where there is much more history to cover, and Pythagore has been gone for quite a while.

So when do you know you know enough, and are ready to dive in the revolutionary project? There is always something more to learn from books and papers, but we will understand them better with hands-on experience. So it is not about learning first, coding after, the trick is to have a good balance of both, and creating a positive cycle; new knowledge allows to make more complex programs, experience allows to understand more complex knowledge, etc.

The same pattern emerge for my clothes, and for my husband’s programming language. We mix and match what we like most from the past, we try to find clever solutions to the things we don’t like, and we use the latest technology for an even better result!

My husband has spend a lot of time reading and learning, but after a while, we realized it was time to actually try all this stuff. His plan is to have a minimal system for christmas. But I expect that his brand new Kindle (his birthday gift) will continue to be filled with plenty of computer science literature.