Programming for Electronics Engineers

[Reg Edwards]

GOTO's are a positive menace. Any language which allows them is a disgrace
to mankind's considerable acheivements in that direction.

They constitute abandonment of essential discipline to complete chaos in
program structure. Helpful only to lazy, soltitary, so-called programmers,
obtaining money under false pretences, who are unable to remember what its
all about the next day. But GOTO's are wicked, useless, obstructions to
bug-finding and maintenance operations carried out by poor unfortunate later
workers who get all the blame for the enormous costs involved.

I first went on a 2-day computer programming course around 1962. Language
was un-named. But there was no GOTO. Never since been on such a course. The
computer was contained in a 5-foot, by 3-foot, by 2-foot case using discrete
transistors. About as sophisticated as a present-day pocket calculator. The
input/output device was a teleprinter using ticker-tape.

So I ought to know!

At the age of 79 and still programming, my favourite language is still the
well-disciplined Pascal. It doesn't have a GOTO instruction except the
in-offensive GoTo(X,Y), where X,Y is a screen coordinate ready for writing
or printing.

The most easy to understand language, of course, is Plain English. We are
still waiting for a compiler. Our Eastern friends, the hard-working
Chinese, look as though they may beat us to it!

 

[John Larkin]

GOTO's are a positive menace. Any language which allows them is a disgrace
to mankind's considerable acheivements in that direction.

They constitute abandonment of essential discipline to complete chaos in
program structure. Helpful only to lazy, soltitary, so-called programmers,
obtaining money under false pretences, who are unable to remember what its
all about the next day. But GOTO's are wicked, useless, obstructions to
bug-finding and maintenance operations carried out by poor unfortunate later
workers who get all the blame for the enormous costs involved.

Oops, I guess I scooped up about $40 million under dishonorable
conditions. I should give it all back, I suppose.

John

 

[John Fields]

GOTO's are a positive menace. Any language which allows them is a disgrace
to mankind's considerable acheivements in that direction.

 

[Don Pearce]

GOTO's are a positive menace. Any language which allows them is a disgrace
to mankind's considerable acheivements in that direction.

They constitute abandonment of essential discipline to complete chaos in
program structure. Helpful only to lazy, soltitary, so-called programmers,
obtaining money under false pretences, who are unable to remember what its
all about the next day. But GOTO's are wicked, useless, obstructions to
bug-finding and maintenance operations carried out by poor unfortunate later
workers who get all the blame for the enormous costs involved.

I first went on a 2-day computer programming course around 1962. Language
was un-named. But there was no GOTO. Never since been on such a course. The
computer was contained in a 5-foot, by 3-foot, by 2-foot case using discrete
transistors. About as sophisticated as a present-day pocket calculator. The
input/output device was a teleprinter using ticker-tape.

So I ought to know!

At the age of 79 and still programming, my favourite language is still the
well-disciplined Pascal. It doesn't have a GOTO instruction except the
in-offensive GoTo(X,Y), where X,Y is a screen coordinate ready for writing
or printing.

The most easy to understand language, of course, is Plain English. We are
still waiting for a compiler. Our Eastern friends, the hard-working
Chinese, look as though they may beat us to it!

GOTO jail. Go directly to jail. Do not pass GO. Do not collect 200
pounds.

Plain English has the phrase GO TO, and makes very good use of it.
Don't be a programming snob.

Computer literacy is the ability of a computer to understand English.

d

Pearce Consulting
http://www.pearce.uk.com

 

[Jim Thompson]

GOTO's are a positive menace. Any language which allows them is a disgrace
to mankind's considerable acheivements in that direction.
[snip]

The most easy to understand language, of course, is Plain English. We are
still waiting for a compiler. Our Eastern friends, the hard-working
Chinese, look as though they may beat us to it!

GOTO jail. Go directly to jail. Do not pass GO. Do not collect 200
pounds.

Plain English has the phrase GO TO, and makes very good use of it.
Don't be a programming snob.

Computer literacy is the ability of a computer to understand English.

d

Pearce Consulting
http://www.pearce.uk.com

Reg opines as if his opinions have merit. They don't.

...Jim Thompson

 

[R.Lewis]

GOTO's are a positive menace. Any language which allows them is a disgrace
to mankind's considerable acheivements in that direction.

