Older blog entries for mrorganic (starting at number 257)

I have a birthday coming up, so I decided to take a few days off from work next week. I need the break.

As an extension to the screed I wrote about COM, I considered writing in more detail about software components in general. But this topic really requires a book-length treatment, and is resistant to the usual "bad or good" comparisons. I disagree with most popular implementations of components (like COM), but the concept is sound enough.

Good programmers know when to use a given tool or approach; mediocre ones tend to blindly follow "the rules" regardless of their applicability to a given problem domain. I've met lots of shake-n-bake C++ coders who claim to know how to use the STL, but are then flummoxed when I demonstrate common algorithms like accumulate and reverse. Or they are completely in the dark about basic things like overloading operators.

This is why I always emphasize craft rather than art to my junior programmers. You want to be an artist? If you lack the basic craft, you'll be a crappy artist anyway. Learn the basics. Don't get fancy, and don't rely too much on wizard-generated code. If you don't understand what a given chunk of code does, don't fool with it until you do. Use (but don't abuse!) comments. Make sure you're solving a problem rather than a symptom.

It seems to me that the whole programming world worries too much about abstract methodology when we should be worried about simple, nuts-and-bolts stuff like code quality and readability.

Not much to report today: just keeping an eye on a newly-deployed piece of software and fiddling around with the new release of wxWindows. wxWindows has several MFC-ish design elements that make me grind my teeth (message and event maps, for example), but is admirably capable in other respects. It's probably the best cross-platform C++ toolkit out there (yes, even better than QT).

I used QT for a time a few years back, and was not impressed. The type system was (and remains) an ugly and breakage-prone hack, and forfeits many of the type-safety features that C++ brings to the programming table. Without that, you might as well be using C (in fact, C is preferable in many ways since it is far less complex than C++).

If you crave type-safety, a sane C++ environment, and target only Linux/Unix boxen, then you may want to consider GTKMM, a C++ wrapper around GTK. It's far more type-safe than QT/KDE, and is a more compliant toolset to boot (it uses STL and the standard C++ library where possible, rather than reinventing strings, streams, stacks, lists, and so on).

24 Sep 2003 (updated 24 Sep 2003 at 12:25 UTC) »

Something deeply weird is going on with Advogato today: I tried to post a diary entry, my browser "went away" for a number of minutes, and them Advogato advises me that the site seems to be broken. I look at the current diary entry list, and my name is there -- but no diary entry!

WTF?!?

berend:

COM is only "easy" in IDEs like Delphi and VB because an enourmous amount of effort has gone into making wrappers and wizards to take the burden off the programmer. And still the essential defects of COM remain: it's about the poor design of COM.

Think for a moment about the humble BSTR, COM's string structure. It's basically a length-prefixed wide-character array. This was done to make brain-dead clients like Visual Basic happy, but at the expense of breaking C/C++, which considers a "string" to be a vector of characters (narrow or wide) terminated by a NULL. And this picture is further complicated by the fact that the OLECHAR* type in C++ is often used synonymously with the BSTR, when in fact they're very different (OLECHAR* values are not length-prefixed). But the COM APIs (being poorly designed) cannot really tell the difference between an OLECHAR* value and a BSTR.

In C++ especially, you run into all kinds of initialization/assignment issues, as well as heap/stack problems, due to the muddiness of the OLECHAR*/BSTR distinction.

