Category Archives: Non classé

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.

Dreaming about code

Everybody keep asking me how things are going since my husband started working at home, and want to know how the project is shaping up. I find it very hard to answer – the task is colossal, but very abstract at the same time, which makes it hard to explain the progress.

We started this Sunday with the usual nerd conversation:

I dreamed about code optimization last night. It’s going to be amazing in C³ !
C³ will have something similar to move semantics, but much simpler than in C++0x. R-value references are a work around to support legacy code, I don’t need to do that.
I’m thinking about giving it a simpler name, I was thinking about “necrophagous functions”, or maybe “loot!”

Dreaming about code optimizationYes, he actually said this (but in French)! After a few laughs, I asked him what his objective was for this week.

The next step is completing the minimum work on IPG (Incremental Parser Generator), a tool he builds for himself, to create a brand new parser (no plan to reuse the old parser he built in 2003 as a university project). The “proof of concept” for this is for IPG to be able to generate itself. The plan is for this to happen this week. Afterward, he will start to write the grammar rules for the C³. He has been thinking about it for years, but now it will be time to actually type it down, and create the first parser good enough to be the basis of a compiler.

If you want more information on move semantics and r-value you can read this article, which I tried to read a while ago, mostly because a printed copy of it was left near my bath… and then I decided to go for Asimov instead 🙂

No news, big news…

Once again, a major project at my job has taken a lot of my energy, leaving me little time to write about C³. No complain from my part here, the intensity of those moments is what shapes us into improving ourselves. And beside, working with such a creative team is never a burden. So now that my work on Spider-Man: Shattered Dimensions is coming to an end, I started writting again, and it is now time to tell about the big projects coming up.

We have been saving money on the side for this day; and everything was folding into place. Alex completed the feature he was working on at work, and started a full sabbatical year a few weeks ago. There are two goals for this time period, take care of his health and bring C³ to the point where it can be released and shown to the world.

The first assignment was to make c3wife enjoyable again. GoDaddy’s server became so slow, editing the web site was a real pain. So we moved the site to a new server that is much closer to us. If you experience problems with this transition, don’t hesitate to tell us about it.

This big change should give me more to talk about, if I don’t get consumed in all my other projects. I have to keep on working hard but hey, I have a househusband! I joke a lot about that, but I know that in reality, he is going to work hard to give you the best programming language ever. He just have to fight the few pitfall from working at home. When I talked about this to my former boss, he told me “you cannot prevent someone from living his dream forever”; I believe he’s right, we are embracing it, and it starts september 2010!

How much can we tell about an unreleased project?

We are closing in on our one year wedding anniversary, or paper anniversary as they call it. For this big event, I was planning to write a full description of the C³ experience. I asked a lot of questions, draw diagrams, wrote a very long article. I was very excited because when I start reading myself, I felt that we had a very innovative concept, something that would improve the experience of programming for all. But then I started to have doubts, how can I be clear enough that this is an intention, a dream, and without creating expectations?


We cannot deny the importance of marketing. In video games, statistics show that marketing influence sales three times more than ratings. These numbers probably vary depending if you are aiming at mass market or a niche of specialized people, but the first impression you do is always important, no matter who you are targeting.

I worked on many projects that had huge marketing budgets. For all those, we had to keep quiet on what we were working on until the marketing reveal. This moment usually happens quite close to the launch which means most of the job is already done when the world learn about the project. The team usually have a hard time about this, you are very proud about this very amazing project you are working on, and yet you cannot talk about it to anyone. “The only thing I can say about what I am working on, is that it is incredibly fantastic!” We do show our work to selected people in order to get feedback, focus tests, but this is rigidly controlled not to interfere with the marketing reveal.

Reality is, this is necessary, you want your project to be hyped as much as possible. You start with a big reveal, then you maintain, and attempt to rise the hype until the product is truly available. If you cannot maintain the interest in your product, you start falling. Apple have been a very good example of this in the last few years, launching their products with a big boom, creating as much hype as they possibly can. Well timed hype translates into sales.

“A (…) problem: The company sells the visionary project before it has the product. This is a version of the famous vaporware problem, based on preannouncing and premarketing a product that still has the significant development hurdles to overcome.” –Crossing the Chasm, Geoffrey A. Moore

