C³wife

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?

Marketing

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.

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:

• SSA is functionnal programming, an interesting but complex article he found via the site of LLVM. Some of the ideas I talked about in Ancestor of C³ are inspired from this text (about the unification of imperative and functional programming).
• The power of abstraction, a keynote by Barbara Liskov, my new model in life. She is just so brilliant and proves that programming language designers don’t have to wear the beard! To me, she is the example of how intelligence, experience, humility and wisdom make a great person.
• On Understanding Data Abstraction, Revisited, a great vulgarization of various concepts, especially the difference between abstract data types and objects by William R. Cook. Don’t miss the commentaries on lambda the ultimate.
• On understanding types, data abstraction, and polymorphism, the original article that inspired the “Revisited” one. It contains a very good explanation of polymorphism.
• We had lots of fun reading Go vs Brand X which reminded us how important it is to pay respect to our predecessors.
• Java in its early days, interesting to look where it was in 1996 and how it evolved from there.
• Supercompilation an interesting optimization method but on which most of the information is in language we don’t understand.
• X86 calling conventions on Wikipedia. But also the history of calling conventions Part 1, Part 2, Part 3, Part 4, Part 5 on “The Old New Thing”, a very good blog on Win32 programming. Raymond Chen also have a book based on the content of the blog.
• IO and monads in Haskell Alex’s interest in functional programming language is growing lately. Don’t worry, you won’t need to understand monads to code in C³!
• Scala, I started hearing about this one recently on stackoverflow, Alex says it may be the closest sibling C³ may have due to its ability to scale (hence the name).
• The C standard, this reading is a funny one, because at work, Alex have a reputation to know the C++ standard by heart. I’m joking, he didn’t actually read the whole thing, but that doesn’t change what his reputation is!
• Development of the C language history of the ancestors of C³ is always an interesting thing.
• Types and programming language the next generation a good summary of the research that have been done in the field and where we are now. My husband is also thinking about buying a book from the same author, Benjamin C. Pierce.
• The next 700 programming languages written in 1966, but still actual. It describes the ancestor of ML, a well known functional language that later led to the development of Caml, OCaml and F#.
• Scripting: Higher Level Programming for the 21st century a recurring suggested reading from the guy that created TCL. He discusses the difference between scripting and system programming.
• The next mainstream programming language: A game developer’s perspective, written by the CTO of Epic, we especially enjoyed this one as it is very close to our own experience and put into words, things we had in mind. Still, I’m questioning the font choice.

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!

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.

We 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!

Isn’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.

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!

Oh here I am to my first « why I haven’t been writing » blog post. I received a comment today asking why I let the site down for so much time, so I have to give an answer at least. So I’m back from a long trip to Europe, which was wonderful. Most of our family, friends and coworkers found pretty weird that I decided to leave without my husband. We both had the same amount of vacation but we have different priorities, for him C³ is on top!

Summer has been a very busy time; because we live in the north, we have a very short period where we can actually work on the house and breathe non-frozen air. On the other hand, in the winter, there is nothing else to do other than cuddle, blog and write compilers.

So everyone rejoice, winter is back and we are also back on working on C³. I say we, but he actually did quite a bunch of things while I was away. He finished writing the PEG parser (now named IPG) and is now starting to write the generator. Also, he read a bunch of things that may have an impact of the C³.

The main discovery was LLVM, or low level vitual machine; some kind of assembly language but ultra portable. It features an amazing level of optimization and flexibility that makes it a very good candidate for a first back-end.

The book about the history of Commodore was an interesting read he says, but is probably more teaching about what not to do. I’m not sure if he did finish the book on ANTLR, a parser generator, seems it doesn’t match his need.

He is now reading Coders at Work. He really liked Founders at Work and is stimulated by those insider’s insights. Don’t be afraid to ask questions, it really helps me with my inspiration!

By the way, if you understand french, you can follow me on twitter and listen to my podcast !standard .

For the first time since the wedding I was away from my husband, we were both visiting our family for Easter. He wasn’t there to “brainwash” me about his project, but convinced me a few days before leaving to read The Design and Evolution of C++ by Bjarne Stroustrup.

The motivations behind C++

I’m just starting chapter 2 (which is the third one, the first being chapter 0 of course). I found out that the motivations to create C++ were founded on this love-hate relationship he had with Simula, BCPL and others. Even though he doesn’t want to compare his creation to other modern languages, he doesn’t hesitate to criticize vigorously those he used before. Here are some excerpts: Pascal gets no love, but it isn’t clear about the others.

“I had found Pascal’s type system to be worse than useless – a straitjacket that caused more problems than it solve by forcing me to warp my design to suit an implementation-oriented artifact.
(…)
The feature of Simula were almost ideal for the purpose, and I was particularly impressed by the way the concepts of the language helped me think about the problems in my application
(…)
The implementation of Simula, however, did not scale the same way. As a result, the project came close to a disaster. My conclusion at that time was that the Simula implementation (…) was inherently unsuitable for larger programs. Link time for seperatly compiled classes was abysmal (…).

