Lists Home |
Date Index |
Mike Champion wrote:
> "In teaching someone about COM programming, it would be nice if I could
> just teach them how to use the Visual Studio wizards and all the code
> generation features, but if anything goes wrong, they will not have
> the vaguest idea what happened or how to debug it and recover from it.
> I'm going to have to teach them all about IUnknown and CLSIDs and
> ProgIDS and ... oh, the humanity!"
> Sure, the Wizzy IDE's can handle the simple cases, but "oh, the humanity!"
> when things start to get complicated or the un-stated assumptions
> are violated.
Note that languages/systems that depend on IDEs have no evolutionary
staying power. They are replaced over the long-term by competitors that
are less picky about their creation environment. So, for example, MFC is
dead and none of its modern replacements are even remotely as grotty.
Same with COM (which is being replaced with .NET). And every attempt to
make programming languages deeply visual has failed.
Part of the problem is that there is a stubborn hacker subculture that
will not be bullied into buying tools and they will invent a better
replacement if only to avoid it! Insofar as they are picky about syntax
and the people using the other languages are not (how could they be, if
they don't see it), the text-hackers tend to win.
On the other hand, easy-to-edit IDL is being replaced by WSDL so perhaps
I'm seeing a trend that isn't really there.
> "Code generation tools which pretend to abstract out something, like
> all abstractions, leak, and the only way to deal with the leaks
> competently is to learn about how the abstractions work and what they
> are abstracting. So the abstractions save us time working, but they
> don't save us time learning."
As usual, Joel is almost right but not quite. ;)
Abstractions do not always leak. I've been using a PowerBook for several
months, both programming and in GUI apps and not once worried about
PowerPC assembly language. Compilera and interpreters have pretty well
hidden that from me through abstractions. The problem is that code
generators do a poor job of abstracting. A code-generator is typically a
workaround for not having implemented the right level of abstraction in
your library or language.
Visualization tools are fine, but they should be visualizing the true
abstractions in the language you are "editing", not trying to hide them
from you with some thin, proprietary, quasi-abstraction layer.