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.

Christmas reading list and writing tips

Our two weeks of vacation are now over, two weeks of family celebration, and while I was playing video games, my husband was upstair working on C³ as always. Since last time, I continue to insist that he should start writing a description of the project. I believe this process will give his vision a much more precise shape. Two difficulties arose from this: words and scope.

I have this great concept in mind but have no idea if it has a name or if I just invented it!

When starting to write things down, Alex had to find the correct vocabulary to describe what he had in mind. The problem is, there aren’t always words for the concepts he wants to express. Or maybe there is, and he just doesn’t know? Or even worst, sometimes in the world of language designers, the same word have been used to describe different concepts, but he needs one for each of them. He ended up reading tons of papers on programming language, watching conference videos, reading presentation slides, and searching in the dictionary. At some point he may have to invent his own vocabulary, and try to keep away from weird terms such as in Algol-68 (my favorite algol invented term is “incestuous union”, isn’t it amazing?)

I don’t think he found all the answers he was searching for, but he sure made a lot of discoveries that are shaping C³ into something even better. I asked him for a bunch of interesting links so that I can read them myself, and share them with my dear readers. Here they are:

If you have suggestions, either texts or videos, that my husband and I should read or watch, please post them in the commentaries!

How precise should I make this documentation?

Is is very hard to define the exact scope of a first draft documentation for such a large scale project. Code is documentation, the most precise documentation you can hope for, but it is filled with unnecessary details and doesn’t focus on the big picture, so we need words (and/or drawings) to do that. How detailed should the description be and how much should it cover? What is the language syntax, how it works underneath, how it integrates itself with the tools, how it changes the world? He is far from complete in the process of writing so I figure I would write some tips to help him out, tips that could apply for any large scale architecture project.

We have to go back to the goal of this process: refine and clarify the vision. Get down and try to express in words the main aspects of the project, especially everything that makes C³ distinct from its predecessors. What is C³? How does it work? How is it used? But especially, what does make it special?

Having a vision is the starting point, one cannot refine nor clarify what doesn’t exist. Alex has lots of ideas about his project, but he needs to narrow them down to what is really important. This can take the form of vision statements. This method usually have the reputation of a marketing/manager thing but actually, the main goal of these statements is to provide a decision making tool. Testing new ideas against the vision statements allow to see more easily if they are in the right track or not. Since the beginning we have used the three words “flexibility, performance, control” to test lots of the concepts. They have been very useful but is also proved too vague to really lead in the right direction. Many other programming languages could claim to answer to them, while we feel those languages don’t go as far as we aim. I feel that an improved vision statement could probably be a refined version over what we have already been using.

No matter how clear are the ideas, start writing now. Different audiences require different documentation, but we need to be able to write for ourselves before writing for others. Being completely accurate is important when writing for others, but not when writing for yourself. Let the words flow, draw diagrams with tons of overlapping arrows, read ourselves back after a good night of sleep, thrash, re-write, fill the gaps, and start writing again. I believe we will then find our ideas evolving faster than if we had kept them inside our mind.

Priority in writing documentation should be set as in any projects, start with what is the most risky and what gives you the most added value. Describing the little details of something that already exist elsewhere is surely easier, but won’t give you much in return. Efforts have to be put on both the unknown and the major innovations, and they are often intertwined.

Early in the development, better start with the big picture, and refine each section in the next iteration. For this, structure is the key. The exercise of structuring the documentation might have an influence on how you will structure the implementation later on, and it might be easier to do this with words than code. Breaking down the project in parts, then breaking each of these into smaller items will help you find out what is already defined, and what is not. We have never done anything like C³ before, very few have come anywhere close, and so it is very hard to describe and evaluate the project. But if we split it into smaller items, chances are that many of those elements are similar to things that we have encountered before and therefore are easier to describe and represent less risk. Then we can get a better view at the unknown, split in smaller sized pockets, more manageable this way.

How to know what is important to describe in the “how does it work?” section? Before anything else, we need a good conceptual model¹, or in other words, how the system needs to be understood from the outside. This description does not need to be complex and exhaustive. On the contrary, the simpler, the better. The code shall be the deep description of how it works inside, the conceptual model is used to get in touch with the actual goal: that C³ be used by actual people. Talking about this, my husband suggested that he should start writing use-cases, I believe this is the right track.

