Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Are new programming paradigms ready for prime time?

By ucblockhead in Op-Ed
Fri Feb 09, 2001 at 07:29:14 PM EST
Tags: Software (all tags)
Software

I've come to hold the opinion that much of the exciting new programming paradigms are simply not ready for general use. What follows is mostly a general rant about one of them.


Development tools are supposed to make our lives easier. They are supposed to allow programmers to concentrate on the algorithms and on the project while not having to worry about the low-level stuff that people have done before. At the root, that's what it is all about. No duplicated code. No reinventing the wheel.

If we go back to the conceptual beginnings of programming, people saw programs as autonomous units. Each program was essentially written from scratch. People quickly recognized that this was inadequate because of the repetition involved. There were two sorts of repetition. There was repetition in basic programming constructs, like loops and such. There was repetition in higher level algorithms, like sort routines, device handlers, and such. I'd submit that nearly all of computer science since has focused on removing those sorts of repetition.

The first sort of repetition is usually attacked with higher level languages, and that effort has largely been successful. The second sort has been more problematic.

Programmers have recognized since the beginning that they often ended up writing nearly identical code over and over. Solutions have appeared over and over. Functions in libraries. Functions in dynamic libraries. Classes. Classes in dynamic libraries. Components. Now each of these things is a good idea, but somehow, none of them have ended up solving the problem.

Where my frustration comes in is that increasingly, these new ideas bring in a lot of baggage. I often feel like I've traded a set of well-known problems for a whole new set of problems. I've especially found this with two very well-known technologies, C++ and Microsoft's COM architecture.

Of the two, COM's the one that's caused the most issues, so that's what I'm going to talk about. Basically, I find myself spending much of my coding time trying to get the technology working, rather than worrying about my actual algorithms, which is really all I should have to worry about. In many, many ways I find myself travelling well-known paths, doing what I'm sure lots of other coders have done before me. The algorithms I write end up being reusable, but paradoxically, many of the technologies used to create them force you into reinventing the wheel.

A good example in COM is the way you essentially have to reimplement basic reference counting in COM if you are doing it at the lowest level. Now, that's just damn silly. It would have been trivial to include.

Now this is a recognized issue, and Microsoft has attacked it with the Active Template Library. Now, the ATL appears nice at the beginning, especially when using the wizards. But wizards are a suckers-game. They appear nice because you can just click-click-click and get something that works. Cool! The trouble is that they insulated you from what you are doing. You end up writing code that you don't understand. This causes disasterous problems in two areas. First, if you have some sort of problem, you often end up high and dry, with no clue about what is going on. Worse, what is going on is being deliberately hidden from you. Second, if you are in a situation where the wizard won't work, for example, you are trying to add functionality to an existing product, you often end up without much clue as to where to go. Worse, all of the documentation assumes that the wizards are used, leaving the guts of what is going on completely and utterly undocumented.

A real world example: In my current project, I've got an existing application that I need to make into a sort of plugin so that other people can use it. I've got to do two things. I've got to be able to get commands in, and I've got to pass event data back. Now this is not at all hard conceptually, and I'd argue that if it is not hard conceptually, it should not be hard programmatically. Unfortunately, this is not at all the case.

Doing this in straight C or C++ would be trivial. Create a DLL. Add some entry points. Pass back function pointers. I could have easily written the code in a day. But instead, we are using this new, advanced technology of COM that is supposed to make this sort of thing easier. Does it?

No, not at all. In fact, it has taken me three, maybe four man-weeks to get the thing working. Why? Well, not because I don't understand what I want to do, obviously. Instead, I've spent the last few weeks wrestling with utterly confusing, contorted, undocumented code. I've only been able to solve my problems by literally debugging into the ATL library code. That is just not acceptable.

Now someone is going to pipe up and say, hey, that only takes ten minutes with the wizards! Well, yeah, but the trouble is, the wizards don't work with existing code. Yeah, I can get a silly little sample program working in ten minutes. What I need to get working is a live application that is already out there in the real world.

What we've got is an evil confluence of two technologies that while interesting, make actual use a nightmare. The ATL is a template library, which is in many respects the fancy C++ version of macros. Then, not to be outdone, Microsoft has gone nuts in i ts use in old-style C macros. They also make massive use of multiple inheritance in C++. The end result is that you, the poor coder, have absolutely no clue as to what is going on.

All of these things combine to make wildly cryptic error messages. As an example, look at the following line:

SINK_ENTRY_EX( 1, DIID_DFooEvents, 1, OnFoo )

This gives the following errors:

C:\Progs\Foobar.h(51) : error C2440: 'static_cast' : cannot convert from 'class FooClass *' to 'class ATL::_IDispEventLocator<1,&struct _GUID const DIID_DFooEvents> *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast C:\Progs\Foobar.h(51) : error C2440: 'initializing' : cannot convert from 'void (__stdcall FooClass::*)(void)' to 'long'
Conversion is a valid standard conversion, which can be performed implicitly or by use of static_cast, C-style cast or function-style cast
Foobar.cpp
C:\Progs\Foobar.h(51) : error C2440: 'static_cast' : cannot convert from 'class FooClass *' to 'class ATL::_IDispEventLocator<1,&struct _GUID const DIID_DFooEvents> *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast C:\Progs\Foobar.h(51) : error C2440: 'initializing' : cannot convert from 'void (__stdcall FooClass::*)(void)' to 'long'
Conversion is a valid standard conversion, which can be performed implicitly or by use of static_cast, C-style cast or function-style cast
Foobar.cpp
C:\Progs\Foobar.h(51) : error C2440: 'static_cast' : cannot convert from 'class FooClass *' to 'class ATL::_IDispEventLocator<1,&struct _GUID const DIID_DFooEvents> *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast C:\Progs\Foobar.h(51) : error C2440: 'initializing' : cannot convert from 'void (__stdcall FooClass::*)(void)' to 'long'
Conversion is a valid standard conversion, which can be performed implicitly or by use of static_cast, C-style cast or function-style cast

Why? Well, it is obvious, isn't it! I mean, really...

Seriously, you get that, because you derived the class with this inheritance:

public IDispEventImpl<0, FooClass, &DIID_DFooEvents, &LIBID_FOOLib, 1, 0>

so that original line should have instead been:

SINK_ENTRY_EX( 0, DIID_DFooEvents, 1, OnFoo )

Now it is just obscene that such a minor error should cause such wildly cryptic error messages. A compiler should help the programmer, as in "Syntax error:unexpected ';'". The above is little better then "Error, something's wrong, you figure it out".

And that, really, is the whole problem with so many of these new technologies. The ideas are good. The theories are good. But the designers get so blinded by the theories and the ideas that they forget that someone has to use the damn things.

