Overview
Features
Download
Documentation
Community
Add-Ons & Services
The POCO C++ Libraries Blog

Archive: March, 2007

SD West ‘07

Filed under: News by alex at 00:33

Few words about this year’s SD West conference. The main reason I attended was to hear what Stroustrup and Sutter had to say about C++ future. Naturally, it was mostly about the upcoming C++0x standard. The most important topics were concepts (see this and this paper as well as ConceptGCC compiler implementation) and threading. Closures are much anticipated, but not so certain to actually make it into the standard. The reason? Dilemma on how to pass enclosing scope local variables – by value or reference. To pass by value (and are values themselves) is thread-safe and there is no concern for the variable lifespan, but what about a GB size buffer (or a pointer to local variable) being copied? If they are passed by reference, sharing in concurrent scenarios as well as lifespan are main concerns. So, all that being said, the jury is still out on it.
There were few other presentations during the two packed “S&S on C++ days”. Herb explained the hardware limits, memory walls etc. Bjarne gave an interesting presentation on use of C++ in safety-critical systems, such as Joint Strike Fighter (he was involved with it) coding guidelines and big marine diesel engines real time control. And then, few interesting topics such as how to mimic CPU pipelining in code (useful technique in some concurrent scenarios) and some not so interesting such as Visitor and Singleton in dozen incarnations, boost::any and boost::variant. The bottom line: well spent couple of days. I stayed an additional day to attend Chuck Allison’s sessions on templates (and actually learned a couple of things ;-), Kevlin Henney’s presentation on patterns and Fortify Software presentation on C/C++ security, where I got involved in an heated debate. Why? Because they did not present any C++ security issues – it was all C flaws. Yes, those are all part of C++. And also one of the reasons why C++ was created (and STL introduced) in the first place – so there would be an alternative way of doing things without backward compatibility and performance sacrifice. I objected to two things: (a) the session title and (b) advice they gave at the beginning: if you want to be safe stop using C/C++ and use … well, I’ll let the reader guess what ;-).

The Emotions of Programming Tools in one short Lesson

Filed under: Uncategorized by gerhard at 14:00

The last days I’ve thought about Alex Blog “The Economics of Programming Languages in one Short Lesson” and what is missing for me, especially with the bottom line “Put your language out there, make it free and open and trust the programmers. … Good programming languages will survive and thrive, bad ones will die. ”

But how are we deciding as individuals what is a “good” programming language ? Isn’t “good” for each of us different ? What is behind the rational concepts “freedom”, “openess”, “trust” – aren’t this emotions, feelings ?

I personally think that our emotions, drive the choice. An excellent presentation of Tom Asaker (http://www.acleareye.com/thoughts/VisualPresentation2006.pdf ) gives a clear insight to that.

“What matters is how you make them feel about themselves and their decisions while in your presence”. The emotions will drive the “good” or “bad” label. The rational arguments are only used for justifying the decision to the others (colleagues, management, …).
But how to create such emotions ? The Author prefer 4 steps to create those expectations.
1. Empathize it. What feeling can we deliver at what prize, such that our audience has a compelling reason to choose it and identify with it?
2. Create it. If you want them to notice you, you have to change things.
3. Dramatize it. Elevate it to a level that overcomes inertia like Habit, Switching costs and Search costs.
4. Demonstrate it to deliver on the expectations.

Take Java as an example. With the slogan “Write once, run everywhere”, the VM-Approach, the supporter bandwagon (e.g. IBM, open source projects, …) they have done it perfectly that way. Maybe they are lacking on demonstrating it in some application domains, but they have done a perfect marketing job as others with C#.

For me the bottom line is that – if you want to make your programming language a “good”, a “valuable” choice create positive expections in the brain of your clients or users. Please don’t get me wrong, I don’t speak here against the functional features of a language but I want to stress that those are only the coffee. The positive emotions are the cream, which makes the difference.
Beside choosing programming languages this theory can also be matched on choosing a framework like POCO.
Let’s make a short test.
1. What feeling attracts you to POCO ?

2. What feeling keeps you engaged with POCO?

3. What feeling will draw you away from POCO?

What do you mean ? I’m curious to your thoughts, comments, arguments, …

Dreaming in Code

Filed under: Uncategorized by alex at 19:22

The only reason I like to travel is being able to read, especially on long flights. So, Charleston, SC – San Jose, CA trip to SD West was a good opportunity to read “Dreaming in Code”. Good book. About OSAF‘s development of a PIM named Chandler. Unfortunately, not comparable with The Soul of a New Machine to which it is often compared. Why not? For the most obvious reason – The Soul of a New Machine is a story of hard work, strong leadership, good management and success. Dreaming in Code is, with all due respect to Mr. Kapor, a story of a management disaster that no amount of hard work could salvage. The Soul… is a “how-to”. Dreaming… is “how-not-to”. At one point, Kapor brings Al Gore in the conference room. Al Gore says: “I’m Al Gore. I used to be the next president of the United States”. And goes on, saying: “Keep up the great work! You guys are changing the world.” And then leaves the room. Go figure.

Other than the above annoyance, for which I see no importance whatsoever that merits a mention in a book, I was pretty much able to identify and agree with Rosenberg’s positions. So, let’s get to the book now. I have made notes of interesting quotes (author’s and otherwise) that appear in the book:

“choice of programming language often comes down to the arbitrary or the ineffable – a matter of taste or habit or gut sense”

Very much true. You can’t beat the gut sense. Some languages (and not just languages) simply “feel right”.

Michael Toy: “… the fools were paying me money to do what I would have done for free if only they had known.”

What true programmer can not identify with that? I mean, heck, we are all like that. Don’t tell anyone, but I’d do it for peanuts ;-)

