Re: GoTo in Java


In article <43vp1uF1pnsa5U1@xxxxxxxxxxxxxx>, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> writes:
>
> The point that is being missed entirely here is that the real solution is to
> NOT maintain source code. (In any language...) ...
>
> Component based development means you write code once and do NOT maintain
> it. (I know there are many places that don't adhere to this and they try and
> maintain the components. There is only marginal gain over a normal source
> code maintaining shop if you do this.)

I'm dubious of the prospects of writing bug-free nontrivial components.

> The rule of source code is over. The future belongs to object code.

As component-composition systems get more powerful, they become source
development environments; the "source" is simply composed of components
and their connections.

When I was at IBM one of the products I worked on was Data Explorer,
IBM's scientific data visualization system. It was a package for
examining large data sets graphically, with support for all sorts of
2D and 3D representations (loop-faces, isobars and isosurfaces,
voxels, hedgehogs, etc). It could import, combine, and filter data
from a wide array of sources; it supported various devices for
dynamic data manipulations (flyovers and so forth); it could perform
many data manipulations; and it could be extended by its users.

It used a component programming model and provided a visual development
and execution interface: a canvas and a component palette. The user
dragged components onto the canvas and wired them up, producing a
graph that was executed in data-flow fashion. Users could write new
components in any language that could call the API, and they could
package graphs as macros for use in other graphs.

At the time that was fairly unusual for a commercial product, but
since then the idea's been used extensively for things like JavaBeans.

What we saw during testing was that users would start off with simple
graphs, then elaborate them to add new function, refactor common tasks
into small graphs that they would package as macros, and so forth.
They were writing source code - it was just source code where each
"statement" was in fact a component.

I believe components will continue to be important in software
development, and that component systems will continue to improve, and
that we will indeed see components becoming ever more dominant, just
as higher-level languages have gradually displaced assembly as a
language of choice. (But just as assembly is still used for niche
applications, so too will non-component development.)

However, I think the component "revolution" has been oversold. To my
mind, it's nothing more than the continuing evolution of programming
toward greater abstraction and interoperation. It's often very
useful (we have customers that have made very good use of combining
third-party components with COBOL programs, and of course we're
selling component facilities too), but I don't believe it marks a
radical change.

> Maintining source code is yesterday's technology.

Component authors will still have to maintain the source to those
components. I don't see anything obviating that need. And people
building applications from components will discover that they need to
maintain their component arrangements - which is just source
maintenance in a different guise.

> But I also think people need to start thinking 'beyond the square'. Todays
> kids are doing it. In 50 years the idea of sitting down and 'programming' a
> computer line by line, will be a quaint curiosity, like us using flint tools
> or speaking Latin in the Supermarket.

I'm not so sure about that, either. Many old technologies have a way
of remaining relevant to specialized practitioners even after they've
left the mainstream. But speculating about this industry fifty years
from now, while entertaining, isn't likely to be very convincing; we
don't have enough history to meaningfully extrapolate for a quarter
of that time.

--
Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx

Do we have boyfriends? We are interested in delicious food and sweets.
And tiny animals like the cat. -- Naoko Yamano
.

Relevant Pages

  • Re: (OT) In search of a definition
    ... Basically Java used the keyword 'package' ... One difficulty with using English language words for technical terms, ... as found in programming, ...
    (comp.lang.cobol)
  • Re: GoTo in Java
    ... smaller, decomposed, functionality. ... maintaining script, ... > It used a component programming model and provided a visual development ... > package graphs as macros for use in other graphs. ...
    (comp.lang.cobol)
  • Re: OO and Extending (Was: Is Procedural Paradigm a basis of OO Paradigm?)
    ... That greatly depends on the language. ... You have to *show* OOP being better, not merely claim you are smart ... Most IF statements add *features*. ... shanty-town-like graphs. ...
    (comp.object)
  • Re: Can you recommend a language to...
    ... Can you recommend a language to... ... Graphs becoming images and constant page refreshes chewing up ...
    (comp.lang.ruby)
  • Re: Looking for a plotting package
    ... > I am looking for a package with a simple API to allow me to write ... > to have the user play with the graphs. ... If you're on a Windows platform and willing to deal with COM, ...
    (comp.programming)