Jeff, I agree in principle that simple is better, but I think a few of your examples are way off.

x86 architecture (crap or otherwise) is VERY complex compared to a RISC architecture. It happened to win out in the marketplace because the suppliers of RISC architectures (DEC, HP, Sun, SGI, etc) were never interested in the consumer market. Intel, meanwhile, kept increasing complexity in order to maintain backward compatibility (remind you of Windows?), thus solidifying its market share.

The reason we abandoned INI files in favor of the Registry was because they were too simple to be useful and because the parsing API did not make it easy to add complex functionality. Registry solved that problem but introduced others that you mention. XML is not necessarily simple (think about what it takes to parse it) but the tools are now in place that make it simple, so the Registry no longer has an advantage.

COM. COM is not more complex than Web Services. Again, its just that the tools for developing Web Services are much nicer than the tools for doing COM. That, and the fact that Web Services are much more open than COM and give you better interop opportunities.

Thanks for your comments.

I think x86 vs. RISC is still firmly in the camp of "worse-is-better" vs. "the-right-thing". Clearly x86 is worse than RISC from a technical standpoint, but it has triumphed for other more practical reasons (eg, implementation).

"COM is not more complex than Web Services"-- is this a serious statement? I know people far smarter than myself who struggled with COM for years. On the other hand, the concepts behind Web Services can be grasped in a day by the most average developer.

Good point on the .INI file-- and I agree that XML parsing is a lot of overhead-- but I think the general theme of "plain text" vs. "complex proprietary binary format" is still a valid illustration of how simplicity always wins in the long run.

In my opinion x86 succeeded through marketing and positioning, not implementation.

COM is simple in principle but for quite a while remained very complicated in implementation. Consider what VB6 did for writing COM components. ATL also made it easier to write COM components in C++. Don't forget that .Net Framework was originally planned as COM+ 2.0.

I never understood why people think COM objects are complicated. I have a friend whom I hired as a Delphi programmer whose first task was creating a COM object to do some processing (our company mainly writes COM - not even COM+ - objects for a living). He started writing the COM object in his first day, and I had to specifically warn him "at some point, you will read some article on the web talking about how complicated COM objects are; ignore that part, it's because they are writing them in C or C++".

"...the concepts behind Web Services can be grasped in a day by the most average developer" -- here's how I explained the idea of a COM object: "it's like a regular Delphi object, except that it derives from TAutoObject and you use the type library editor to add/modify methods and properties". That was all he ever needed. Sure, basic level stuff - he never wrote aggregated objects or custom factories - but on the other hand, 95% of our projects don't need those.

It's like saying "programming with windows is incredibly complicated". Sure, the first program I saw (for Win 3.11) that actually created a window with a button on it had 80 lines in C. Tools have advanced a little since then; trying to write a SOAP-compliant web service in K&R C would be quite a difficult task.

I figured it must have been an April fools thing.

- "COM is not more complex than Web Services"...
- "I never understood why people think COM objects are complicated"

It MUST be an April fools joke. These comments must have been changed to appear they were from the past. Did you use GMail Custom Time somehow?

http://mail.google.com/mail/help/customtime/index.html

I don't agree that the New Jersey solution was better from the way it is presented. The way I look at it, you can handle that condition once in the OS, or thousands of times in applications all over the place. Which is simpler? How many times will you have programmers who are new to the environment who will not put that check in? Or forget? Or maybe the required check may be different in a future release requiring changes to how many programs?

I do a lot of iSeries (AS/400) programming. It is common to see date format routines written in different programs scattered all over the place. Someone needs to convert a date, easy enough, I'll write a conversion. I'm used to PC programming and using standard libraries so my first inclination is to write a standardized implementation and start pointing those programs to them instead.

For me this is "right" because if there is a problem or a new format is desired, the change required is minimized. Most dates I see are still handled as decimal or packed fields even though a date type has been available for years. Ever wonder why Y2K was such a pain on midrange and mainframe systems?

The simplicity here should not be letting the OS developer be lazy at the expense of the app developer. It should be to minimize the effort to handle a condition. And the way to do that is handle it in one piece of code in one place (in this case, the OS).

Any idiot can make something complex. It takes genious to make it simple. But applying the wrong solution just because it's simple is cheating, and it will come back to bite you.