Re: GoTo in Java


In article <44bngcF1d24oU1@xxxxxxxxxxxxxx>, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> writes:
"Michael Wojcik" <mwojcik@xxxxxxxxxxx> wrote in message
news:droi6h02jb4@xxxxxxxxxxxxxxxxxxxx
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.

So am I; that's NOT what I'm advocating... :-)

My experience over the last 5 or 6 years is that the simpler the components
are, the more reuse they get. 'Nontrivial' functionality is comprised of
smaller, decomposed, functionality. It's like building with Lego. You don't
change the bricks.

That's fine in theory, and no doubt often achievable in practice.
However, there are simply going to be cases where a component can't
be decomposed into definitely-bug-free pieces, and cases where it
has to change because of a change in requirements that can't be
captured by specialization (at least not in a sensible fashion).

For an example of the former, consider a GUI component that renders
an image map. Image rendering is notorious for security holes; we've
recently gone through another spate of these vulnerabilities. Any
component that renders an image is potentially vulnerable to issues
such as integer overflows, and that's not something that can be
usefully decomposed into trivial components. There's no reasonable
option other than to put the (necessarily complex) processing of the
image data format into a component and maintain it.

For the latter, consider a calendar component which has rules for
daylight savings time. Either those rules can come from processing
DST rules files - in which case you have much the same problem that
you have with image files above, plus questions of how those rules
files are located, etc - or they're hard-coded, in which case there
are localization issues. Moreover, you have situations like what
we're faced with in the US right now, with a pending change to the
rules for all the regions which observe DST, plus an incipient switch
in most of Indiana to observing DST - though the timezone differs in
different parts of the state, and a significant portion of the
population appears determined to ignore it. That's a change in
requirements which can't be anticipated by a trivial component.

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.

Well, that's an interesting argument. Would you say that 'scripting' and
maintaining script, is the same as 'programming'? It is certainly arguable.

Yes, I would. Scripting languages are programming languages; I don't
even see a clear distinction. "Scripting" seems to be an informal
description applied to some high-level languages with primitives for
executing external commands. Aside from that, I don't know what makes
Perl, for example, a different kind of language from, say, C. They're
both Turing-complete, compiled, general-purpose languages that have
been used for everything from trivial one-off utilities to large
production systems.

But I think you would agree that the script required to glue a bunch of
components into an application has nothing like the volume, verbosity or
complexity of the all the lines making up those components, irrespective of
the language(s) they're written in.

That's generally true, yes, though I'd be reluctant to make a maxim
of it. Judicious use of highly-expressive languages can get a great
deal done in a few lines of code (for an exercise in the OCaml book
I'm reading, I just wrote an entire dictionary system, suitable for
eg a spell-checker, in under 50 lines of source), and I've seen
component-based systems that used an awful lot of components and glue
code.

I have seen a similar product form MicroSoft that was used for building RDB
procedures and triggers. Most impressive. Finished, working, bug free,
application in minutes from a graphic IDE without a single line of code
(script or procedural) in sight. Just drag and drop components. I believe
that is the future.

The future for accomplishing certain tasks, perhaps; I think it's a
good goal to aim for in much application development. But I don't
see anyone building, say, a production DBMS this way, or a real-time
3D rendering engine.

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.

There we have to differ. I believe it does. It has certainly changed the way
I develop systems. Radically.

Is it more radical than the shift from plug-board wiring to stored-
program computers? From hand-assembling to software assemblers? From
assemblers to early high-level languages like COBOL? To structured
programming? From programming the "bare metal" to running under a
monitor, and then a full-blown OS?

I don't think so. I think those (and several others) were all
advances of approximately the same order. For individual practi-
tioners, yes, they often marked radical changes in the way they
personally created software, but over the course of the (short)
history of the industry, they represent a steady, if steep,
evolution.

I don't agree about it being oversold; if anything, it is undersold. Just as
OO was undersold to traditional programmers.