Back to the pillow talking

I love staying in bed in the morning, and talk with my husband for hours, programming language design being our favorite conversation subject. So two weeks of vacation gave us much more opportunity to do this than usual. He was thrilled with the unification of static and dynamic polymorphism, but now he feels that the unification of imperative and functional programming has even more potential. I love to see him as excited as he is about those things, and all this reading and writing is stimulating even more.

¹ I’m borrowing the term “conceptual model” from “Design of Everyday Things” by Donald A. Norman. The author describes how important it is for the user to have a mental model of how things work inside in order to use them correctly. I deeply recommend this book even if it is more than 20 years old!

Food, challenges and inspiration

This time it was a fantastic week-end, we had a meal with an old friend and an unexpected guest. Can it get any better than a table, with nice (french-canadian) food on it, and intelligent people around it, talking about programming language design? Aside from being wise and clever, what our new friend brought was experience. Insights from others that went down the road of creating a programming language is a precious thing. We learned a lot about the challenges that waits ahead.

We spent a large part of the conversation challenging Alex on his design. Until this day, a few friends had challenged him and I also do the same on a daily basis. But our two guests had a different approach, they have a lot of experience with C++ and other languages, and are actively participating in the D 2.0 effort. They are somewhat part of the competition! This time, I switched side and practiced my own sales pitch to stand by my husband. We had to cross the language barrier as well, English being a second language for everyone.

This challenge was very stimulating, discovering what others seek into a programming language, finding about things we never thought about, explain ideas and try to be convincing about them, and the most important, having fun doing all that. We also reached a point where things were not defined, or refined enough to explain it to someone else, there we had to realize the necessity of putting things down on paper.

After all this, I was bursting with ideas about the importance of documentation in the elaboration of a clear vision. I started working on a new twist of the iterative methodology and couldn’t stop. We went to a Christmas music concert and I started writing everywhere on the concert program. I wanted to write a blog post about this, but I have to calm down and make something organized with all this before it becomes possible.

The dynamic between the two of us is taking shape with each challenges, what is my role into all this, and where he has to work alone. I am growing skills in communication and management in my day job, but in the end, he is the technical expert. This is probably to our advantage, we complete each other in so many ways. They say that behind every great man there’s a great woman, with such a great husband, I will have to surpass myself to keep this saying true.


Ancestors of C³

c3wifepyramidWe had a very slow week-end. Some friends came home saturday evening, and we went to sleep after too much food, wine, beer and video games. No wonder why it was so hard to get out of bed Sunday morning. So instead of getting things done, we spent some time together, talking about C³ on the pillow. Alex was telling me how existing programming languages were inspiring him and making things possible for him. He suggested I wrote something about it. I thought it was a very good idea.

C³ doesn’t intend to change everything, on the contrary, my husband want to take what is best in the already existing languages and bring that to the next level. Reinventing the wheel is not about starting from scratch, it’s about learning from the past, taking advantage of the tools you have, that your ancestors didn’t, and innovating at the same time.

Low-level inspirations

An inspiration I didn’t expect was LLVM. We have coded in C and C++ for so many years, those languages infused themselves into our mind. But LLVM has been in our live since so little time, and we haven’t really coded with it, and yet it seems to be an important source of solutions for problems he had earlier this year. Almost too good to be true.

The first thing that came to mind was that LLVM makes a perfect back-end. It fits the requirements: low-level enough to provide performance and control, and a special attention to performance as well. The C³ compiler code is planned to be flexible to support different back-ends, but it seems very likely that LLVM will be the first one.

But LLVM is not only a tool, its implementation contains some nice things too. The analysis and optimizations that LLVM makes on the SSA form (Static Single Assignment) is very inspiring. The algorithms behind this are very powerful and my husband want to adapt them for his own optimization system, or in short, apply them for high-level types. The list is very long, but to name a few: “Dead-code elimination”, “Constant propagation”, and “Combine redundant instructions”.

Good old C is also an inspiration. To be more specific, he really likes the way the abstractions of the language directly map on the different modern computer architectures. As he mentioned in his latest notes: the flexibility of a set of native abstractions (that may change between target machines!) may be the core element that will allow C³ to be the bridge toward the next generation of computers.

