Re: GoTo in Java

As usual, an excellent response, Michael.

I understand your position, but it hasn't changed mine :-).

I've made a few quick responses below, but I really don't have time to
labour this further.

I believe in components. I don't believe in maintaining them. I don't write
large graphics applications or gaming or simulation software; my comments
should be interpreted purely in the context of commercial business
processes; accounting, administration, MIS, etc.


"Michael Wojcik" <mwojcik@xxxxxxxxxxx> wrote in message
news:ds7pnl0gc7@xxxxxxxxxxxxxxxxxxxx

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.

I certainly is for me.

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).

As this point I was waiting for you your examples and was pleased to see you
provided some... :-)

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.

Having never written this kind fo software, I'll take your word for it.
However, I believe if it was approached with the idea of simplification,
encapsulation, and decomposition it has to be possible to make it better.
Even in the most complex of engines there are sub-assemblies. I see it this
way; I understand that you don't. I don't think you are wrong, but you have
failed to persuade me it can't be done. :-)

There's no reasonable
option other than to put the (necessarily complex) processing of the
image data format into a component and maintain it.


My experience has taught me that when people say "There's no alternative" or
"It's the only way..." what they really mean is that they WANT to do it this
way, OR they are unable to think of another way. I've seen this countless
times and there are invariably alternatives that weren't considered, because
the people were too close to the problem, no discussion and brainstorming
was done, or there was an entrenched culture of "That's the way we do things
here" or similar.

I have adopted a Japanese proverb as the motto for my current project where
it has been necessary to stress that several teams of people are involved
and it is essential that the whole thing melds as one team. The proverb is:
"None of us is as smart as all of us." I firmly believe in discussion and
brainstorming, even on deeply technical problems. There is no room for
technical prima donnas (or even the Project Manager :-)) to impose a
solution without exploring all options available. If the guidelines are:
"Simplify, encapsulate, decompose" somebody somewhere will build a less
complex, more efficient, 'complex engine'. Just on that, I was interested to
note in passing today in the NZ Herald technology pages, that a company here
is building electric motors that are highly innovative.
(http://www.nzherald.co.nz/search/story.cfm?storyid=00077DCE-ECE1-13E6-A35183027AF10240).
I couldn't help thinking that it was a brave man who would decide to improve
on the simple technology of an electric motor. Yet someone did. Success has
been 10 years coming to Wellington Drive, but they have persevered and it is
now paying off.


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.
Well, that's only 2 options... why stop there? What about public properties
that allow DST to be off or on and specify when it is to start and stop?
Anyone using the engine could specify at the time they invoke it, what
their DST requirements were. These can be parameters or properties and can
be passed from anywhere you like, including a command line or control
script. It would be tempting to include the location, but I wouldn't do
that. Simply build a 'smarter calendar'. Then wrap the location data into
another component that invokes the smarter calendar... The smarter calendar
would not require maintenance (unless the rotation of the Earth was to
change :-)) Location data would be passed through the 'location handling'
component which would also be suitably parameterised. And so on...

Personally, in the interests of standardising and stabilising interfaces, I
don't pass parameters to components; I use public properties instead. Set
the properties to obtain the behaviour you want, invoke the component, get
the results from the properties it set up when you ran its methods. Stable,
simple, maintenance free.


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.

I disagree. If you build the components right they can cope with all of the
above scenarios.

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.

Hmmm... I don't plan on writing any critical business applications in
VBScript, Turing-complete or not...

Just because something CAN be done, doesn't mean you necessarily want to do
it.

I once wrote (for a bet) a computer program that read punched cards,
processed the data on them, and produced printed output, using only the
logical operators AND, OR, NOT, and XOR (plus branch, load and store
registers - and I could have done without those by cheating and building
them in memory form the BOOLEAN instructions...). That was Turing-complete
(it looped through the input), but I wouldn't recommend people to adopt this
form of application development :-)

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.

No, we can agree on that.

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? Yes.
From hand-assembling to software assemblers? From
assemblers to early high-level languages like COBOL? Maybe... not sure.
To structured
programming? Yes.
From programming the "bare metal" to running under a
monitor, and then a full-blown OS? Definitely.

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 agree with that, but OO was a major step forward and components are
another leap again.

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.

