Re: Y2K stuff (Re: smokers - victim/victorious)

Ron Resnick (
Wed, 27 Aug 1997 17:27:10 +0200

Hey, I like this thread! It has the potential to bring all kinds of
together. Stay tuned for Munchkins, Objectology refs, God&Ethics refs -
the whole
FoRK gamut! Talk about your basic Interconnectedness ....

BTW - this is getting to be very dist-obj'y. I think that rather than
I'll send out a notice on d-o with pointers to the FoRK archives to this

Sandor Spruit wrote:
> Ron,
> Ron Resnick wrote:
> > Sandor Spruit wrote:
> > >

Man, this is like ping-pong.

> <remark>Agreed, but you and I know that it ain't that simple to design, implement
> and test an entire system using a component approach. It takes a whole
> new way of looking at a problem to get to a system of loosely coupled
> components.
> </remark>

Yes, this is true. But I think part of the problem is in thinking that
you're even building a 'system' to start with. I suggest that the most
successful application of componentware comes from lots & lots of
components being designed & built as standalone things - typically
shadows attached to real world things - with the guys building them
not even having any 'system' or 'application' in mind. Then, you cobble
sets of them together as needed for ad hoc tasks.

Granted, this can't always work - there are always situations in which
you have a specific large-scale task in mind, and there's no way to find
'commodity objects' to satisfy it. Then, my preferred 'bottom-up'
(assemble prefabs into desired goals) has to be replaced by 'top-down'
(decompose desired goals to determine requisite components).

Most of 'traditional' OO is the latter, bottom-up stuff. Start with
a problem- e.g. build a telco switch. Then decompose its complexity into
objects, and implement those. Even if they're built as components, such
as Beans, or OpenDoc parts, they still began from a particular problem
in mind.

The other approach is *don't* start by assuming you want a telco switch.
Pretend you've never heard of such a thing. Rather, start with saying
everything beyond a certain threshold in your life (you, your dog, your
your baby's diaper :), has bits, and that those bits are its shadow
And, all these shadows live on a network - a packet network, with direct
attachments to the platforms where other shadows live. Now you start
them all up, so they can fire messages at each other. And then you do
by-value object-migration agent thing. Next thing you know, you've
the global telecommunications problem (how to build a robust, routable,
scalable network) without a single top-down switch - everything is just
diapers & kettles. Ok- I'm oversimplifying (a ton), but the principle is

This, btw, is munchkins, as I understand it. Oh sure, change the shadows
to html docs or something. Big deal. Minor technical adjustment.
Routers=end nodes. Mobility & self-propagating messages = active
(For a good Java active networks link, try PLAN - discussed in

> It is always difficult to foresee exactly where a software project is heading,
> or so it seems. If anyone would suggest me to replace a huge system with
> an entirely new approach and new software, I don't think I'd do it.

True. I don't blame IT for its conservativeness. Conservativeness is
healthy - it's a self preservation instinct. But the real trick to
is sometimes knowing when a conservative strategy is the *worst* thing
do, and you really have to take the risk. Good money managers understand
the tradeoff between risk & safety. A good number of entrepeneurial
understand it too. Most of IT, imho, doesn't. I predict most of existing
IT will collapse over the next 20 years, as startup component shops
massacre them.

>It is
> just too difficult to predict how long it will take to complete the software
> because programming is so intimately related to human problem solving
> in general. To predict the outcome of a software project solving some real
> problem

See, that's the difference in top-down, bottom-up again.
If you start assuming that all sw has
to solve some large scale 'real world' problem, then you're doing
decomposition. Sure, at least you'll wind up with a set of
objects (if you do it right), but you're right - you've set a big "goal"
and measuring progress towards it is very difficult - impossible I

In some cases, this will always be necessary. Some things are by
"big goals". But lots & lots &lots of sw systems can just as well be
done from the opposite direction - assembly of components that were
part of a 'big goal'.

> requires a deep understanding of the problem in advance, but if
> you actually understood the problem into every detail beforehand, you'd
> probably not even need the software anyway !

Um..? I don't think so. Understanding your problem intimately doesn't do
away with the need for its solution.

> If you introduce an extra
> variable into the equation (we are going to solve the problem with this
> entirely new totally cool way of thinking "components", yeah)

It's not an extra variable. Not to me. It's the only way to think about
problem. It's the zen. The karma. The faith. Not necessarily
mind you. But granular, encapsulated, well-defined bit-packages? Yes.

> Hmm. Now you got me curious... Have to browse through the archivesto find the
> Despair problem; I've not really be following discussions lately.

It's in
buried halfway down a long post. You know how I like to bury stuff :=)

Here's a bit of it:
So back to brains&people. And my thoughts driving this morning. And the
'despair' problem, neatly summed up in Joe Kiniry's oft-used quote:

the issue i have with this is that, for the most part, most products
of engineering in our field are written by the 97% and thus, no matter
how open and beautiful and wonderful the framework/bus/system/whatever
is, they'll screw it up. these wonderful plug-and-play, self-aware
gizmos will be equivalent to little blind, deaf, and dumb mechanical
cockroaches that run up to each other, touch antennae, and vomit.
-- Joe Kiniry

(the '97%' being the great unwashed out there, of course). This same
despair sentiment was also well-phrased recently by Doug Lea:

Nearly all of the consequences of the widespread adoption of Java are
pretty scary if you think too hard about them. People who know nothing
about distribution are building distributed systems. People who know
nothing about concurrency are building concurrent programs. People who
know nothing about OO frameworks are building GUIs.
-- Doug Lea

I said more in the post, and I'm writing even more on the side. Only
I'm not sure yet if I should give it a happy or a sad ending....

> Well, over here in Holland - hate to admit it - there are just not enoughtrained
> guys to do the work in the first place. That's part of the problem,
> too. The industry could use some 10.000 IT guys a year in Holland alone,
> but only some 2.000 are graduating from our universities and institutes for
> professional education.

Oh, it's not just Holland, Sandor. It's worldwide, as you know. Which is
why you'd think supply & demand would raise the salaries of really good
distributed sw folks to the range of baseball players or something.
Unfortunately, supply/demand economics doesn't always work evenly...

> > Maybe. You're suggesting that if we have enough plane crashes
> > and bankrupcies on New Years Day 2000, then people will suddenly
> > wake up, smell the coffee, and want to solve the real problem for once?
> Hmm. I must have fallen asleep and started dreaming while I was keyingthis in !
> :) Hope they'll be smelling Java, BTW 8-)

Sure, that would be nice. But I don't know how likely it is. It's
that us Java guys will be the ComponentX guys of a few years from now.
The trick is to never get to emotionally attached to the tech. base -
in the concept, not the brand.

> > I doubt it. Revol