They constitute abandonment of essential discipline to complete chaos in
program structure. Helpful only to lazy, soltitary, so-called programmers,
obtaining money under false pretences, who are unable to remember what its
all about the next day. But GOTO's are wicked, useless, obstructions to
bug-finding and maintenance operations carried out by poor unfortunate later
workers who get all the blame for the enormous costs involved.

I first went on a 2-day computer programming course around 1962. Language
was un-named. But there was no GOTO. Never since been on such a course. The
computer was contained in a 5-foot, by 3-foot, by 2-foot case using discrete
transistors. About as sophisticated as a present-day pocket calculator. The
input/output device was a teleprinter using ticker-tape.

So I ought to know!

At the age of 79 and still programming, my favourite language is still the
well-disciplined Pascal. It doesn't have a GOTO instruction except the
in-offensive GoTo(X,Y), where X,Y is a screen coordinate ready for writing
or printing.

The most easy to understand language, of course, is Plain English. We are
still waiting for a compiler. Our Eastern friends, the hard-working
Chinese, look as though they may beat us to it!

Nothing wrong with Pascal - it just aint that popular- but it most certainly
does allow conditional operations. (The odd prog.may be constructed as a
simple linear, single step, coding but they will be few and far between).
Just because something isn't labelled as a GOTO it doesn't mean that a GOTO
has not been constructed.
However if your understanding of the processes involved is so poor you
probably think that GOTO is unnescessary without realising why it isn't so.
A number of silly fantasies such as this grew up in the very early days of
software.

It is possible to never ever use the word NO in the english language (should
it be so desired).
It is not practically possible to avoid expressing a negative reply to a
question,request, etc.
There may, under different circumstances, be more erudite ways of saying NO,
but not always, and *always* it is a construccted NO.
One must be carefull that the construction is not the more complex and hence
the more prone to mis-interpretation (or should I say erroneous
programming).

Regards,

 

[Ken Smith]

www.rsinc.com

 

[Joel Kolstad]

GOTO's are a positive menace. Any language which allows them is a disgrace
to mankind's considerable acheivements in that direction.

You can call them different things, and provide some structure around their
exact operation, but GOTOs are still around in pretty much all languages.
Prime example: Exception handling. In C++, for instance, the whole
try/catch/throw business amount to (try something) (if there's an error,
GOTO the catch statement).

This argument always boils down to... how much do you trust the programmer
when you design a programming language? You can use the logic that, hey,
99+% of the time there's no really good need for a goto, and plenty of poor
programmers will use it when they shouldn't, so let's just not have it in
the first place. Fair enough, and you'll get plenty of takers, but
personally I prefer languages that give you twice as much rope as you need
to hang yourself, rather than those where I'm only given enough rope such
that 99% of my foreseeable needs are met.

 

[Ken Smith]

GOTO's are a positive menace. Any language which allows them is a disgrace
to mankind's considerable acheivements in that direction.

Variable assignment, looping constructs and the case statement are just as
dangerous. You can directly convert any GOTO ridden code into a loop
containing variable assignments, and a case statement. The result is no
easier to understand or debug.

 

[Ken Taylor]

GOTO's are a positive menace. Any language which allows them is a disgrace
to mankind's considerable acheivements in that direction.

They constitute abandonment of essential discipline to complete chaos in
program structure. Helpful only to lazy, soltitary, so-called programmers,
obtaining money under false pretences, who are unable to remember what its
all about the next day. But GOTO's are wicked, useless, obstructions to
bug-finding and maintenance operations carried out by poor unfortunate later
workers who get all the blame for the enormous costs involved.

I first went on a 2-day computer programming course around 1962. Language
was un-named. But there was no GOTO. Never since been on such a course. The
computer was contained in a 5-foot, by 3-foot, by 2-foot case using discrete
transistors. About as sophisticated as a present-day pocket calculator. The
input/output device was a teleprinter using ticker-tape.

So I ought to know!

At the age of 79 and still programming, my favourite language is still the
well-disciplined Pascal. It doesn't have a GOTO instruction except the
in-offensive GoTo(X,Y), where X,Y is a screen coordinate ready for writing
or printing.

The most easy to understand language, of course, is Plain English. We are
still waiting for a compiler. Our Eastern friends, the hard-working
Chinese, look as though they may beat us to it!

English has a GOTO - Goto Hell, or even more colorful ones in
Australian......

Ken

 

[Rolavine]

Subject: Re: GOTO's

From: [email protected] (Ken Smith)
Date: 1/18/05 3:13 PM Pacific Standard Time