Syntax and types

I talked a lot about C++ as an inspiration. One feature of C++ that he wants to push beyond its current boundary is the ability for the user to create his own types. What he wants is to make user-defined types first-class citizens of the language. Int, float, long and double don’t have to be special cases. The language architecture is done in a way that allows every type to be used without additional limitations, optimized as much as intrinsic types would have been.

The C++ syntax is a familiar one but flawed in so many ways, especially the type declaration syntax. Bjarne Stroustrup admit himself that he kept it this way only for backward compatibility with C. It is a mess to parse and some contradictions have led to many debates: do I put my * with the pointee type or with the pointer name? But yet many languages like Java and D continue to use it as an inspiration for syntax, C³ as well. The reality is that the C++ syntax contains everything necessary for a good syntax and people love it! It just need a good clean-up. My husband describes the C³ syntax as a “naive” version of the C++ syntax, which means what you would think the syntax is intuitively instead of the one you discover in the field.

Multiple paradigms

Having multiple paradigms is a major aspect that my husband want to push farther. Being able to mix and match different programming styles with the same language is a rare quality that we love in C++. Some believe in purity of style, we believe that the right toolbox has a variety of tools that cover most situations, and even allows you to build your own!

One of these tools is generic programming. In C++, it is a powerful but complex style. Templates have allowed for this to be possible by decoupling the algorithms from the data structures they are processing. Inspired by the writings of Alex Stepanov and his work on STL, my husband intends to make generic programming something more intuitive, for example with the unification of static and dynamic polymorphism.

My husband often says that functional programming is an important part of C³ with the use of functions and closures. In C³ it is done with a “function” type that allows functions to be assigned to variable (that means support for closures as well). When I think about LISP, I think about parenthesis. But reading the essays of Paul Graham, I have to admit that functional programming can often be the best tool for the job, especially if the syntax is made convivial. An unexpected inspiration that has lots of potential.

Not only does he plan the unification of static and dynamic polymorphism, he is planning the unification of imperative and functional programming as well, isn’t it interesting…

So many…

Each of these elements would be worthy of a post by themselves, and there are so many other inspirations, aside from those we are not even conscious about! Great languages already exist and we have so much to learn from them. I find it very exciting to delve in this complex but so fascinating field that is programming language design. And just in case you worry about the impact of all this in our couple, we do talk about C³ often but we still try to get some things done, we are almost over with the wedding thanks cards. I know we are very late on this… Better late than never!

The excitement of anticipation

c3wifeelevatorIsn’t it exciting when you know you are one step away from something amazing? Like tracking a precious package in the mail, or waiting for your plane to land in some exotic location. I feel just the same way about C³, especially recently. My husband has been working like crazy each night and his plan is becoming clearer every day. Each morning we walk together toward our day job office and we talk about programming, most of the time about language design. I learn a lot from those conversations but I also get a connection to the grandiose project growing in his mind. But you would be right to ask yourself when you will be able to see anything at all.

Being a big fan of Scrum, and using it for the team I manage daily, I consider important to ship early and often. C³ should be no exception to this mantra, but a programming language is quite more complex than the common web application. Getting to the point of a small basic subset of features will still take time, especially as this is done part time by a single human. For this reason, I cannot give a calendar based answer, but I can tell you about the plan.

To decide how many features is enough for a first release, and which ones have priority, you have to know your “client”. We believe that the base design of C³ gives it the potential to please “everyone”, but a first release can hardly reach that goal with just a subset of the language. So what’s the best thing to do then? I think: “Start by filling you own needs, chances are you will please others that have similar goals.” And as he defines what he wants, we see other programmers that crave for the same things everywhere, on forums, on blogs, in books, among our friends. People asking how to solve a problem where the best answer would be “switch to C³”.

So what is that “kind of programmer” exactly? We work in an industry where performance is the key, on projects with large code bases. Many programmers continue to work with old languages like C, even with all the problems and limitations that we know from those languages, because the more recent languages have made compromise in areas where they cannot afford to loose. Those programmers prefer performance, flexibility and control over ease of use and embedded feature. We believe that the early versions of C³ can satisfy this public with something simple, but well executed. “Simple” is probably an understatement, he wants to release a compiler that can do as much as C does, no less. Support for all the basics of a programming language, with an implementation that provide performance at run-time. We have to keep in mind that this stereotype of programmer is an autonomous quick learner but is also very intolerant toward instability and slowness.