I'll agree it's under-adopted. But I think billing it as revolution-
ary actually is partly to blame for that. We work in an industry
where there's far too much hype, and consequently too much noise and
a concommittant cynicism.

From the day I first got remote procedure calls working in a DCOM+
environment that 'everyone knew' was unsafe and unstable and vulnerabe to
attack and could never work, and I had to be crazy to even think of
developing in it, I was sold.

Well, DCOM+ *is* vulnerable to attack. It has been attacked, often
and successfully. That's simple fact.

(No-one has ever successfully hacked it. There are safeguards in place, both
hardware and software. Of course there is always a risk, but all risks have
mitigations.)

Unfortunately, in security, negative anecdotes don't demonstrate
anything useful; there are plenty of insecure systems that have never
had a breach detected. That's no comfort to the people who own
systems that *were* compromised (all of which, of course, had never
been "hacked" right up until the point when they first were).

However, DCOM+ is beside the point. The quality of a particular
component implementation (distributed or not) doesn't say anything
about the usefulness of a component architecture in general.

Suddenly my applications could be distributed around the network, could load
level themselves, and could reach across vast distances (this app. ran in
Australia... it's a big place) just as if they were running on a standalone
desktop. One copy of encapsulated functionality, running anywhere you want
it. I was sold then and I'm sold now.

Sure. Distributed applications have been paying my salary since
1991, and even in 1988 I was working on a commercial multi-tier,
multi-protocol middleware product.

I agree that most front-end applications can be written by gluing
components, and that there are significant advantages to doing so;
and in many cases, at least some of those components will be
distributed (though hopefully with far more attention to security
than there has been in the past).

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.

Again that's where we differ. If you maintain a component, you shouldn't
have written it as a component. I have components that I wrote years ago,
they are successfully deployed in live appplications and I have NEVER
TOUCHED THEM since they were written. The only time I would consider
modifying component code is while it is being tested and debugged.

How do you know when it's free of bugs?

Once it
does what it is specified to do, its methods, properties, and events are
documented and that's what it does. Nothing more, nothing less.

Oh, interface stability is a fine thing, and well-written components
will enforce a degree of programming by contract, which certainly
eliminates huge classes of errors. No disagreement there.

If you want
to modify the way a certain method works you wrap the component and either
override the method.via an interface, or write a new method in the wrapper.
Encapsulated functionality is exactly that...encapsulated.

I'm not advocating changing the interface. Published interfaces
should be stable (extensions aside). Microsoft's failure to learn
this is responsible for "DLL Hell", which in turn has created a
counterproductive move away from the most basic form of component-
ization, shared code modules.

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.

Yes, it is certainly useful to experiment with different arrangements and
that's where a GUI IDE comes in handy. This is the same argument as above;
is script actually source? I don't think so, but I would agree it is
arguable. I predicate my argument on the fact that glue is not considered to
be timber, and, so far as I know, no one has ever built a house (or anything
else) from glue.

I think that's a false analogy. Glue isn't structural; it's of a
different order. Scripting languages have the same capabilities as
the components they assemble. (I've never seen a "scripting
language" - at least nothing to which I'd apply the term - that isn't
Turing-complete.)

You can hardly call it 'source maintenance' if you have machinery that
allows you to experiment with different positions and combinations of
building blocks, and then, when you are satisfied with the final
arrangement, injects the necessary glue for you at the right places...

I don't see why not. I have compilers and editors that let me
experiment with different arrangements of the statements permitted in
my programming languages; how is that not such "machinery"?

When I experiment in OCaml, I use the compiler's top-level
interactive loop, which incrementally compiles each statement into
the workspace as I enter it. Similar facilities are commonly used
for LISP, APL, and even many traditional BASICs. How is that
qualitatively different? (I could create a GUI representation of it
if I liked.)

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.

OK, I grant that. There are still people who make flint tools and speak
Latin. Most of them do it for fun or because their profession requires them
to investigate and understand these things. They are, as you say,
'specialized practitioners'. Could we exclude these from the argument,
having agreed this point? My statement was referring to the world at large.

The specialized practitioners I was thinking of were more on the
lines of the programmers of embedded systems - which represent the
vast majority of computers in use, incidentally. Many of those
systems are hard real-time, using the minimum-spec hardware required
to do the job (because in such systems every penny counts). I don't
see them using GUI component-assembly tools, by and large, anytime
soon; as embedded hardware gets more capable, more will be demanded
of it, so there's always room in the market for the lowest-end
implementations.

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.

12 and a half years from now? Sure...step right up and meet August, 2018...

1. Wireless internet will be the norm and will pervade our lives. Most
people will carry a device or accessory that connects them to it instantly.
'Intelligent jewellery' will be a sought after accessory; brooches,
cufflinks, spectacles that all talk to you using their internet connection
to keep you informed instantly..

I assume "most people" here refers only to the industrialized
middle-class; I think hoping for pervasive WiFi in Bangladesh in
the next decade is probably a little optimistic.

(Personally, I loathe the idea of being surrounded by people who
are constantly interacting with unseen presences, which is why I
don't live in an institution for the insane; but apparently some
folks think it'd be swell.)

2. Roads will be tolled, cars will be made of non-metallic substances, run
on hydrogen (or water) and everyone in China will want one.

Point of order: this has nothing to do with "this industry". I
didn't say anything about the possibility of accurately speculating
on the future of other industries. (That said, I'm not sure I find
this terribly convincing either. I don't see any engineering
purpose behind making cars entirely out of non-metals, and water
doesn't have much energy density.)

3. Gorillas will be extinct in the wild.

And who knows how many other species...

4. Large scale supersonic air transport will be available. London to Los
Angeles in 4 hours.

I don't think there's a market for it, frankly. The Concorde was
never commercially successful. And conventional SST over populated
landmass is unlikely to gain government approval, while HST is too
hard on the passengers. (Even astronauts aren't fond of riding on
the "vomit comet".)

5. The 2002 COBOL standard will be implemented by a consortium comprised of
the remnants of MicroFocus, AcuCOBOL, and Bendix

Well, at least it's making better progress than the 1999 C standard.


To sum up, though, I think we're largely in agreement that component
architectures are a Good Thing; our disagreement seems to be in
quantity, not quality. And I wouldn't be dismayed if components did
storm the battlements; there's a lot to be said for rigorous
enforcement of interfaces and interoperability and loose coupling.
We could stand some better-quality software. Components don't
guarantee that, but they provide some of the tools to make it more
convenient, and convenience is half the battle.

--
Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx

Pretty good for a small-town kid who grew up with all the advantages a
prosperous nation has to offer but decided not to bother with any of them
in favor of gaming, TV and, of course, blogging. -- The Rotting Dog Blog
.

Relevant Pages

  • Re: Scripting 101
    ... any discussion of scripting should begin with a discussion of the ... automation environment and it allows me to quickly create software to ... although somewhat primitive compared to scripting languages ... However, unlike most programming languages of the time, these scripts ...
    (comp.home.automation)
  • Re: Programming language for financial modeling
    ... languages, there are a bunch of languages designed purposefully for ... If you are doing simulations there is SIMULA. ... > I am thinking about learning a programming or a scripting language. ...
    (Debian-User)
  • Re: object system...
    ... C/I is also unable to effectively facilitate some non-C/I languages, ... Interface is a poor-man's MI. ... Consider a doubly-linked list interface. ... such activity as programming, you better program before you execute ), ...
    (comp.object)
  • Re: How Tcl speaks for itself and how Tcl is not spoken for...
    ... If we conclude that Tcl doesn't have any major technical defects, ... does have a few, but so do most of the other scripting languages), ... languages" as not being "real programming languages" and scripts not ...
    (comp.lang.tcl)
  • Re: Lua (was Re: What would you do with 10 Man Years?)
    ... |> The idea that scripting has to be slow is a rather primitive ... programming at all; rather, ... "system programming" LANGUAGES. ... the Lisp family of languages lies somewhere between ...
    (comp.lang.lisp)