Re: GoTo in Java



"Peter Lacey" <lacey@xxxxxxx> wrote in message
news:43EF81EC.BD753329@xxxxxxxxxx
Pete Dashwood wrote:

"Peter Lacey" <lacey@xxxxxxx> wrote in message

Perhaps it is not a good example (?)



Perhaps it is, perhaps it isn't. You could say that AFTER you'd
answered! That way you would seem less dismissive.

Peter, I spent time attempting to respond to your points. How is that
dismissive? I even went on to try and provide a good example of the case
you
were making. I don't HAVE to do this, so a little more civility if you
please.

You said "why would that happen?" You said "Perhaps it is not a good
example". Over and over again, in this newsgroup, in other fora, and in
real life, I have posed questions which have been dismissed as
impossible in whole or in the assumptions, and in any event not worth
answering, so often that I react sharply at times. You did attempt to
answer but, that being said, I have to respond according to my own
issues, not yours. If you truly found that uncivil - it wasn't meant to
be - then my apologies.

OK :-) I wasn't being sharp when I asked how it could happen, but I see how
it could be interpreted that way. I am not trying to defend a position here
because I really don't care whether people use it or not. I'm trying to
explain it simply because it is different to the norm and I find it very
successful. I wouldn't even raise this subject unless somebody asked me. I
did a long time ago; until I learned better and did my own thing and let CLC
get on with it... :-)

Let me be more general, then. Suppose a component starts giving
demonstrably incorrect results, several years after it's been put into
production. Are you saying that you'd still use it but wrap it in some
other thing that corrects the error?

I'm saying that is a hypothetical which, so far, I have not encountered
in
the real world. This despite having many components running live now for
a
number of years. To answer your question:

1. Components cannot be faulty if what they do is properly defined. (They
either do it or they don't, and if they don't, they don't go live.)

With the best will in the world and the most rigourous procedures
things can still be overlooked.

I understand why you have a problem with this. (I was a procedural COBOL
programmer for over 20 years.) Like I said it is a DIFFERENT approach.

I really don't know how I can explain this in a way that will enable you to
see past what you "know"....

There is an old story about an archer who was an acknowledged master of the
craft. When asked how he could possibly be so good with a bow and arrow he
replied: "I claim that whatever the arrow hits is what I was aiming at..."

This is a bit like that, inasmuch as the functionality is developed (evolved
by interaction and iteration, really) and seen to be working. Then it is
documented as doing that.


2. IF, by some incredible stretch of the imagination, and purely for the
sake of intellectual argument, the scenario you posit was to happen, no,
I
would NOT wrap a faulty component. It would be replaced in its entirety,
with the whole proces of its functionality being reviewed and rewritten.
Fortunately, these are relatively small pieces of code, so this approach
is
viable.

No stretch of the imagination, incredible or not, is needed. I wouldn't
have posited it if it hadn't happened to me.

If you have never developed and written a component based system, then it
hasn't happened to you. It has happened to you when you have inherited or
developed standard code. I keep saying it is not the same, but the message
doesn't seem to be getting through. Yes, both approaches involve writing
code to program a computer. But that is where the similarities end. The
methodology used to decide what to write, the units in which the code is
written, evolution rather than design, the factors that decide when code is
"finished" (goals are achieved), the way in which problems are fixed, the
methods of user interface and documentation, are all different from the
usual approach.

I think it is better, but I'm not here to evangelise. I use it. It works for
me. I defy anyone to find a post from ME complaining about having to
maintain source code at 2am...:-)

I can think of three
instances: all were programs executed at year-end or infrequently; all
had functioned properly for six or seven years before I inherited them;
all three suddenly started producing incorrect results, apparently at
random. One was suffering from a weird and completely unanticipated
combination of circumstances which led to a (calculated) divisor of
zero; the other two failed due to inflation! Work fields in a
calculation didn't have sufficient digits. When the programs were
written consideration was given to the maximum values the fields would
have to contain but the maxima were eventually exceeded. In the other
program there was a check for zero-division; since it was considered
impossible the default action was inappropriate.

Sure, I've had similar experiences, and I'm sure many people reading this
have too. I haven't had such experiences since I started using component
based design.

