Monthly Archives: April 2009

Tough love: the programmer love-hate relationship with her languages

The Design and Evolution of C++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).toughlove

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 C3 design

My huband programmer love story with C++ went a lot farther than me, metaprogramming with templates and stuff like that. The C3 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 C3 is going to be a wild one!

The value of values

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. c3wifegarbage

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 C3.

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 C3, 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 C3, 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.

Is creating a programming language an extreme form of Not-Invented-Here Syndrome?

c3wifereinventingIn 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 C3 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 C3.

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 C3. 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!