I have seen many project trying to create a hype too soon and missing the wave. Some games that were presented at my first GDC in 2006 have a hard time getting credibility when they aren’t completed four years later. My personal reaction is that their game got to be amazing because my team got a fraction of this for our own work, and we still manage to make great stuff. I imagine that the general customer simply forgot about it, and is mislead into thinking that it is an old thing that he just missed when it came out.

Even worst are the projects that are hipped but never see the light of day. In life, many projects get cancelled. Believe me, it happens all the time. People starts working on something, but things change, the project becomes something else, or the team simply starts over on a new concept. If nobody knows about it, you waste some time, but if you are already public with it, you also add shame on your name. You end up spending a lot of energy to justify yourself to a lot a people that don’t matter that much, and your reputation goes down. Easier to crash down a credibility than it is to raise one. Even if you have very strong creations in you port-folio, you aren’t protected from this.

Talking about a personal project

So I imagined that C³ would be different. It is a personal project, not some block buster anyway. Following the creative adventure of my husband helped me renewing my love for programming, and push myself learning new stuff. I love writing, why not write about it? Most comments, from friends or on the blog, have pushed us forward in our reflection, shaping the project into something better.

When I started, I never anticipated any problem writing about anything. My husband didn’t agree with me. Many of the concepts we were talking together were early into development, and subject to change. “Won’t people judge us if they see we are changing our mind all the time?” Not only do I think it is normal for ideas to change, I believe it is in the nature of great project to iterate on them. I am fascinated by the creative process. This is exactly what I wanted to talk about: how a project evolve, how the vision refine itself, ideas that shape themselves with the various challenges, new discoveries that add themselves to the big picture.

I was seeing myself as some kind of journalist, I though it would be obvious that I was following a creative process. But my enthusiasm led me to write a lot about C³ in a descriptive and somewhat “selling” way. I cannot claim neutrality, I care for my husband, I care for his project. No matter how I try, my words become some kind of marketing involuntarily.

I first become aware of this when my former schoolmate Michel talked about C³ as vaporware. I was disappointed at first, I though I had failed to make it clear that this was the documentation of the process, and not an actual reveal. Now I realize that this is impossible, as soon as you start talking about something, it is a reveal.

Compromise for the best of both world

So comes the dilemma, either I just don’t care about it and continue talking about it. Too bad for those who think we don’t have credibility because we don’t publish anything. They should know that creating a programming language takes time. Or I start writing behind closed door, showing my stuff only to chosen people. Closing ourselves from potential feedback and suggestions.

All this may seems obvious from the outside, but it wasn’t for me. But now that I am aware of all this, I cannot unseen, and have to take a decision. C³ is an ambitious project and we will need all the credibility, and hype we can get when the time comes. How can I keep from creating unnecessary expectation, raise my credibility while getting maximum feedback at the same time? I also want to keep on writing and drawing for the fun of it!

I don’t have a simple answer for this, but I do think of a few approaches on the subject that I feel wouldn’t interfere with the project while attracting constructive feedback.

First thing, I should go back to my primary idea of documenting the creative process. As a manager, I develop a strong knowledge of this in my day job, and I choose that way because I have a passion for it. Talking about challenges, how we overcome them, methodology and tips are interesting things to share. By nature they apply to various types of projects, thus it can reach a wider audience. This is also a nice way to get feedback on how to face certain situations. All this without really talking about the nature of the project itself.

I also realized that when we get challenged, it is more about our view on a certain topic, than how it really translates in the C³ design. Our opinions are shaped by our experience, I find it interesting to challenge my conclusions and seek advice from people that have a different background than me. I am very confident in my beliefs, but there is nothing like a good fight to improve them and make them stronger. I feel I should continue talking about our opinions, without going deeper on how it translates into the project.

As we will approach release, I will want to be as transparent as possible, describe with great details how things work, and why so, but only when the design on those aspects are complete. This is necessary to build a relationship based on trust, especially if we go open source and and want people to contribute. For now, things are evolving too quickly to spend energy on describing publicly something that is destined to change.

And then I cannot turn my back on this long article, exhaustive description of the project, a first draft documentation. I think it is necessary to write this in order for the project to go forward at an optimum pace. But now I realize I don’t have to publish these, they have to be written for ourselves, to clarify our vision into words. Maybe we can use them in focus tests. So no pressure to publish everything I write as soon as it is complete, leave space for iteration in the writing as well. The world can wait.