The inflation one is interesting... I would agree that if the fields
overflowed because the computer could not accommodate them, then that would
certainly be a flaw in either approach. In the component case it might
involve an override of a property when we were dealing with currencies like
lira or yen. Personally, I make accumulation fields the maximum size
available on the platform (but that's just me, and some would argue it is an
unnecessary inefficiency.) It would be wise to trap overflow and ensure
action was taken right at step one when the code was being developed.

Such a thing could conceivably slip through, though and the code would be
broken in either case (whether you used components or you didn't.) Because
of encapsulation in a component based approach it is very easy to identify
and fix the error with minimal effect on the existing code. Even if you
didn't have the source code, you could STILL fix it in a component based
system. (You would need to wrap and override the offending method, and the
Class would need to have been written in a manner that allows you to do this
(implementing an interface or an extension or using factory) ) This is
extreme and to do this simply to avoid changing the source (assuming you had
it) would probably be pushing things unnecessarily. So, yes, in a case like
this you might change the code. I can honestly say I haven't had such a
case. I certainly don't consider this to be "routine maintenance" and I
stand by the position that things like possible overflow should have been
considered on day one when the code was written.

Other causes are possible. I'd say that nearly all of them are due to
unanticipated circumstances. I would not have the hardihood to assert
that ANY method of design and implementation is guaranteed to be
error-free and absolutely complete under all possible circumstances. I
have hubris but not that much.

It isn't arrogance that makes me say it, and you are pushing my position
beyond where it was stated to go.

There is no hubris in saying "code does what it does". It is a simple
statement of fact.

As you may have seen in other discussions here, I do not believe in
absolutes either. I am saying the code does what it is documented to do.
(Because the document was written AFTER the code was seen to be working...)
It does it day in and day out for years on end. Just like your operating
system, your compiler, and most of the critical code in critical
systems.(Many of which are component based...) I am not saying what you
assert above. I am happy to write code that hasn't crashed yet, and to know
there is fair chance that it won't and I can run it with confidence. If and
when it does, fine, I'll deal with that. But I won't be maintaining source
code which generates more possible errors and increases the chances of it
happening.

It is "over maintained" source that is most error prone, and yet, knowing
this, there are still people preaching the value of maintaining source. For
most of them it is because they have no other choice. I'm saying there ARE
other choices, but it is easier for many (particularly experienced
programmers) to decide they are just a re-invention of something already
understood, than it is to actually approach them anew, and evaluate them on
their own merits, instead of how they stack up to "what we do now".

I am not trying to "sell" components to you. I have no vested interest here.
I really don't care whether anyone else uses them or not. I attempted to
answer some questions, that is all.


The problem we are having here is that you are trying to relate my
component
approach to what you do now. It is a DIFFERENT approach, conceptually and
practically. You might as well complain to an orange because it isn't a
pineapple.

A greater man than me once blasted a fig-tree because it wasn't bearing
fruit. That it was out of season wasn't considered important.

Sorry, I fail to grasp the significance of that.

The problem we are having here is that you are implying something that I
consider to be incredible if not impossible: that code can be written
and tested so perfectly in the beginning that maintenance is not
necessary.

<Sigh...> That is not my position. I am saying that if you code "ADD 1 TO
COUNT" and it compiles and runs correctly, it is reasonable to assume it
will continue to do so. That is what it does. So if you ever need to
increment a counter...:-) Now, you might need something that increments in
2s. Well, the above component is not what you need. It doesn't do that. You
might as well say that the general ledger system is pointless because it
won't do debtors. Hey, they're both posting to ledgers, runing balances and
controls and producing audit trails...

On the other hand, when you sat down and coded ADD 1 TO COUNT you might
have thought to yourself it might be a good idea to check for overflow on
COUNT, and permit values other than 1 to update it... so, now it becomes
ADD INCREMENT TO COUNT ON OVERFLOW CALL COUNT-ERROR-HANDLER
The Help File [spec.] for the component now changes to say that it adds any
number (placed in factory at beginning of run or day or whatever, or set as
a property before invoking the "increment" method) to a counter and checks
that the operation succeeded. If it didn't an error processing component is
invoked.

So, if I need to increment a count...:-)

I would venture a guess that it's not impossible that there
are others following this "ng" that agree with me.

I would accept that there are many (probably a majority) here who have never
used Object Oriented programming or built a component based system. That
would tend to make your statement very likely.

In no other way can
I take your suggestion that nobody will do maintenance of code as
meaningful.

Do you normally maintain code that is correct? No, you maintain code because
it is wrong. If it works, you leave it alone. :-)