The support for more high-level concepts will come afterward, but their development is already being anticipated, so they will be integrated naturally in the language. In which order, this has yet to be defined, but having a complex project to try it on seems like the best idea. We have yet to decide on a specific project, many are in the air: from obvious like creating a benchmark, to very audacious like porting Linux. He often jokes about that last part, but I feel he thinks it would actually be possible (but would require a C converter to make the task manageable).

One thing is certain, the first step is the biggest to make, the anticipation of this moment is a mix of excitement and fear. He is driven by his passion, but also hope. Recent announcement of the Go language could have broken a dream, but on the contrary, it confirms that there is a need for new languages, that there is still place for improvement in this field. Go can be use as an inspiration but is also very different from C³. My husband’s project have so many genuine ideas and concepts that I continue to anticipate a revolution.

Husband’s notes: C³ as a Systems Programming Language

Bjarne Stroustrup describes C++ as a “general purpose programming language with a bias towards systems programming“. I aim to make C³ simply a “general purpose programming language”. It will provide high-level features that I hope will qualify C³ as the best language for tasks that are currently best served by domain-specific, scripting, or other general purpose languages. It is an incremental improvement over C++: it means that C³ will be suitable for a wider range of software projects than C++. It does not mean that systems programming will receive less care! Some languages make low-level tasks impossible or harder because they try to provide high-level facilities. In C³, all “levels” will get full support! In today’s notes, I explain the design choices that will make C³ the best systems programming language: there will be no bias, but there will be no compromise either.

I want C³ to become the first choice for systems programming tasks such as heavy-load application infrastructures, cutting edge 3D games, real-time applications, and operating systems. To achieve this, C³ will follow the C++ design guideline “you don’t pay for what you don’t use” even more than its predecessor. (See The Design and Evolution of C++.)

I always hear about new languages that add “just a little bit” of overhead to enable easier programming techniques. For example, they have garbage collection and built-in types like strings and maps. I believe it is possible to design a core language that will make easy programming possible without these integrated features. The key is to make the “user-defined” features first-class in syntax and performance as if they were integrated. Some C++ features like copy constructors, operator overloading and inline functions are steps in this direction but the resulting types often have rough edges and are not as efficient as built-in types. C³ users will be able to define seamless and fully optimizable modules, data types, and even control structures! Features like communication facilities, dynamic arrays, and loop structures (including multi-threaded ones!) will be available in the C³ library.

Because I want to support all possible programming environments, there will be no core language features that require any kind of system runtime support. When coding an OS, you’re on your own; there is no system support! The only requirement is a compiler back-end that maps a set of “native” abstractions to the target machine language. Everything will be provided to build higher abstractions from the ground up. Of course, many facilities that require support will be provided! You’ll find them in the C³ library and they’ll be very easy to use, as explained in my previous point.

The C programming language succeeded for OS programming because its core abstractions were close enough to the available hardware platforms. But we can do even better! An innovation in C³ is that the set of native abstractions may change between target machines. This flexibility will allow the C³ system programmer to target different memory models (remember near and far pointers?) and new computer architectures (quantum computing, anyone?). Moreover, it will enable more target platforms that are not necessarily hardware. Someone could implement a back-end that targets the JVM, the CLR, or even javascript (for web applications).

C is still the number one language for kernel-level programming. Unfortunately, it makes OS hacking harder than it should be because C does not provide high-level features. C++ tried to combine the best of both worlds but failed in this niche in part because of its system support requirements, even if they are small. It also does not give enough control on the implementation of its complex features. For example, sometimes, the exact layout of the vtable of an object must be in the control of the programmer. (See this interesting discussion featuring the Linux creator.) In C³, everything that is of a higher-level than C constructs will be fully customizable and implemented in C³. For known object-oriented features, usage will be mostly like in C++, but the definition will be accessible in the C³ library instead of its compiler. This will also enable programmers to design their own interoperability layer with other languages.

I could continue to write for hours about various details that will make systems programming in C³ both effective and enjoyable but I also have some compiler code to write. Maybe next time I will talk more about the C³ library that I keep mentioning without further explanations… See you soon!