The KISS principle ("Keep It Simple, Stupid") is well known, but somehow most forgotten when we write tools for ourselves. And what is unfortunate is that we, as programmers, are often not able to truly choose our own tools because of market forces. As mentioned before, I'd probably just as soon just do a damn DLL with callbacks, but because of the way the market has worked, you've got to use the new technology. If you want to interact with IE, you have to use COM. Be a control, gotta use COM. Rather then get the technology right, really right, and then incorporate it, too often vendors (and no, Microsoft is not the only offender, just one of the worst) rush it out in a half-assed, ill-thought-out manner and then force you to use it to deal with their stuff.

And then when the problems become apparent, too often the fix is not to go back and get the stuff they put out working in a more friendly fashion, but rather, to come up with a new technology that will make everything perfect and simple. Unfortunately, that's what is said about every new software technology, and somehow it never comes out in practice.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
We should...
o Jump into new programming paradigms immediately 39%
o Wait for vendors to get new ideas right before using them 60%

Votes: 28
Results | Other Polls

Related Links
o Also by ucblockhead


Display: Sort:
Are new programming paradigms ready for prime time? | 54 comments (47 topical, 7 editorial, 0 hidden)
this is why i like java (3.12 / 8) (#4)
by rebelcool on Fri Feb 09, 2001 at 01:04:31 PM EST

the error messages, though occassionally inaccurate, are fairly descriptive in java. You also dont have all the silly STL, ATL things. I think c++ is quickly becoming obsolete... the more advanced things we're trying to make it do only make it more complicated and harder to understand when things go wrong. Error reports in Klingon would probably be just as descriptive as some of these things.

COG. Build your own community. Free, easy, powerful. Demo site

C++ is not MSVC++ (none / 0) (#43)
by codemonkey_uk on Mon Feb 12, 2001 at 08:02:52 AM EST

And MSVC++ is not C++

C++ is no where near becoming obsolete ... show me one peice of solid evidence that c++ is in decline and I'll show you 5 that its use is on the rise.

The STL is great. Your vendors implemlentation of it might not be.

ATL is not part of C++ ...

Error reports are the vendors problem.

And so on and so on.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

True (none / 0) (#44)
by ucblockhead on Mon Feb 12, 2001 at 12:44:55 PM EST

That is definitely true, and it makes it all the more frustrating to know that there are better implementations out there.

We've had to dump the MS version of the STL in favor of the SGI version because of bugs and incompatibilities.

There's lots of little ways that compilers can help or hinder the programmer. One great example is the old missing #endif error. It is an easy mistake to make. VC++ reports this error as an error at the end of the file, which is basically useless. The coder is forced into manual #if/#endif pair matching. gcc, on the other hand, reports the line of the unmatched #if, which usually makes it trivial to discover the problem. Just one way were a very little difference can make the coder's life much easier.

The biggest problem I've seen with the STL in general is that I've yet to see adequate docs for it. The learning curve is very steep, not because most of the concepts are hard, but because the syntax is somewhat arcane, and there are few docs available. I've yet to see a decent book on it.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
The ugly template rears its foul, fanged face (4.20 / 5) (#5)
by Anonymous 242 on Fri Feb 09, 2001 at 01:07:37 PM EST

FWIW, anytime one works with C++ templates, the error messages turn out verbosely cryptomatic like your error. This is true of gcc working with the STL and Sun's Visual Workshop with Rogue Wave's template library. I'm not all that surprised to find it is also true of msvc.

Perhaps errors should be better in an ide like Visual Studio, but technically the errors are telling you exactly what the problem is.



Templates (4.50 / 2) (#6)
by ucblockhead on Fri Feb 09, 2001 at 01:28:53 PM EST

Yeah, templates were supposed to replace C macros, but I've found that they end up having a lot of the same problems. They have a tendency to hide the actual code which is why you get error messages that are wildy confusing (if, as you say, technically correct).

Really, in my mind the point of the error message should be to be technically correct, it should be to point the programmer in the direction of the mistake. After all, that's the whole point of dev tools right? To make our lives easier.

And I don't think it is a matter if simply learning the tools. I've been doing C++ coding since, literally, 1985. I've got more experience then virtually anyone. And frankly, when I read books like Effective C++ where the experts in the field often appear unsure as to how to do things, well, you gotta wonder...

I've run into much the same problems with the STL, as you say. In particular, we ran into a nasty memory leak situation that was near impossible to debug, mostly because the code in question was buried in all kinds of template crap.

Maybe I should have rewritten this thing differently, focusing on templates in general. Still, templates aren't the only area where I've seen this. And, in fact, another poster mentioned Java, which does indeed solve some of these problems, but IMHO brings in a raft of others as it is, as well, a new idea not entirely well implemented. I'd rather have the old ideas implemented well.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

a combination would be good (3.00 / 1) (#9)
by rebelcool on Fri Feb 09, 2001 at 01:34:11 PM EST

something with the linguistic characteristics of java (remember..java was built to be OOP..c++ is OOP tacked on to c) to make writing it a bit less painful, but with the flexibility and speed of C.

Then again, with many of these absurd template structures, and with java runtime and compiling technology advancing, the speed gap between the two is quickly narrowing.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

templates.... (4.00 / 1) (#16)
by your_desired_username on Fri Feb 09, 2001 at 02:29:15 PM EST

hm.. I can't claim to have your experience. I have only been coding in C++ since 1995. Yet I feel that templates *save* me a lot of trouble, despite weird error messages and incomplete compiler support. I cannot count the number of places a template has enabled me to write one line code instead of ten.

I have found templates to be a good tool for changing run-time errors into compile-time errors (compare libsigc++ slots and signals to gtk's slots and signals) - and I would rather have a compile time error than a run time error, even if the compile time error is cryptic.

Perhaps I am weird, but think templates are c++'s best designed feature, and I find them easier to use than c++'s polymorphism.

[ Parent ]
One line of code... (4.00 / 1) (#18)
by ucblockhead on Fri Feb 09, 2001 at 03:10:22 PM EST

Too often, though, I've found that it takes me far more than ten times as long to write that one line of code!

In many ways, I think templates are a good idea in theory. I just don't think the implementations are good. Once I figured out how to get some of the data structure templates worked, I began to love them and they can allow for some very elegant code. But I still run into massive, confusing wierdness from time to time that quickly sucks any time-saving down to hell.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
The point of templates (4.50 / 2) (#28)
by SlydeRule on Fri Feb 09, 2001 at 09:24:31 PM EST

templates were supposed to replace C macros
Not at all. The C macros are still in C++; templates aren't a substitute for them.

The point of templates is to allow genericity. The most common application of this is in the production of type-safe containers: lists, sets, dictionaries, etc., and their associated cursors and iterators. Without templates, whenever someone wants one of the contained items, you end up returning a (void *) and letting the caller cast it to whatever he thinks is the correct type. In contrast, a template can return a pointer (or reference) of the correct type.

Templates also allow you to create containers of primitive types (int, double, etc.) without having to create separate wrapper objects for the stored items.

Template functions (as opposed to template classes) allow the description of algorithms in a type-independent manner.

Templates are more restrictive than macros. The body must be either an entire class or an entire function; not an expression, not a code fragment. Each template parameter must be either a type or a value; not an arbitrary string.

On the other hand, templates are more efficient. Whereas a macro is expanded in-line each time it is used, a template is expanded as a separate linkable entity (class or function). The compiler and linker guarantee that only one instance of a particular template expansion will be included in the resulting executable file, no matter how many times it's referenced.

[ Parent ]

Preach on brother!! (3.00 / 9) (#8)
by spacejack on Fri Feb 09, 2001 at 01:33:02 PM EST

Basically, I find myself spending much of my coding time trying to get the technology working, rather than worrying about my actual algorithms, which is really all I should have to worry about.

Exactly. That's all I have to say.

The Abstraction Distraction (4.00 / 7) (#10)
by lmnop on Fri Feb 09, 2001 at 01:38:15 PM EST

I feel your pain, though in different places. I'm a Sys. Admin. and I have to deal with trying to install, maintain and troubleshoot various Internet-related software packages (template engines, webservers, the usual stuff).

<rant>
Each product seems to have its own names for the same thing. Documentation is reading more and more like marketing speak if it's provided at all. The creators of the software seem more involved with telling you how interesting their idea is than with how to use it practically, or use it at all, or get it running.
</rant>

If I have to read another meaningless flow chart I'm going to punch a nun.

I have to remind myself that much of the stuff I deal with is new-ish (like Tomcat, SOAP, XML), and it's still under active development. I just get tired of absorbing.

By Monday I'll think it's all cool again and be thankful I'm being paid to play with new technologies.

What it seems to come down to is some abstractions are better than others (the UNIX notion that everything is a file is a good, simple abstraction).

OK. I'll stop complaining now and go earn my paycheck.

-lmnop
"If all else fails, immortality can always be assured by spectacular error." -- John Kenneth Galbraith
Microsoft programming languages/tech sucks (2.57 / 7) (#12)
by delmoi on Fri Feb 09, 2001 at 01:57:08 PM EST

I have no idea why, but everything M$ comes out with as far as APIs seems to suck ass! Com is a huge pain in C++, but in VB it's easy... of course, VB itself sucks. C# will be an improvement, but I'm sure Microsoft will find a way to screw that up as well.

If you ask me, they just should have modified the VC++ compiler to produce com Objects out of every class the way they did visual basic. It would have made things *a lot* easier
--
"'argumentation' is not a word, idiot." -- thelizman
If you've used EJB, you should be able to identify (3.40 / 5) (#13)
by GusherJizmac on Fri Feb 09, 2001 at 01:57:53 PM EST

I totally agree. A project I was working on, we decided to use EJB and container managed persistence (if you don't know what that is, it's a way to automagically map your Java objects to fields in a database w/out using SQL). We also encapsulated business logic in session EJBs.

To do this, you have to create these awful XML descriptors. The only documentation on what they should contain is the DTD that describes it! Weblogic provides NO additional documentation other than the EJB spec! This is not cheap software! Anyway, if you don't get it just right, you get an error message, literally that is "Descriptor doesn't match DTD", and you are on your own to find out why and where.

Now, some of you might say to use the build tools that come with Weblogic or to use Visual Cafe or something. The reasons why I don't use them are three-fold:
   1) Not all of them work on Linux, and some are written in Java and are horrible to use and completely slow
   2) I don't like visual tools
   3) Visual tools insulate you from what's going on, putting you at a real disadvantage when things don't work right.

Now, many of these issues could be addressed by proper training. I've never been to Weblogic training, but every training course I've gone to has not been worth the money and has bascially sucked. They give you little to no information about how to actually build a production system and actually do development.

I think these companies get caught up in theories and cool technology that there really isn't demand for and then you are forced to use it for some reason or another. Then, they bolt on poor documentation and mediocre training, all at huge expense.

<sig> G u s h e r J i z m a c </sig>
EJB's and Weblogic (4.50 / 2) (#24)
by SlydeRule on Fri Feb 09, 2001 at 05:52:23 PM EST

Weblogic provides NO additional documentation other than the EJB spec!
Perhaps if you checked their Web site, you might have found Weblogic's XML Deployment Properties documentation. This is part of a quite-extensive on-line documentation library.

I might also point out that the part of the deployment descriptor that goes into the ejb-jar.xml file is specified by Sun, not Weblogic. You can find information on this in a number of Sun publications, both online and on paper.

we decided to use EJB and container managed persistence
/me sighs

EJB is a lot more than just Weblogic. The decision to use container managed persistence is a clear indication that the team was woefully unlearned about even the most basic concepts of the EJB technology.

Yes, EJB is quite complex. It doesn't get any less complex if you just jump in without learning even the basic concepts. It also doesn't get any less complex if you blame the vendor when you can't get his product to work without even looking at the documentation.

[ Parent ]

hints on Weblogic/ EJB (none / 0) (#46)
by zzzeek on Mon Feb 12, 2001 at 09:34:45 PM EST

We are using Weblogic server where I'm working. They did give us a week of training which was helpful, but the xml deployment descriptors are documented, anyway, the weblogic-specific ones by weblogic, and the generic ejb ones are in the the spec, which is great reading and will clear alot of things up for you.

Our code is buildable on three different platforms (NT, Linux, Solaris) using a great tool called Ant, which every Java programmer should learn how to use. Its all the goodness and wisdom of "make" without the ugliness, and is XML based. We can build any portion of the code and also automatically do an EJB-deployment, and it is dependency-based so the command is just "build" and thats it. My company spent a huge amount of cash on about 6 copies of Visual Cafe which are mostly still in their shrink-wrap.

The entity CMP thing is a little rough, as WL is lacking features in that area; you might have performance issues depending on how you use it. You should check out the standard entity performance enhancement which is the details pattern. Also read the WL docs on the "isModified" method or use a similar technique to minimize it from saving the bean's fields every time. Putting both techniques together yields an entity bean that usually does just one SQL query for a web page that would display its contents, instead of the unreasonable default of a select and an update for every accessor method called.



[ Parent ]
Entity Beans (none / 0) (#47)
by SlydeRule on Mon Feb 12, 2001 at 10:30:55 PM EST

The entity CMP thing is a little rough, as WL is lacking features in that area
The last I'd heard, most of the containers were lacking in that area, not just Weblogic.

Not that it matters much; CMP entity beans are the least valuable of all bean types. Offhand, I can't think of any place that they have a legitimate use.

All, or almost all, of your beans should be stateless session beans. Do not be fooled by the terminology "entity bean" into thinking that an Objectory entity class should be modeled as an EJB entity bean. A database row normally should be modeled as a separate entity class which uses a DAO (data access object) class for DB access. Both of those classes are included within the session bean. These entity classes (and DAOs) might well be reused across a number of session beans.

An entity bean is used when there is a clear advantage to having the EJB container deal with caching, concurrency, and transactioning considerations on some set of data, rather than leaving it for the database to worry about. This implies that the data being handled by an entity bean is heavily shared and reused during normal operation.

Once you've committed to the overhead of using an entity bean, you want to make that bean work for you. Consequently, when an entity bean is used, it usually models an entire cluster of data which is contained in joined tables, not just a single row from a single table. In the process, it takes on the responsibility for maintaining referential integrity. Container-Managed Persistence can't handle this complexity; you have to use Bean-Managed Persistence.

Stateful session beans are mainly useful for handling point-to-point communication links in cases where stateless beans won't work. They should be only be used where the number of potential links is very small; you don't want a lot of stateful session beans active at once.

[ Parent ]

you're just now figuring this out? (3.00 / 6) (#14)
by SEAL on Fri Feb 09, 2001 at 02:04:41 PM EST

This .plan is the best summary I've seen so far... :)

- SEAL

It's only after we've lost everything that we're free to do anything.

Hi welcome to the club! (4.66 / 12) (#15)
by cezarg on Fri Feb 09, 2001 at 02:13:25 PM EST

I also have the (dis)pleasure of writing MS apps. Nothing I've seen before compares to the continued obsolescence of the MS platform. We get new buzzwords coming out of Redmond every month now to the point that I'm seriously considering a change in my career direction. They keep "innovating" to the point where I am no longer willing to adopt. It's not that I refuse to learn it's just that those new technologies don't address any of my real problems. I have no use for ATL for instance. Perhaps it's nice but plain vanilla COM is what I've grown used to and have absolutely no intention of rewriting my (working) code just because MS decided to add a new buzzword to their repertoire.

I suspect that all those new tools are created purely to justify the existance of their creators. They all get pushed by MS through creating the "need" by continued obsolescence. Example: nobody at this point can predict what will happen to MFC and the code people spent years writing. MS has the new kid on the block: their .NET project. We all know that it will be the best thing since sliced bread and it will "revolutionise" the way we write our code. The problem is however, I don't want MS to revolutionise my development tools yet again. Besides the last thing that really revolutionised the way I worked was syntax highlighting in my editor. Everything since has just been buzzwords and fads. I'm fed up!

The other problem with MS is that new technologies creep in while the old ones don't get entirely scrapped leaving us with a sour mixture of old and new. The new supposedly better is usually a compromise made in the name of preserving compatibility so the implementation usually seems very "half assed". The example from my backyard is DirectShow an odd mixture of "old" ActiveMovie and "new" DirectX/DirectShow APIs. It takes not only documentation but some studying of MS's history to work out why some interfaces are the way they are. Sad, truly sad.

Unfortunately the Open Source world isn't that much better. Their stuff also gets written to be thrown out the window two years down the line. New graphics libraries and sound frameworks grow like mushrooms in the Linux world. Little thought is given to designing with future expandability in mind. Everything is written to address only a specific set of problems making them useless for most reuse.

C++ per se is not new and object oriented programming is certainly not a new buzzword. I would not throw it into the same bag as all those MS "innovations". C++ compilers tend to produce criptic meaningless errors but that are implementation specific. This gets particularly nasty with templates. Having said that you eventually get used to it and begin to accept the state of things. Where C++ really needs fixing is standardising its binary interface. Only then will we be able to see COM like libraries written in the spirit of C++. One of the reasons why COM is so ugly is because it uses C for it's binary interface. That eliminates name overloading, proper inheritance, type safety and other neat stuff.

There, I said it. Our industry definitely needs to reevaluate what does and what doesn't help us do our job. Solid implementations help us get there multiplying buzzwords doesn't. Hopefully now that they tech hype mania is fading away platform vendors like MS will cool down and think long and hard what really "needs" to go into the next version of Windows. Or maybe I'm just deluding myself. Most likely the latter.

C++ (4.00 / 1) (#17)
by ucblockhead on Fri Feb 09, 2001 at 02:56:24 PM EST

I think you are right about C++, that a lot of the problems have to do with templates and such, which after all, are relatively recent additions.

I think much of the problem is that people are too worried about backward compatibility so that new systems end up hacked together with the old ones so that it all ends up to be a big old confusing mess.

I've seen much the same multiple API crap in the CD interfaces I deal with that you mention for ActiveMovie, etc. Just to deal with something is simple as dealing with a audio CD means dealing with at least three different interfaces, all of which have bizarre quirks, and aren't ready for prime time.

In my mind, the answer to the question of what really "needs" to go into Windows is what is already there, only working. And yeah, I suspect that won't happen.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Standardizing the binary interface of c++ (4.00 / 1) (#19)
by your_desired_username on Fri Feb 09, 2001 at 03:36:30 PM EST

Sgi, HP, Cygnus, IBM, and a few others are pushing a standard C++ ABI. Unfortunately, it is intended for the IA64 platform. Some parts of it can be easily applied to other platforms - like class layout, but some parts, like exception handling, cannot.

Many C++ compiler writers (including gcc) have promised they will adopt it for the IA64 platform. Gcc intends to adopt the portable parts of it for every platform they support.

However, this does not address anyone's complaints about COM; M$ does not seem to care.

[ Parent ]
C++ is not the future (none / 0) (#53)
by arturo on Tue Mar 06, 2001 at 09:46:52 PM EST

C is a bad language but we can't blame because it was designed 'modest' and reflects K&Ritchie by those years believed a language has to being. And C has achieve its goals (OSes, low level libraries). What is really wrong is trying to do almost anything in C (its dangerous and expensive). C++ come into scene to be the 'real' language of modern OO concepts, but with a very wild extended syntax and almost the same weakness of C. So why not to try really fresh modern and elegant languages like Dylan or Ocaml?. It's a good advice.
Arturo Borquez
[ Parent ]
Construction Metaphor (4.85 / 14) (#20)
by rusty on Fri Feb 09, 2001 at 04:30:56 PM EST

If you'll permit me to use a construction metaphor here (I know this won't hold up to deep scrutiny, but I think it gets at the nub of the gist of the problem)...

Consider yourself, as a programmer, to be analogous to a bricklayer trying to build a brick wall. You'll need, basically, some bricks, some mortar, and a plan. You're a good bricklayer, and you've done this before, so the plan is pretty familiar.

You buy some bricks. Bricks are discrete, replicatable objects which have well defined dimensions and properties. They are the "heart" of your wall -- you might need to lop a few of them in half at the corners, but basically, they won't need to be messed with. These are your "objects", and the construction of software has got these pretty well figured out. In the bricklaying world, of course, you have to make each brick individually, but they all come out of the same mold. In code, you just make a new instance of a class for each brick.

You also need mortar. Here's where our problem lies as programmers. Your bricklayer, he's mixed a million batches of mortar. He knows exactly how to do it, but he still has to do it over again every single time. There's no choice for him, because he's dealing with a real world, finite resource. Programmers, of course, say to themselves "well, it sucks that we have to mix this mortar code every time we write something. Why not mix up one batch of "universal mortar" and then just refer to it when we need it!" This seems like a good idea, so they create things like COM.

But as it turns out, mortar is not just mortar. An experienced bricklayer will tell you that there's different types, for different situations. You need to get the mix just right for your current application, and you need to put just the right amount of it in the right places. To a programmer, mixing mortar seems like repetetive drudgery that they've done a million times already. But when you look at it closely, you'll more often than not find that while you've done similar things over and over, very few were actually the same.

So the attempts at universal mortar inevitably don't quite fit the current situation. What we're doing is trying to treat mortar like an object. You don't use a "piece" of mortar to stick bricks together-- you use just exactly enough to fill in all the cracks between your bricks. We're trying to package mortar in discrete chunks, and what we inevitably end up doing is making more mortar to glue our mortar together.

If you followed that tortured analogy (or maybe especially if you didn't), the point is this: Programming is not mechanical. It is not reducible to stringing prepackaged routines together. Or rather, a lot of it can be prepackaged, but the "stringing together" bit can't be. That's the voodoo, that's the real craft that we practice. Trying to replace this with packaged mortar will simply push our craft up another level, to stringing mortar together. So I guess you have to choose what the best place to mix by hand is, and the whole point of this rant is that things like COM push that hand-mixing to the wrong level and ultimately just make you rewrite a different type of thing over and over.

____
Not the real rusty

Couldn't resist... (4.00 / 2) (#21)
by ksandstr on Fri Feb 09, 2001 at 04:35:53 PM EST

Dammit, Jim, I'm a software developer not a bricklayer!



Fin.
[ Parent ]
Hell (4.50 / 2) (#22)
by titus-g on Fri Feb 09, 2001 at 05:41:35 PM EST

I've been both, ok maybe I worked more with (uncut) stone more than brick. But although I can't say why, but there is a definite correspendence.

Anyway the module/mortar thing works.

Think it all comes down to the fact that if you want to be good at anything, you should stop and go out and do other stuff.

Umm /me wandering, gag me with a spoon, night all...

--"Essentially madness is like charity, it begins at home" --
[ Parent ]

Other Work (4.50 / 2) (#26)
by rusty on Fri Feb 09, 2001 at 07:24:53 PM EST

Yeah, I used to make furniture, among other things. I can say that there definitely is a similarity between programming and many other kinds of skilled labor. I guess maybe it's only obvious if you've done some other kind of construction or craft work, but I think the idea is latent in a lot of coders minds. That's why we so often fall back on construction metaphors for what we do.

____
Not the real rusty
[ Parent ]
And round the prow they read her name. (4.50 / 2) (#27)
by titus-g on Fri Feb 09, 2001 at 08:21:15 PM EST

It's the art of the thing maybe, I know that with building, first you try, but eventually you know. Like with stone walls, you have a space, you can find the perfect stone to fill it, very peaceful :)

Programming can be like that, though it's trickier :)

Sufism has a quite a few 'stories' about it, nice to read :)

--"Essentially madness is like charity, it begins at home" --
[ Parent ]

There's no need for any new programming paradigms. (5.00 / 5) (#29)
by mrsam on Fri Feb 09, 2001 at 11:59:22 PM EST

Your real problem is that you have a completely crippled development platform that is explicitly designed against allowing any reasonable code reuse. Basic concepts that allow one to reuse code in a modular fashion have existed for a long time, but not on a Microsoft platform. Your problem is that you live in a world of its own, where forces of nature were not designed to make life easier for programmers and developers, but instead to bring a steady trickle of revenue to a single corporation based in Redmond, WA.

No, that's not a flame, that's a statement of fact. Consider the Microsoft development environment of, oh, say four years ago. Question for you: is any of what you've learned four years ago still applicable today? Such as VBX controls? OLE? ODBC?

No, of course not. And why not? Because Microsoft has a vested interest in keeping the life cycle of any technology as short as possible. This is required in order to keep all the developers in a perpetual cycle of having to constantly take new classes in order to learn the Way To Do Thing In Windows this year, to generate more revenue to Redmond in terms of certification fees, licensing fees, and development tools upgrade fees.

Now, please tell me what incentive does Microsoft to give you any development technology that can be quickly reused in other applications a year from now? Two years from now? Five years from now?

Of course there's none. Microsoft would rather have you back in class, and back for more certification exams year, after year, after year.

On the other hand, everything that I learned more than ten years ago, as a UNIX programmer, is still just as valid, and useful today for me, a UNIX/Linux programmer as it was ten years ago. Sure, I play now with many new toys that didn't exist back then. There's Perl. There's HTTP, and CGI. But all of that only SUPPLEMENTS what I've learned back then, it does not REPLACE it.

For example, go here, to find some of the stuff that I've been doing recently, in my spare time. Over there you will find: a mail server, an IMAP server, a webmail CGI application, and a mail filter. If you were to take a closer look, you would find that a good portion of the code -- as much as 70-80% in some cases - is shared amongst these widely different applications. In fact, all of these applications are built out of the same CVS repository, with the CVS modules defining which modules get built into what.

So, there is no need to invent any new programming paradigms in order to effect reusable, modular, code. It's already here, and it's been here for quite some time, in the form of the GNU toolchain (a simple set of configuration scripts and other tools that allow one to quickly build up modular applications). So, unfortunately, if you're looking for a stable, modular, development framework, you won't find it in Visual dot-whatever. But it does exist, and many people use it every day to build large scale projects.

Here's the thing... (1.50 / 2) (#30)
by spacejack on Sat Feb 10, 2001 at 01:42:04 AM EST

Yes it would be nice if the world were a happy-go-lucky-utopian "yay, let's all use Linux!!! And let's be all standard at the same time!!! YAYYYYY!!!!" world. But it's not, and sometimes it's fun to rant about this shit you have to deal with without someone going "You're all going to hell for using Micro$oft $oftware! $inners!! $IN!!!"

Anyways, I have a hard time believing that you don't waste just as much (if not more) time hooking up technologies with Linux.

[ Parent ]
Ripleys... (3.00 / 1) (#32)
by mrsam on Sat Feb 10, 2001 at 07:49:16 AM EST

Anyways, I have a hard time believing that you don't waste just as much (if not more) time hooking up technologies with Linux.

"Believe it, or not."

[ Parent ]

Still (5.00 / 1) (#34)
by spacejack on Sat Feb 10, 2001 at 02:56:08 PM EST

Look, the thing is, there are many opportunities to build some very cool things out of newer technologies. If it's a question of getting your hands dirty and making the thing, or wimping out and saying "eww not standard"... I choose to make it.

[ Parent ]
Re: Still (none / 0) (#40)
by mrsam on Sun Feb 11, 2001 at 12:04:10 PM EST

But see, the problem is that the "new technologies" in MSWindows today are going to be obsolete next year, or two years from now. This is guaranteed to happen. Without an artificially reduced technology lifecycle Microsoft cannot maintain a steady flow of revenues from licensing and product upgrade fees.

There is no doubt whatsoever that "COM+", whatever that is, is going to be completely obsoleted two years from now, by something else that Microsoft wants everyone to learn, and be certified for. This is so obvious, that it's actually laughable. COM+ is going to go the way of COM, OCX, and VBX. Only the extremely naive will doubt that.

Go ahead, and try to do something with COM+. By the time most people figure out how it actually works, this "technology" will be obsoleted by some other buzzword of the year.

[ Parent ]

Everything becomes obsolete (none / 0) (#41)
by spacejack on Sun Feb 11, 2001 at 01:50:38 PM EST

All software eventually becomes obsolete. COM has provided solutions to software developers for years and is by no means dead or unsupported. This is why I can still write a game using DirectX 1, while MS is up to version 8. And my app can detect this at runtime and deal with it.

What are you going to do, avoid all software and tools that will eventually become obsolete? Even when it provides solutions for the here and now that no one else does? That's just silly.

[ Parent ]
Re: Everything becomes obsolete (none / 0) (#42)
by mrsam on Sun Feb 11, 2001 at 04:06:49 PM EST

The read() system call is not obsolete. Neither is write(). Therefore, not all software becomes obsolete. It is very unlikely that any software that calls read() and write() is going to become obsolete in the near future.

DirectX is no longer a supported Microsoft technology. This is why you have to "detect it at runtime", because modern device drivers no longer support DirectX 1. This is an obsolete technology that is no longer supported. Two years from DirectX 8 will also have the same status, so if you wished to continue to provide universal support, you'll be in a perpetual cycle to write a layer upon layer upon layer of emulation code, for each version of the same basic API that Microsoft chose to deprecate in favor of a different API, each time their revenue stream from the current API ran out.

On the other hand, no POSIX software has a need to "detect at runtime" whether or not read() and write() is supported. The basic POSIX API layer has remain unchanged for decades, so me learning the POSIX API twelve years ago was not a waste, unlike the VBX, OLE, and ODBC APIs. It's the same way with the C++ STL. I know that any STL-based software will continue to work for the foreseeable future. Unfortunately, I have no similar assurances from Microsoft, that they are not going to announce tomorrow that MFC has been retired, and that everyone will have to go and learn a completely different API set. Or, perhaps that they chose to completely overhaul VB for .NET, requiring a major porting effort for the majority of existing VB apps.

... Oh, wait, they already did that. Never mind...

[ Parent ]

Not really. (4.50 / 2) (#36)
by cooldev on Sat Feb 10, 2001 at 07:35:17 PM EST

"Question for you: is any of what you've learned four years ago still applicable today?"

Aside from the fact that I was writing Unix and not Windows applications four years ago, yes. What exactly do you think OLE is? OLE, ActiveX, etc. are all COM-based and except for the naming it has been a very stable technology.

Microsoft has a vested interest in keeping the life cycle of any technology as short as possible. This is required in order to keep all the developers in a perpetual cycle of having to constantly take new classes... and development tools upgrade fees.

I doubt that Microsoft makes a substantial amount of money off developers, they probably barely break even. There is always a balance between moving too fast and not fast enough. But the old stuff still runs. You can still write DLLs and export functions. Heck, you can build monolithic applications in C and statitically link to all the .LIBs if you want.

Besides, what about every other technology? Can you honestly say that your Xlib and Motif skills have carried through to GTK and QT? What about HTML and scripting? XML? XSL? PHP? Do you groan every time Java gets updated? Javabeans? J2EE? Are you Red Hat certified yet? Give me a break.

When .NET comes out I can assure you there will be an interop layer that will allow you to cleanly interface with Win32 APIs, COM objects, DLLs, and all of the other "old" stuff.

"So, there is no need to invent any new programming paradigms in order to effect reusable, modular, code. It's already here, and it's been here for quite some time, in the form of the GNU toolchain (a simple set of configuration scripts and other tools that allow one to quickly build up modular applications)."

BS. Yes that's all good and useful for a certain class of applications, but piping a set of commands together does not equal component based design. If what you say is true than why are XPCOM, CORBA, and Bonobo still being developed and used?

Beyond Object-Oriented Programming by Szyperski is a good read. I looked at your page and you've done classic code re-use, but component-based development is about being able to hook together "off the shelf" components, often without recompiling.

Let me give an example.

Let's say you were building a mail client. Wouldn't it make sense to have a component that handles all MIME encoding/decoding? You don't need to have the source, put it in your CVS tree, and build it as part of the project. You just need the binary component with a good set of interfaces. Ok, next step, we need a way to display the message. Wouldn't it be nice to have a component that can display plain text, HTML, and RTF messages and even automatically highlights URLs? Again, you don't need the source, all you need is a component with a small set of interfaces. Ideally the editor component aggregates the same display engine, but you don't have to know that. Another component would handle talking to the SMTP/POP3/IMAP servers.

The idea of component technolgies such as COM and CORBA are that you can buy (or get for free) those components and write your app. The components are packaged for easy distribution and reuse, much more so then your source-level reuse.

First came code reuse, then static libs, then shared libs, and now (real) components. This doesn't mean that source level reuse or static libs are bad, it's just that components are sometimes more appropriate.



[ Parent ]
I agree (none / 0) (#54)
by arturo on Tue Mar 06, 2001 at 10:13:11 PM EST

Yes that it is!. Moreover add that Microsoft commitment to support WINOSes (as they stated) and all associated software is 3 years (see TechRepublic). It's a real mess, none serious tech effort would reach a maturity at so short time. Microsoft is plunging into precipice.
Arturo Borquez
[ Parent ]
Look past the wizards (4.00 / 3) (#31)
by cooldev on Sat Feb 10, 2001 at 02:25:45 AM EST

So COM and ATL sucks because it took you four weeks to get connection points working? It is ironic that the title of this story is about "new programming paradigms" yet you fail to realize the benefits of these.

Yes, there is a learning curve to both technologies. The curve will be even steeper (perhaps insurmountable) if you are a not a reasonably proficient C++ programmer. But the paypack in productivity is tremendous once you learn it. I don't care if you like Microsoft or not, but there's a reason that almost all their applications are heavily COM based. They understand component-based design.

Go pick up a book (start with Essential COM and ATL Internals) and learn how to use the technologies. It's not that hard, really! It sounds like the main problem is that you are relying on the wizard and tidbits of documentation from MSDN instead of understanding what is really happening. You're programming by coincidence and it's going to all fall apart sooner or later.

(BTW: You really only need to use connection points when firing events to VB or script. If you are building components that don't need IDispatch you can just register your own custom (simplified) callbacks. Either way it's not that much harder than any other language (ie. Java's "Listeners")).



Been there, done that... (4.00 / 1) (#33)
by ucblockhead on Sat Feb 10, 2001 at 11:06:35 AM EST

The trouble is that the wizards, books, etc. are all geared to stupid little test programs.

Anyway, the problem isn't the theory of COM. The problem is that ATL is horrendously implemented using confusing and error-prone macro and template hacks.

The problem is that I do understand what is going on, and what is supposed to be happening. The trouble is the wildy arcane syntax created with the assumption that no human being would ever use it directly.

I wish I were relying on the wizards. That'd make it easy...
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
I'm not convinced you've been there or done that. (none / 0) (#35)
by cooldev on Sat Feb 10, 2001 at 06:46:17 PM EST

"The trouble is that the wizards, books, etc. are all geared to stupid little test programs."

The wizards, perhaps, but this is not true for good books. ATL Internals and Essential COM should teach you more than you need to know for any sized project.

"Anyway, the problem isn't the theory of COM. The problem is that ATL is horrendously implemented using confusing and error-prone macro and template hacks."

I'll grant you that ATL is terse, and they perhaps were overly concerned about efficiency (using templates as a clever hack to avoid virtual functions), but ATL is quite easy to use without wizards. I personally only use the Visual C++ IDE for debugging. The reason for the macros and templates is that it makes it easy to do by hand. If they didn't care about making it easy the wizard could have just generated all the code from scratch and put in "do not touch" comments.

I normally hate macros and excessive use of templates, but ATL has clevery combined them in a way that makes writing COM objects almost a breeze. For example, CComEnumOnSTL is a bit tricky to use the first time, but it factors out literally hundreds of lines of redundant code that would otherwise be impossible to factor out.

Let me address some of the points in your article more directly:

1) You complain that SINK_ENTRY_EX( 1, DIID_DFooEvents, 1, OnFoo ) gives bad error messages when you mix up the control ID. True, but so does leaving a ; off the end of a class definition. If you used constants and DISPIDs instead of 1's and 0's then you wouldn't have had this problem. Besides, you should be happy whenever the compiler can catch an error for you! Lastly, if this is giving you so much trouble you can always directly implement DFooEvents (the convention is _IFooEvents, BTW), override Invoke, build a huge honkin' switch statement for the DISPIDs, and crack the dispparams yourself. Personally I'd rather use ATL.

2) "A good example in COM is the way you essentially have to reimplement basic reference counting in COM if you are doing it at the lowest level. Now, that's just damn silly. It would have been trivial to include."

I think what you are looking for is CComPtr and CComQIPtr. Quite easy to use, but again you'll have to understand what you are doing. But at least it relieves most of the burden of manual reference counting.

BTW: You didn't even mention the things that start getting hard in COM. I'm talking about threading, marshalling (especially when you can't rely on the built-in oleautomation marshaller), STA vs. MTA, worrying about the Windows message pump getting blocked (STA COM objects use the message pump for synchronization), reentrancy, custom class factories, circular reference counts, etc. Luckily most programmers shouldn't have to deal with most of this stuff.

One point which you probably didn't intend to make rings true: ATL (and to some extent COM) was not meant for dabbling. They are tools for serious software developers. If you want to dabble you can write and use COM objects in VB, Python, Perl, J++, and many other languages. Those four make it especially easy, but you'll give up some of the benefits of C++.



[ Parent ]
not for dabblers? (5.00 / 1) (#37)
by kubalaa on Sun Feb 11, 2001 at 05:39:29 AM EST

What nonsenese. I don't have to know anything about the technologies you're talking about (and indeed, I don't) to agree with the original writer that this is a design flaw. If I'm a software engineer / programmer, my job is to come up with a simple conceptual model for the code and then get it implemented. It is not to understand arcane and backwards details of some language or set of libraries. Anything which is not simple and intuitive enough to be "dabbled in" is badly designed, because when it comes to coding, dabbling is all a real programmer should need to do. The meat of the work and intelligence is on design, the language is just a tool.

How much time did you waste, er, spend, trying to comprehed the COM system?

[ Parent ]

Devil's advocate (none / 0) (#45)
by kubalaa on Mon Feb 12, 2001 at 09:33:28 PM EST

I've been thinking about the other side of this. It may be that COM is like OO programming; it takes a while to wrap your mind around. Once you've learned the methodology, you think about things a different way and it does all become simple, but before that you're trying to apply old methods to a new tool.

So the first poster's problem was that he had what he thought was a simple way to do it, but his "way" was not the COM "way." And perhaps in his case, COM was a bad idea. *shrugs* That said, I still think that there are a great many systems that are more complicated than they need to be, and leverage too few existing technologies for ease-of-learning. It's almost as if it's a meme evolutionary thing; make old ideas obsolete so the new ideas have an all-or-nothing advantage.

[ Parent ]

Good observation (none / 0) (#48)
by cooldev on Tue Feb 13, 2001 at 04:56:14 AM EST

I've been thinking about the other side of this. It may be that COM is like OO programming; it takes a while to wrap your mind around. Once you've learned the methodology, you think about things a different way and it does all become simple, but before that you're trying to apply old methods to a new tool.

Well said. I'd like to think this is how most things worth learning are. For example, I've actually read The Language Instinct but I can still only partly follow discussions such as this, especially when they start mentioning things like semantic vs. pragmatic vs. morphological analysis of language or "phenomena such as VP Ellipsis, Discontinuous Constituents, Anaphora Resolution and Presupposition..." But the fact that the analysis of language and grammar is complex and hasn't been fully refined doesn't mean it's worthless.

I'd rate COM/ATL a couple orders of magnitude easier than (human) language analysis. Once you get past the initial hurdle (and stop using wizards) it's pretty easy going. It's possible to get up to speed and start writing COM objects after spending a few hours a day tinkering for about a week.

There are a couple of reasons for the complexity in ATL. One is that COM was designed after C and C++. ATL helps adapt it for C++, but the launguage doesn't have first class support for COM. Other languages such as VB and J++ don't have this problem; in fact it's so seamless that most people don't even realize they're using it. I believe that in J++, for example, Microsoft's Java runtime treates every class as a COM object. (This is a VM implementation decision and has nothing to do with compatibility issues).

We cannot forget that the reason software development is so complex is that we're always trying to push the envelope. As soon as something becomes simple we take it for granted and move on to try something more complex.



[ Parent ]
Disagree (none / 0) (#49)
by ucblockhead on Tue Feb 13, 2001 at 03:24:22 PM EST

Sorry, but COM just isn't that complex, in theory. The ideas behind it are pretty damn simple. The trouble is with the implementation.

After all, if COM makes things more complex, and makes are work harder, why the hell use it? I've done all this the hard way, with raw NetBIOS calls. The point of COM should be to make it easier to do this sort of thing.

I think the fundamental disconnect here is the assumption that someone saying that the new technologies aren't ready is the same as someone saying that the ideas behind them are bad. I've no problem with COM/ATL/etc in theory. But a bad implementation is often worse then no implementation.

Yes, the point of software development is to make complex things simple, but listen very carefully here: I am not a COM developer.

What I mean by that is that I have a lot of complex things that I need to make simple. What I need is for other people to make other complex things into simple tools that I can use. The reason this is important is because I don't want to waste my time making other, peripheral stuff simple in lockstep with thousands of other coders.

And that's really the whole point of the exercise. In my mind, until the vendor of COM makes COM simple to the extent that it is useful for me, I'm going to question, in my mind, whether or not there's a point in using it.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

<Sigh> (none / 0) (#50)
by cooldev on Wed Feb 14, 2001 at 03:57:39 AM EST

And that's really the whole point of the exercise. In my mind, until the vendor of COM makes COM simple to the extent that it is useful for me, I'm going to question, in my mind, whether or not there's a point in using it.

What part of my statement about how VB, J++, Python, Perl, etc. makes COM easy did you not understand? It sounds like these would be perfect for you. As you said, you are not a COM programmer.

I'm not disputing that using COM in C++ requires learning, even with ATL as a set of helper classes. But what you fail to realize is that there is a benefit to using this technology. A benefit that can not currently be realized any other way.

Tell me what other significant technology can be learned without having to learn anything. I'm a fan of Java, and the class library is pretty decent, but the work required to become proficient is only slightly less work than learning COM + Win32. There are tremendous benefits of using Java for some projects; other projects are made very difficult or impossible.



[ Parent ]
You aren't reading... (none / 0) (#51)
by ucblockhead on Wed Feb 14, 2001 at 10:17:02 AM EST

The statement "I am not a COM programmer" means "I am not one of those whose task it is to develop COM". You are still missing the point.

What part of my statement about how VB, J++, Python, Perl, etc. makes COM easy did you not understand?

The part where VB, J++ or Python would let me take an existing C++ windows program and change it into a program that uses an ActiveX control and uses a connection point, using ATL. I'm not going to go into my individual app further because it is proprietary information. Suffice to say that it is a damn site more complicated then you assume.

The trouble is that you are doing the Microsoft thing: essentially blaming the developer when the tools are difficult to use. Again, I've personally done the sort of thing that COM does at a very low level. I know how complex it is. That is not the issue here. The issue here is making the API transparent to the ideas behind the API. That is a design issue.

The trouble is not that COM requires learning. The trouble is that COM and ATL require learning arcane syntax and behaviors that have nothing to do with the ideas COM implements.

To understand what I am talking about, imagine a C++ compiler that responded to any error at all with nothing but "this program is wrong", with no line numbers and no additional information. Would it make sense to say that any developers that complained just haven't learned it well enough because they are getting errors? Does it make sense to tell anyone who complains that perhaps they ought to try a simpler language like BASIC?
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Missing the point. (none / 0) (#39)
by ucblockhead on Sun Feb 11, 2001 at 11:00:09 AM EST

I normally hate macros and excessive use of templates, but ATL has clevery combined them in a way that makes writing COM objects almost a breeze.

Yeah, until you get an error. There is a reason that all the C++ gurus recommend against macros. It is because they make debugging a nightmare.

As I said originally, that's the trouble with COM. It is a snap to write nice little test programs. I've done it myself. Slapped out a control in thirty minutes. The trouble comes in when it hits the real world. Try converting an existing deskband object to a complete COM control. That was my task, and it wasn't easy because so much of was completely undocumented.

The trouble is, most Microsofties rarely do anything but slap together little test programs. This is especially true in books.

(And I've read the two you mention, so stop with the recommendations.)

You missed the point of the error I was taking about. Yeah, leaving a semi-colon off will give you a syntax error. But it will be something like "Syntax error:missing semi-colon" in a reasonably intelligent compiler.

) You complain that SINK_ENTRY_EX( 1, DIID_DFooEvents, 1, OnFoo ) gives bad error messages when you mix up the control ID. True, but so does leaving a ; off the end of a class definition. If you used constants and DISPIDs instead of 1's and 0's then you wouldn't have had this problem. Besides, you should be happy whenever the compiler can catch an error for you! Lastly, if this is giving you so much trouble you can always directly implement DFooEvents (the convention is _IFooEvents, BTW), override Invoke, build a huge honkin' switch statement for the DISPIDs, and crack the dispparams yourself. Personally I'd rather use ATL.

I was not complaining that there was an error. I was complaining because it the error wasn't something like "Error, no sink class defined for that control id,.:. You know, something that'd help me fix the error. That's the basic problem with the whole ATL system. It wasn't designed to be used by a human being.

(The convention may be _IFooEvents, but the wizards use DFooEvents.)

(Personally, I'd rather use a good API, rather than either doing it raw or using ATL. Hence the original rant.)

I think what you are looking for is CComPtr and CComQIPtr. Quite easy to use, but again you'll have to understand what you are doing. But at least it relieves most of the burden of manual reference counting.

Again, you are missing the point. I've used both of those, so you can stop with the condecension. The point I was making with IUknown was that in the original implementation of COM, some of the most obvious things were missing. That was just one example. There are a ton of others.

One point which you probably didn't intend to make rings true: ATL (and to some extent COM) was not meant for dabbling.

I ain't no dabbler. I've been a profressional programmer for fifteen years. I've used many different APIs. I've done many things that are conceptually much harder then COM. The problem is that COM is simply a bad implemtation.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

RMI, COM, ATL aren't new programming paradigms (4.00 / 2) (#38)
by jetto on Sun Feb 11, 2001 at 09:04:27 AM EST

Before speeking about new programming paradigms your must look to things like lambda calculs and functional programming, logic programming, constraint programming, native distributeted langue and native concurent langage.

I prefer to call them alternative insted of new paradigms, since there are quite old now, even if they are not very used.

RMI, DCOM, CORBA are just tool to do remote invocation. It never come to mind of somebody to say that pipe, socket and IPC are paradigms, so why for RMI and the other. I know that marketing and commercial force are very good to sell sand saying it's gold, like Sun and Java, or Microsoft an New Technology (NT), but we must look outside.

If you want information about alternative programming I suggest to look at Moazrt witch is an implementation of Oz that is a multi-paradigm langage (fonctional, distibuted, concurrent, logic and constrained).

To see how to solve SEND+MORE=MONEY in Mozart look here

This is what a new paradigm can do for you.

I don't say that RMI, DCOM, CORBA aren't usefull, I just say that they are not more new programming paradigms than pipe, socket, or IPC.

RMI COM, ATL aren't new programming paradigms (none / 0) (#52)
by arturo on Mon Mar 05, 2001 at 05:17:43 PM EST

Sorry about my english. I agree with you about functional programming. I am surpriced the low attention that programmers are giving to FP that undoubtly is a great stuff, and divert their attention in accesory short sighted concepts. Moreover, all this middleware layer do devepment more difficult and expensive. In my personal opinion all this nightmare is because they put the NET in the wrong place breaking apps in the 'middle' and all that was safe, consistent becomes unsefe unconsistent fragmented 'virtual'. I hope that developers and IT manager will recover common-sense. The real solution to do Client/Server apps is gathering all app code into the server and the client must become in a ultra-thin-client (terminal app) like Internet Browsers do (running applets). I predict that CORBA, COM ... will die in a few years.
Arturo Borquez
[ Parent ]
Are new programming paradigms ready for prime time? | 54 comments (47 topical, 7 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!