Sometimes, circumstances will change and, because the bit that needs to be
changed is embedded with other good code that doesn't need to be changed,
you change the "bad" bits and regression test the lot. Components give you a
much better chance of only needing to change or replace the bad bits;
everything is much more decomposed into encapsulated specific functionality.
Lego bricks; not concrete slabs (and, yes, I accept there are places where
concrete slabs are very useful. However, for the most part, commercial
computer programming is not about building motorways; it is about holiday
villas and comfortable, purpose built homes and offices...) You don't need
to regression test the good bits because they HAVEN'T changed.


With respect, I can't get away from decades of experience:
things will change over the course of time that will require revisiting
the code. I am NOT questioning your methods of development.


That's really OK. I understand your feeling about it. I can't explain it
more than I already have and the "decades of experience" make it difficult
to see. (That is not a criticism; I had exactly the same problem when I
first embarked on this.)

Just ask yourself this: "If I HAD NO SOURCE CODE what would I do?"

I have live applications which use components for which I don't have source.
I use Windows components every day for which I don't have source (so do you
(if you run in the windows environment) but you are not aware of it).

It isn't a problem.

A component that cost a couple of hundred dollars could save me months of
work. (I have some that come in this category and I have others that I have
traded that saved me heaps of work also.) These components get reused over
and over and pay for themselves many times. If one of them DID fail (so far
none of them ever has) I'd get a replacement from the guy who wrote it, OR
I'd simply write a replacement myself. I have that option. The Methods,
Properties, and Events are documented, along with the interfaces; replacing
it would be a fairly simple task (in most cases; not the ones that would
take months to write :-)) It is still better than trying to maintain source,
in my opinion. The other thing abut this approach is that some of the people
writing these components have specialist knowledge of certain areas, and
produce components with methods and properties you might never think of if
you did it yourself. (Yes, you could add them later, but it's much better if
you don't have to :-)) I only have one lifetime; I cannot and do not desire
to be, expert at everything.


What you call a spec I'd call documentation,
because it's post-facto.
Sure. But don't lose sight of what the "documentation" is intended for.
Yours is to help maintain the code; mine is to tell you what the
component
does.

It is extremely important that such a thing
exists for the benefit of others and yourself ten years from now at
2a.m. in an emergency, whatever we might call it.

No, Peter, it isn't like that at all. There is no requirement for
documentation aimed at maintenance because the component will NEVER be
maintained. Not now, not in ten years from now, not ever...

It has a Help file stating its Methods, Properties, and events. (That is
ALL
it has and all that is needed.) It does what it says it does. It cannot
do
more or less. That is why it doesn't fail in production.


Well, for the rest of us, who have programs that do fail, and do so at
the worst time - the aforesaid 2a.m. - your "spec" would indeed be
invaluable. It would help eliminate the places that don't need to be
looked at.

Hahaha! I take your point... :-)

Pete.



.

Relevant Pages

  • Re: Fraction
    ... in the documentation whose title is "division". ... in front of this 3rd paragraph, you would generate an index entry ... which many times is just a politer way of saying "if you want it, go do it yourself, who is stopping you?". ... The things that go without saying needn't be like that if the author of a code actually thinks about it while writing the documentation -- but for this a programmer needs to realize this himself. ...
    (comp.graphics.apps.gnuplot)
  • Re: Yet Another Spinoza Challenge
    ... Undefined behaviour is to make it easy to write optimising compilers. ... By saying "the behaviour on overflow is undefined" ... both the compilers can simply emit the code register a = register b + ...
    (comp.lang.c)
  • Re: LOOP CODE
    ... you seem to be saying "all optimizers are perfect". ... to add, compare and branch or to subtract, ... prepare two sets of tests when the sign of the increment ... in the optimization phase prior. ...
    (comp.lang.pl1)
  • Re: Where is the notificiation about IE zero day vulnerablity?
    ... You are refusing to do research and are ... Saying 'it's there, find it' is easy. ... A man who loves/believes/is passionate about what they speak of is willing ... and able to present documentation at a moments notice - backing up what they ...
    (microsoft.public.security)
  • Re: Measuring time differences
    ... > use in Microsoft Windows than Microsoft do you are giving BAD advice. ... used to compare times. ... The MS documentation simply says you shouldn't ... I'm not saying its not there, ...
    (comp.lang.c)