BCPL makes C look like a very high-level language and provide absolutely no type checking or run-type support.
(….)
I swore never again to attack a problem with tools as unsuitable as those I had suffered (…).”

Different state of mind, different languages

Some languages, like lisp, are creation of design and purity. These are interesting for the intellectual stimulation, but rare are the people that use them in real life (or happy to do so). Like a nice, but small, canvas in which you can only express a part of yourself. After all, lisp was design to express mathematical concepts and not to communicate with a machine.

There are also the “design by comity” languages. Composed by a team of designer, based on compromise, the result is a hybrid between different style. Having keyword for mostly anything is a big sign of design by comity because it is easy solution for a group of people to agree on. Usually the result can do a wide range of things but doesn’t perform well in any of it. COBOL and ADA are two examples, I don’t know anyone who have a really positive opinion about those.

I have the feeling that real life experiences forge language design oriented toward well… real life. When you have to face a wide variety of problems, went to the limits of your favorite languages, you develop a devoted love for the good things, and a growing frustration for those itches, especially if you have an idea on how to fix them. Programming language designers that falls in this category tend to create stuff people are more inclined to use (or love using).

My own love story

Under my last post, my friend Michel’s comment was right. I am very harsh against garbage collection, and virtually everything counter performing. This is probably a professional deformation. After a few years coding with performance as a priority, it’s hard to quit. In fact I don’t want to quit, this has made me a better programmer.

My first serious experience with code was with C++. It wasn’t an easy gal, took a while to master the basic concepts. What really hook me up was the wide range of possibilities. I had frustration with the sometime non-intuitive ambiguous syntax, with the compiler’s bugs and performance, with ugly Microsoft stuff like MFC or COM; but I never felt limited in anyway. Controls, physic simulation, graphic, AI, photo processing; I went deep down many of those and the only limitation was the time I had to code. Would it have been easier to use, I would probably spend more time thinking, less time coding. But I still prefer flexibility and control over ease of use.

I loved my experience with Java when I was at university, easy to learn, quick to make simple stuff. But when I got into more serious programming, it couldn’t match my needs. I had outgrown the language. Mostly the problem was performance and control. But I also had some design interrogation, for example: why do I have to make a class even when it’s not the right design?

I always had a passion for assembly and down to the metal languages. You totally have the right to judge me crazy on this. I’m not sure why I love them so much. I agree with their reputation, hard to master and it takes a lot of time to do something with it, no matter how simple. They are extremely non-portable, hence I learned a few: x86, Motorola 680×0, but my favourite was VHDL. Programming directly the controller behaviour, managing directly the electric current, how much closer can a programmer get to the machine? You know you are low level when you have to manage the impact of the laws of physics on your program. While doing this slow pace programming, I developed an unconditionals love for the machine and its complexity. I now must reassure you, my husband is not as crazy as I am!

Impact on the C³ design

My huband programmer love story with C++ went a lot farther than me, metaprogramming with templates and stuff like that. The C³ design doesn’t compromise on performance for the exact same reasons that Stroustrup had when building C++. Similar background, similar conclusions.

Having multiple paradigms is probably the only way to allow programmers to fully express themselves. Like he said, each paradigm has its part to play, but it is their combination that really make thing lift off. Supporting a wide range of styles doesn’t have to make programming difficult. Nice design, behavior that default the correct way (that can get overridden should you need), simple and clean syntax: many elements that can give birth to something as easy as java to use (even easier), but as powerful as C++. Although, easy on the user side doesn’t mean easy in the compiler implementation.

Easy for me to say all this, nothing of this truly exists yet. But when we talk about it (everyday, even in bed before sleeping), I feel he thought of everything, now polishing on aspects I wouldn’t have imagined. I’m not usually easy to impress, I challenge him on every aspect I learn about. I hope this will help improve things. Unlimited passion… all this because we love and hate our programming languages. I feel my relation with C³ is going to be a wild one!

or Why value-based programming is not a bad thing!

Working on values was implemented in C++ to maintain compatibility with C. Bjarne Stroupstrup also invented RAII, a method that ensure that resources are acquired correctly, and also properly released. This is more intuitive to beginners, and honestly, this is what we want to do most of the time; keeping pointers for when we really need them.

Values and references both have their uses and patching the nonexistence of value-based variables with a garbage collector makes your programs slow and less predictable. Even with the optimization made to garbage collection algorithms and the increase of computer performance, many applications need to minimize overhead and cannot afford to lose on something that can be done at compile time. There is also the predictability of a garbage collector. The ones I worked with had a non-deterministic nature, the memory gets cleaned up, but it’s hard to know the exact moment. Sometimes life depends on a program, some applications in space or health care cannot afford randomness. Serious programming often requires performance and predictability. It will be possible for someone to add the possibility to use a garbage collector, but it shall not be a necessity in C³.