Citing Peter Drucker: “Management is about human beings. Its task is to make people capable of joint performance to make their strength effective and their weaknesses irrelevant.”

Very true. What a contrast with a lack of leadership demonstrated in the Chandler project.

“There is no reliable relationship between the volume of code produced and the state of completion of a program, its quality, or its ultimate value to a user.”

“It takes a pretty alert and knowledgable manager to tell what software developers are doing.”

Absolutely true.

Citing Brooks: Tower of babel failed because its builders “were unable to talk with each other; hence they could not coordinate. When coordination failed, work ground to a halt.”

Good old Brooks, still accurate today as he ever was. Or is it actually the Bible that’s accurate?

MIT graffiti citation: “I would rather write programs to help me write programs then write programs”

POCO anyone ? ;-)

Abe Lincoln citation: “Give me six hours to chop down the tree and I will spend the first four sharpening the ax.”

Fits well with the above graffiti. AKA 80-20 rule: Do 80% of the work in last 20% of time. It’ll be done on time if you’re lucky. Otherwise, the release will be – well, late. Welcome to the world of software development.

“Reaching back to ancient Rome, Kapor proposed applying to software the architecture theorist Vitruvius’ principles of good design:
- firmness – sound structure, no bugs
- commodity – a program should be suitable for the purposes for which it was intended
- delight – the experience of using the program should be a pleasurable one”

All valid points, very much along the Christopher Alexander’s patterns (btw, that’s what I’m up to now – to finally read Alexander’s opus magnum). In theory. Implementation has obviously failed dismally. Essentially, the above are the elements of alive (I use the term “alive” here, Alexander calls it “quality without a name”) patterns, all applicable on multiple levels:

- user interface for the end user
- library interface for the application programmer
- programming language “interface” for the library programmer
- machine “interface” for the compiler writer, etc. ad infinitum

The main moral of this painful story comes in quotes from the interview Linus Torvalds gave to Linux Times in 2004:

“Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you’ll overdesign … If it doesn’t solve some fairly immediate need, it is almost certainly overdesigned … Don’t expect to get anywhere in any kind of short time frame …”

Or as Beverly Sills said: “There are no shortcuts to any place worth going”.

“It turned out that improving how you organize code was a cakewalk compared with improving how you organize people and their work.”

This really hits the essence of the project failure – the management issue. People are difficult. Leadership is important.

In the end, what to say about the book and the project it describes? It is a good book, bringing many important software development issues to the surface in the context of a real project. Essentially, it is a description of software development anti-pattern. Too many dilemmas and labor over them, to little decisions at critical times, to many direction changes, too many people came and left. It is disappointing to finish a book about a project with the project unfinished, but even if you didn’t know it before, somewhere in the middle of the book it becomes clear that this project will never be finished. And even if it is, it will be so late that it’s not likely to have any relevance. But, as it usually is, it may just so happen that something totally unexpected comes out of it.

BTW, have you ever dreamed in code? I do it all the time ;-)

std::cout << “YAWN!” << std::endl;
std::cout << “ZZZZZZ”;

