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

Ron Resnick (resnick@interlog.com)
Wed, 27 Aug 1997 17:27:10 +0200


Hey, I like this thread! It has the potential to bring all kinds of
stuff
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
crosspost,
I'll send out a notice on d-o with pointers to the FoRK archives to this
thread.

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'
approach
(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
that
everything beyond a certain threshold in your life (you, your dog, your
kettle,
your baby's diaper :), has bits, and that those bits are its shadow
(component).
And, all these shadows live on a network - a packet network, with direct
attachments to the platforms where other shadows live. Now you start
hooking
them all up, so they can fire messages at each other. And then you do
the
by-value object-migration agent thing. Next thing you know, you've
solved
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
clear.

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
networks.
(For a good Java active networks link, try PLAN - discussed in
http://www.infospheres.caltech.edu/mailing_lists/dist-obj/0415.html)

> 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
very
healthy - it's a self preservation instinct. But the real trick to
survival
is sometimes knowing when a conservative strategy is the *worst* thing
to
do, and you really have to take the risk. Good money managers understand
the tradeoff between risk & safety. A good number of entrepeneurial
startups
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
top-down
decomposition. Sure, at least you'll wind up with a set of
responsibility-driven
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
think.

In some cases, this will always be necessary. Some things are by
definition
"big goals". But lots & lots &lots of sw systems can just as well be
done from the opposite direction - assembly of components that were
never
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
the
problem. It's the zen. The karma. The faith. Not necessarily
Objectology-objects,
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
http://www.infospheres.caltech.edu/mailing_lists/dist-obj/0458.html
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
possible
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 -
believe
in the concept, not the brand.

> > I doubt it. Revolutions don't come by gradual change from within. They
> > come
> > by starting all over again on a clean base. Those ComponentX guys
> > I mentioned yesterday are out in left field in terms of really
> > building something meaningful. But those are the kind of folks who one
> > day
> > may save us from ourselves.
>
> I wouldn't exactly wanna call a bunch of crashing planes and companiesa "gradual
> change from within". If a 747 on your roof does not qualify as
> a revolution coming from the outside, I sure wanna know what does ! It
> would require you to "start all over again on a clean base", too.

Hey, you're right! Maybe there is a silver lining to a 2K crash. When
the world is reduced to rubble, we can start all over with nothing but
Beans :-). Of course, it would be highly "unethical" of me to actually
be hoping for a disaster in which people may lose their fortunes, even
their lives. And to gleefully anticipate such a thing, and be scheming
to benefit & profit from it? Grotesque! But - I'm not the one
instigating
it. I'm powerless to control the possibility of a 2K crash. If anything,
I'm still doing my bit to prevent it from happening - I'd rather see
systems made safe, than hope they crash.

But if the cataclysm does happen, is it wrong to try to take advantage
of it?
Ernie? Adam?

duck once noted, some time back, that sometimes people have to die for
progress to be made (very badly paraphrased - apologies duck). It was in
the 'Algonquin bears' thread. So, maybe a Y2K crash might be God's way
(oh boy,
now I'm in trouble) of letting us 'start over'? Like Noah's flood?
Yikes.
I better bail out.

Cool that a thread which started from a duck post on smoking, with a PS
on Y2K, is now back to duck :-)

One other subject I wanted to bring up - this one addressed primarily
to Rohit - deals with the front end/back end business. I noted
that common practice is to build 2-tier or 3-tier architectures with
the front end being GUI, OOUI, Web, Java, CORBA, whatever cool stuff
is out. But the backend is sacrosanct datacenter stuff.

Now, the 'object revolution' I preach is the peering of all that. All
the clients==servers==peers. Note that the web is about peers - for all
of its
c/s http underpinnings, what makes it powerful & scalable is its peer
nature -
all documents link to all other documents. There is no root.

But the *business* usage of the web maintains the tiered asymmetry. The
backends
are still there. The're not 'munchkinized' or 'document-ized'. The
revolution isn't complete - the evil 3-tier still lives.

And I think that's what troubles me in your Church of Objectology piece.
Yes, the web is probably gonna smother us object-weenies just by its
sheer mass. But is that a good thing? Is that really
the revolution we want? Does that really end the legacy nightmare
Sandor&I
have been discussing? If it's all cgi's to Oracle stored procedures,
where's munchkins in that? Where's all your neat 'physics alcove' ideas?
The 'Magic Eye Shroud slapped on a web page' doesn't sound like it fits
to the real revolution. The database behind all those part catalogs is
still-
a database. On a server. In a datacenter. Am I missing something?

Ron.