Anyway, garbage collection doesn’t make your program leak proof, if you make some complex cycles (a pointer pointing on something that is pointing to the original), chances are that it won’t be detected, leaving a nasty leak while the programmer have been used not to care about those things. There are so many things other than memory that has to be managed, memory doesn’t have to be a special case. Examples: network connections or OS resource handles . Why assume the programmer is an idiot that needs to be protected from herself? Good design doesn’t prevail by limiting control, especially in a creative tool like a programming language.

The solution is to make the use of objects, both as value or reference, easy for general application and leave the door open for a meticulous management. Using value-based programming is easy in C++ and will continue to be in C³, thanks to RAII. Using pointers in C++ have a reputation of being complex, but it becomes an easy thing if you are using smart pointers. Most of the time, there is two ways we want our pointers to behave: non-copyable pointers, and reference-counting pointers. Non-copyable pointers simply disallow multiple pointers to the same object. Reference-counting pointers keep track of the number of pointers to the same object. Both know when the pointed object is no longer necessary and deletes it at this moment. No need for complex manual management! Another example is a clone pointer that makes a copy instead of pointing to the same item when copied. Other more custom pointers could also be used. This is where the serious programmer is free to push thing down to the metal.

Having smart pointers being part of the language standards allows making other simplification for the user. In C++, not redefining constructor, destructor, copy constructor can be a dangerous thing if your class contains pointers. But in C³, the default behavior will most probably be the one you need because the type of pointer you use define its behavior in those situation. Basic language functions won’t return raw pointers (like C++’s new operator). Other operators could be generated automatically correctly, like operator==, which isn’t the case in C++. My husband recently answered this question after seeing it on stackoverflow.

Why don’t C++ compilers define operator== and operator!= ?

IMHO, there is no “good” reason. The reason there are so many people that agree with this design decision is because they did not learn to master the power of value-based semantics. People need to write a lot of custom copy constructor, comparison operators and destructors because they use raw pointers in their implementation.

When using appropriate smart pointers (like boost::shared_ptr), the default copy constructor is usually fine and the obvious implementation of the hypothetical default comparison operator would be as fine.

So this is how memory is never stack as a pile of garbage, waiting for another process to collect it. It just manages itself in a very easy way and the serious programmer continue to be free to invent new ways to manage his pointers. Memory recycling itself without more efforts. The simple programs continue to be easy of implementation, and the programmer gets flexibility, performance and control for all possible applications.

Husband ’s note:
C++ “concrete type” facilities were only optimized for small objects that are cheap to copy.
C3 makes value-based semantics easy and efficient, even for more complicated objects.

In my last article, I posted a link to Joel Spolsky’s “In Defense of Not-Invented-Here Syndrome“. To justify modifications to a compiler is something technical that can be demonstrated in a non-subjective way. Creating your own programming language, can hardly justified the same way since there are so many languages already existing. Still I’m coming in defense of the language creation, mostly by describing my husband motivations.

The first motivation to any write any code for which you aren’t paid is fun, including compilers. If design is fun to you, there is nothing wrong trying to design a programming language. In fact, the exercise will make you grow up. Trying is the better way to learn, programming language design and compilers are two of the best ways to get down to the metal, into the deepest layers of the machine. Understanding how things work will always gives you a heads up compare to learning workaround by memory. This is true for programming, but also when learning English or French, or when operating a microwave (you can learn what not to put in it, and maybe forget, or you can learn how it works, and deduce naturally what is a bad idea to put into it.)

Still there is more about C³ than having fun. It sure began that way, but my husband has outgrown the educational purpose. It all starts with a dream of making the perfect language. Off course reality catches up, the more you program, the more you realize the complexity of the task. But the more you program, the more you see space for improvement. There is an amazing amount of programming languages out there, some are really good and we have a lot of respect for them, especially C++. But they all have a bunch little something annoying (sometimes big) which leave the door open for improvement and new discoveries. Closing the door would be a very sad thing for the sake of creativity, but pushing the limit farther: that’s an interesting challenge.

Identifying what doesn’t work is one thing, but thinking about an elegant solution is very different. Over the years, he had been collecting problems in languages he was using, each time challenging his design. But the good designer also has an eye for good design, even when it’s not own work. Experience is what shaped this dream into the refined reality of C³.

So here we are, he doesn’t intend to reinvent the wheel, C++ is a big inspiration in his work and those familiar to it should feel totally comfortable with C³. But he’s making it evolve, mostly by making the syntax leaner. This doesn’t make the language more restrictive. On the contrary, simplifying the rules will leave more space for innovation. Alongside come ideas to make the programming more comfortable with better tools and a dream of a more unified community of programmer (and somewhat of a plan on how to make it happen).

Back to the question, is this a Not-Invented-Here syndrome? Probably… But this is how evolution works right? If everything was perfect, there would be no need to improve it. Only the most innovative persons challenge the very basics of things.

So mostly that’s it, a programmer should start designing his own programming language for fun and educational purpose. Some people, like my husband, discovers along the way that the world could benefit from their innovative ideas and want to push further. There is a long way ahead to make this actually happen. Hopefully he isn’t alone, a wife stands by him!