This is a core design flaw in COM. C/C++ are the primary COM languages (through ATL), and yet Microsoft crippled a core data structure to support weaker clients! (And don't even get me started on the horrendously-cruddy SAFEARRAY and related API).

When you say COM is simple, you're only partly correct. In concept, yes, COM is simple. But in practice, it rapidly degrades into the stinking mess you see today because the design flaws are right at the center of what COM is: BSTRs, SAFEARRAYS, and the standard marshaller.

23 Sep 2003 (updated 23 Sep 2003 at 18:21 UTC) »
cm:

What you're talking about is called metadata, i.e., data that describes other data. Most databases do provide some level of this (checking on the system tables will give you column information like type, size, etc.). However, you run into another problem: you need to describe your metadata somehow. Meta-metadata? Meta-meta-metadata? At some point, it becomes self-defeating.

The Unix Way (to which I adhere) is to provide mechanism, but not to dictate policy. This extends to databases as well; I like databases like Berkeley DB that just give you key/value pairs and leave the rest up to me. I can then either use in-code structures (structs, classes, or tables) to give form to my data; or I can use a markup language like SGML or XML.

Self-discoverable data structures are very complicated both in concept and execution, and lead to the chicken-and-egg problem I noted earlier: you run into a "set of sets" infinite regress where there is no ultimate set to describe all other sets. It's better to just lay down the law (algorithmically speaking) and say, "This is how my data looks; conform or be damned!"

We've been in database hell today. Up, down, up, down. My pager has been buzzing nonstop.

I shoulda been a farmer.

21 Sep 2003 (updated 21 Sep 2003 at 22:26 UTC) »
berend: As the author of the rant on the main page, let me respond. COM is a horrible botch by any measure. I have written C++ CORBA clients (using the TAO toolkit, which is excellent), and I guarantee you that writing CORBA is a hell of a lot cleaner and more consistent than COM/ATL. And with TAO, it's more performant and more secure as well. That's not bloviating, berend: that's a simple fact, and I can back it up with IDL and code samples. Care to take me on? (You'll lose, I promise you!)

You suggest that COM was a good idea originally, but technology has made it obsolete. I disagree. COM was never a good idea. It violates the KISS principle, is badly designed (it's a binary rather than a protocol message standard) and badly implemented (see my Registry rant).

COM sucks. It has always sucked, and always will suck. It was a bad, short-term solution that Microsoft forced everyone to accept.

Sun is evil. Need proof? Read this interview. Basically, Sun says that Linux is worthless as a server and that you should (quelle surprise!) run Solaris instead. Oh, sure, they're willing to use Linux-originated technology like GNOME, Evolution, and so on, but God forbid you actually run this stuff on Linux! You should instead give your hard-earned money to Sun, who needs it far worse than you do.

Sun will take the work and sweat of thousands of open-source programmers (almost all of whom were using Linux to develop the software in question), incorporate it into a slightly-modded "Java Desktop" (little of which is actually written in Java, by the way), and sell it at a profit without acknowledging the people who enabled them to get there. This is an amazingly uncool thing to do.

Now that Bill Joy has left Sun, any remaining geek-cred they used to have is now gone.

19 Sep 2003 (updated 19 Sep 2003 at 17:08 UTC) »

Ah, the pleasures of pre-release code. It makes me glad that I now do limited-release betas before final release: we caught two potentially serious bugs and one formatting irritant that, while minor, would have led to a firestorm of bitching by the users.

With any luck, I'll do a final release early next week.

Oh, and: Avast, ye scurvy dogs! Batten the hatches and hoist the Jolly Roger! Grog and hardtack to all, me hearties! Yarrr!

Some interesting news from Borland about their new C++ tool: CBuilderX. The IDE is Java-based, the VCL seems to be missing in action, and it's unclear at whom this tool is aimed. Embedded developers? System coders? Who?

As a longtime user of C++Builder, I am decidedly ambivalent about this change in direction. I never much cared for the Visual Control Library (VCL) -- it was an Object Pascal library, written for Delphi, and shoehorned into C++ via some really nasty hacks and compiler extensions. The C++Builder IDE (also the same as Delphi's) leaks memory and crashes at least twice a day. And don't even get me started about the various database technologies Borland has adopted and abandoned over the years: BDE, ADO, IBX, DBExpress (although the last may survive into the new product).

For all the problems C++Builder had, it was a good RAD tool -- you could quickly get a GUI database app and running, much faster than you could with, say, Visual C++. And now it seems that Borland has made the decision that C++ is no longer an appropriate RAD tool -- if you want RAD, you will have to use Delphi (or whatever .NET incarnation of it comes along).

What concerns me about this new product is that, for the money, it doesn't bring much to the table. You get a bloated and slow Java IDE, huge resource requirements, no GUI builder, etc. Borland is intending to use wxWindows as the GUI library, which is a good thing (it's a good cross-platform GUI library, if a bit too MFC-ish for my taste); but there's no GUI builder, and even if one appears, it probably won't support VCL-to-wxWindows conversions -- the differences are probably too great. So you don't have much backward-compatibility either.

It seems to me that with a copy of EMACS, GCC, and wxGTK, I can do the same thing Borland is offering -- only I can do it for free.

Lots of discussion on this topic here.

248 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!