Variable assignment, looping constructs and the case statement are just as
dangerous. You can directly convert any GOTO ridden code into a loop
containing variable assignments, and a case statement. The result is no
easier to understand or debug.

I recently wrote a Visual Basic 6 test program, and I used one goto to loop the
sequence of tests back to the top to wait for the next circuit board to be
installed. This main loop called the subroutines that did the actual testing,
however it was still about 200 lines of code long, with another couple of
hundred lines of comments. In this case the Goto seems to make more sense than
ending the sequence with the end of a looping construct, because the statement
"goto next_test_start" is far more descriptive than a something like a Wend
with a comment.

Visual basics statement are almost like Pascal, if you set the variables to be
explictly defined. Really not very different at all, other than all the crap
that is added to make the program driven off screen objects.

Rocky

 

[John Larkin]

I *hate* the punctuation marks C uses now! I much prefer begin/end to
{}. It's easier for my eyes to find words.


That would make overloading the functions easier, but do you really
want M$ to overload '/' like Intel did? ;-)

No, it would be more proper to have all math operations be declared
external subroutines:

Div_Int_By_Float(*var1,*var2)

like 'printf', evolving towards a pure, ideal language that does
nothing itself at all.

John

 

[John Larkin]

There have been some attempts at "structured assembler" with 'for' and
'while' type kluges, generally by use of a simple preprocessor or a
bunch of weird macros. This makes debugging especially silly.

John

 

[keith]

|
C|
C|
C|
|
(created by AACircuit v1.28.4 beta 13/12/04 www.tech-chat.de)

See?

Damn! I wish I'd thought of that! ;-)

 

[Ken Smith]

No, it would be more proper to have all math operations be declared
external subroutines:

Div_Int_By_Float(*var1,*var2)

Better yet:

float Div_Int_By_Float ... etc

I think the routines should be in the form of "optionally inline
routines". The compiler could be made to expand the routines like macros
or call them. This way the optimizer can slim them down for speed.

I'd include all of the operators not just specifically the math ones.
This way, you could have range checked versions of the assign,
dereferencing and indexing operations.

 

[Ken Smith]

There have been some attempts at "structured assembler" with 'for' and
'while' type kluges, generally by use of a simple preprocessor or a
bunch of weird macros. This makes debugging especially silly.

Somewhere (perhaps on a disk that is not installed in my PC anymore) I
have a bunch of macros I made for the turbo assembler that did structured
stuff.

They were only slightly silly. They did allow programs to be written
without actually using a jump instruction. All they really did was
convert the IF_COND into a jump of the inverse sense and stuff like that.
It was a useful exersize that didn't make a useful result. It did prove
to me that it could be done.

 

[Rich Grise]

Do you mean that it isn't obvious from the source code that it works right
for all non-zero results. If the answer would be zero, it fails on a
divide by zero. If not it gives the right answer.

Well, as usual, if the problem requirements had been clearly stated from
the start, this problem wouldn't have arisen.

'p' or 'q' can be zero but not both. If both are zero, the answer should
be zero but the code fails. For zero inputs, I can work out the answer in
my head so this limitation of the routine is not an issue unless we are
turning it into a function to be called.

This wasn't specified in the original post. Coding this is almost trivial.

Yes that and debating over silly issues while ignoring the real problem
that no-one has really written a good language for engineers. All the
existing ones have major short comings.

Again, it depends on what you're trying to accomplish. I designed a bank
of Sallen-Key filters using a spreadsheet once. When the only tool you
have is a hammer, all problems start to look like a nail. ;-)

Cheers!
Rich

 

[Rich Grise]

Well, isn't obvious that it is always the case that the user did something
wrong. They either entered bad values or they ran a program that crashes,
both of which are their fault.


All seriousness aside:
I was more interested in showing the style and flavour of Pascal than the
details of a program. I used a useful program as an example because it is
often easier to grasp things with real examples.

Oh, heavens! That settles it then! C is better.

Cheers!
Rich

 

[Pig Bladder]

GOTO's are a positive menace. Any language which allows them is a disgrace
to mankind's considerable acheivements in that direction.

Religion for the 2000's: AntiGOTOism, second only to antismokerism in
popularity and venom.

 

[Pig Bladder]

Oops, I guess I scooped up about $40 million under dishonorable
conditions. I should give it all back, I suppose.

John

How'd you like to swing by Whittier, and spill 0.1% of it?