The Economics of Programming Languages in One Short Lesson

Filed under: Uncategorized by alex at 22:47

I got tired of seeing the “Does C++ suck” title. So, I guess it’s time for new blog. I got tired of dumb radio stations on my way to work, too. I also get bored a lot working out in the gym. So, to kill the proverbial birds, I got myself an iPod Shuffle to listen to – books. It took me a while to master the art of cancellation of the external noise and now it works great – I hear anywhere between one half to a whole book a week. Recently, I was pointed to one of the Austrian School famous members, late Henry Hazlitt and his book Economics in One Lesson (also freely available online). The essence of the book is debunking the widely accepted fallacies about economy. These stem from taking into account only one social group in a short period in time, while neglecting the “big picture” – the overall, long term, impact of an imposed economic measure on the society. Communism is the prime example of how such fallacies can not survive. It has failed because it was too blatant and extreme to be sustainable long term. The fallacies have survived, though and keep on living, most obviously under the name “socialism”, but also very much present in western-type social democracy. And, although comunism is dead, things are not getting better. In essence, the idea behind the book is that economy does best when left to the laws of demand and supply to regulate it – it will optimize itself much better than any government intervention ever could hope to do. This is not to say that there should be no rules. Clearly, illegal activites are unacceptable and must be sanctioned. Immoral ones, if can’t be legislated, should and will be shunned. I can not do justice to Mr. Hazlitt here, so anyone curious about the idea should read the book – it’s a very easy and interesting read. Or, should I say “hear”?

Now, what does Hazlitt and Austrian School have to do with programming languages, one may ask? There’s something there. Programming language author (or, where applicable, standard body) is a “government” of sorts, setting the rules. Just like the government’s involvement in regulating the economy, programming language author(ity) should not get in the way of accomplishing a goal in the most efficient manner. That’s where the art of programming language economy is. That’s why as much freedom as possible in a language is good. Eventually, the programming community establishes a set of guidelines and best practices for optimally safe and efficient code. The cry “but you can do so and so in language X and people do it and it’s dangerous” is heard all the time. Certainly. You can also jump from the nearby bridge. It doesn’t make the bridge bad. Most people use it as intended – to get quickly and efficiently somewhere they need to be. It’s true that some folks jump from it. Yet nobody proposes to tear the bridge down and switch back to ferry-boats. Well, just like in economy and the bridge above, without looking at big picture, some folks jump (no pun intended) to conclusion that, due to some inappropriate use, feature X is unacceptable and must, by all means, be banned. Hence, we must quick come up with the language that will prevent X from happening. And they come with, say, garbage collected language. Which, make no mistake, is a great thing. Except when it’s mandated. And especially when it’s done in such a way that object destruction determinism is lost. With such aproach, memory management becomes easier at the expense of resource (files, connections) management becoming more difficult. Resources have to be taken care of from outside, causing additional concern and breaking encapsulation. Why not treat programmers as intelligent people and give them means to do garbage collection while letting them decide when to use it, how to use it and when and how not to use it? And then, ah those endless discusions how language X is better and shall “kill” the language Y and everyone should ditch Y because X does Z in a much better way than Y. Again, focusing on a single language feature proves nothing else but exactly that – a single thing being done better. It usually comes coupled with some other thing being done in an inferior way (think speed vs. memory requirements, for example). The overall context defines whether Language X is really better. So, goodness of a language is not solely in its one feature, it’s in all the features as a whole plus in the context (application domain, available libraries, etc) of the language as well. It turns out that it’s a pretty complex issue. Left to develop freely, the best language shall win. The most serious interference and root of many evils are corporate marketing propaganda factories, promising impossible and misguiding people with the sole purpose of locking them into proprietary technology in order to suck their money in years to come. Since it’s not illegal but it certainly is immoral to lie, they are those that should be shunned. Don’t get me wrong, I’m a firm believer in free market and I don’t mind paying. I do mind being dishonestly lured into a cage and held there against my will, though. The bottom line? Put your language out there, make it free and open and trust the programmers. Some people will do stupid things with it. Some people will create works of great value. But, whenever possible, let programmers decide what they want to do and how. Bad things will eventually go away, good things will stick and we’ll all learn valuable lessons of what to do and how as well as what not to do and why. Good programming languages will survive and thrive, bad ones will die. General-purpose languages shall have broad application domain, specialized ones will have narrow one. And that’s the best way to optimize the economy of programming languages.