> 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.
OK. Use dist-obj-nofork please ...
> Sandor Spruit wrote:
> >
> > Ron,
> >
> > Ron Resnick wrote:
> >
> > > Sandor Spruit wrote:
> > > >
>
> Man, this is like ping-pong.
Reading Joystick Nation at the moment - reminds me of thePong - era :)
> > <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.
Agreed, but ... (see below)
> 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).
Indeed - like with my Dictionary app which includes a TaskModeldescribing the activity
known browsing-a-dictionary. I cannot do
a nydecomposition here, since the reason I'm doing this work in the
first place is that we do not *have* a workable model yet.
> 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.
Yep, "everything has bits" Talk about bottom-up programming ! :)
> 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)
OK.
> > 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.
Agreed.
> > 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.
Okay, so maybe I'm just too busy with applications where it is notthat easy to isolate
the "bottom" parts and work your way upwards.
> 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.
True. This argument suffers from the same preoccupationmentioned above.
> > 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.
Yep. To you and me it isn't. To the outside world it is, probably.If you are happy
using your monolithic apps, you'll consider The
New Way to think Components an extra hurdle to take.
> > 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 :=)
Thanx.[snipped the quotes]
> 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...
Sad but true. There must be some sort of an agreement between all ITshops to keep the
salaries from going sky-high.
> > > 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.
*very* true. Though it's difficult sometimes given the sort of religiouswars on
operating systems, languages etc. etc.
> > > 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.
Me too, of course - but at times, especially when using M$ stuff .... ;)
> But if the cataclysm does happen, is it wrong to try to take advantage
> of it? Ernie? Adam?
Depends on who's left on the Planet to judge your actions ...
> 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.
8-)
> Cool that a thread which started from a duck post on smoking, with a PS
> on Y2K, is now back to duck :-)
Ping - pong - ping.
> 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?
Nope. It's sad but true :(
Sandor
-- ir A.G.L. Spruit, Utrecht University, the Netherlands "...just another village, burning in the hills, Saw it on the tv, just another thrill, Someone else's problem, someone else's grief..." (from Fish, "The perception of Johnny Punter")