And there's also surprising resistance to change, and conservatism from
people who you would expect to know better. They resist having programming
standards imposed, that may require changes in how they write programs,
never mind new languages, and, God Forbid! new TECHNIQUES and CONCEPTS!

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.

So has everything else. And DCOM+ today is NOT the DCOM+ of 6 years ago. I'm
not pretending it is fireproof (nothing is...) but it is not as fragile as
the naysayers would have you believe, either...

(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).

And there is no such thing as a bug free program, there are only programs
that haven't crashed yet... What is the point of all this? We live in an
imperfect world. We have to make compromises every day. I'll settle for
something that runs NOW and delivers ROI, rather than wait ten years to make
it impossible to penetrate (if that can EVER be truly achieved). Any system
that is impenetrable is useless. There has to be legitimate access and then,
by definition the system is not impenetrable.

However, DCOM+ is beside the point.

I agree. I mentioned it purely in the interest of historical fact. My first
great thrill in the RPC/Component world just happened to be in that
environment. It was interesting that all the people who had predicted dire
consequences and the likelihood that it would NEVER work, were surprisingly
quiet when it ran for months without problem. After a year, they didn't like
to be reminded of their gloomy prognostications, but by then they were
writing COM components too...:-)

The quality of a particular
component implementation (distributed or not) doesn't say anything
about the usefulness of a component architecture in general.

No, that is very fair comment. It DOES say that at least one practitioner
has successfully implemented a system using component technology. Not only
that, but he has been pleased by the results of it and then moved on to
repeat the process in different environments.

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).


Yes. :-) (A very fair statement which I have no difficulty in agreeing
with...)

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?

You don't. Ever. You know it is free enough to run without problem for as
long as it is likely to be needed. So you take the same chance that all
computer programmers take, having done due diligence and QA, promote it to
live for a couple fo weeks and let the users find the bugs you missed...
:-) AFTER THAT you don't maintain it...
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.

Glad you agree. I found this out by trial and error.


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.)

Just about every modern computer language, scripting or programming, (apart
from SQL, and some implementations of that can be excluded) is
Turing-complete. That is not the issue here. Is glue the same as timber? You
say it's not a fair statement because the glue is "Turing-complete" just
like the timber, I say Turing-completeness is not the criterion I would
judge this on. Glue and timber are both brown, but that doesn't mean they
are the same.

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"?

Your compilers and Editors are not injecting glue automatically.

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.

OK. I grant that. As I said above, my statements are intended for commercial
computer programming. (This is a COBOL forum... :-))

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".

Point of Order... :-)?!!! This whole section was intended to amuse, not
participate in serious debate...


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.

C has had it. It will, like COBOL, be overtaken by events. C++ may survive.

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.

An excellent and fair summation. I'm happy to leave it there :-)

Pete.


.

Relevant Pages

  • Re: success-path-only software
    ... Programming Languages ... The primary function of a programming language is ... Supports business applications that require the Supports sophisticated ... a prototype to show sample report formats and ...
    (comp.lang.misc)
  • Re: How do I combine enumerated constants?
    ... I'm still kicking it with 2005 (I don't use new programming ... languages and new applications in general, I like letting other people ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: About speed
    ... programming, in the same way as object-oriented programming isn't more ... delegate void Method; ... A lot of people thought that one day all business applications would be ... business rules in unmanaged languages are numbered. ...
    (borland.public.delphi.non-technical)
  • Re: Is OOP a paradigm or methodology?
    ... insurance applications, then financial, then wireless etc). ... Ada does not use curly braces. ... > is an up-to-date, flexible language that allows system level programming, ... ADA and Eiffel and C++ are all great languages. ...
    (comp.object)
  • Re: Programming Practices
    ... developing C# applications and programming in general. ... and have developed simple applications to work with Access/SQL databases. ... code into 'layers', you hear about the presentation layer, the data access ... I implemented this with a data access layer, a business logic layer and the ...
    (microsoft.public.dotnet.languages.csharp)