Those who know how to do …

… do, those who don’t – teach.

Believe it or not Scott Meyers is a poster boy for the second half of the above statement. He is also the first person that made me think about it in a serious, positive and equal-to-the-first-half sense. Whether he knows how to do, I don’t know. But I don’t think anyone would dare to deny Scott due credit for his work – it is safe to say that the guy is top-notch, world class, one of the few, in what he does. Yet, he confessed recently it’s been decades since he has written a line of production code. And no, it was not in C++. I know you are surprised. I was, too. At first. Then I was relieved because I have realized why I read Scott’s books and attend his seminars, not the other way around. I am from the first half of the sentence. Since my employer keeps on handing me magic green pieces of paper which I am skillfully converting into useful stuff like bread, butter and air-conditioning, it must be that I am from the first half. And since “In God we trust, everyone else pays cash”, I’m really happy for it ;-).

But, I do not want to talk about Scott or myself. I want to talk about Poco – a top-notch creation in the first-half sense (although second-half application should not be excluded – I heartily recommend it to universities if they really want to teach students how to make software properly). There is a lot of pragmatic sense in Poco for things that, well, make sense. And that matters, especially in C++ and real world (AKA “production”) domains. From my personal experience in the last year and a half, Poco is made by folks who know how to do. My contributions are really small compared to the overal size of the framework, but I am nevertheless proud to be a part of it. Anyway, how does the Fair and Balanced Poco Dictator keep our Favorite Framework Kingdom a great place to live and what exactly is it that makes us love it more than other frameworks out there? For one thing, there are no re-invented wheels in Poco. At least not non-round ones. std::string is thy string and thou shalt have no other strings. STL does a pretty darn good job at containing things and iterating over them, so use it, rather than trying to parallel it. Regular expressions, compression, xml parsing, … have been conquered by some folks long time ago. Stand on their shoulders rather than your users’ toes. Also, it’s nice that all parts have the same “look and feel” to them.

To be completely fair and balanced, there are missing parts (see project ideas) and not all things Poco are as shiny as they could be, but once rare rough surfaces are spotted and pointed out, they are quickly and efficiently taken care of. Util::Application options are the most recent example.

So, let me conclude with a provoking thought based on article from the second-half poster boy. Not exactly the most recent stuff, but actual nevertheless and it made me think – there may be some classes in Poco with too much interface and I myself am guilty for some of them. Would it make sense to think of pulling out some existing non-member functions (DateTime and Timestamp numerous operators come in mind) and also considering NMF in future where it makes sense? It may seem like a heresy at first, but it would make objects lighter and enhance encapsulation which may make it a worthwhile endeavor.

Comments welcome.