The software development process.

Here he is in one of his (I hope) crabbier moods...

I'd love to see some of *his* code.

John

John Larkin wrote: [programming languages, GOTO considered harmful]

For C++, probably, but that's mainly because it's horrible. I seem to recall the author of C++ once saying he never expects anybody to understand all of it (and I suspect that includes him!). Anyway, part of the idea of OO languages is that it doesn't matter how you got there, because it's all neatly encapsulated. You can only get 'there' through one of the well defined interfaces, so you needn't look beyond the few files that define the class, because there are no bizarre interactions, no unexpected entry-points and no curious side-effects from other parts of the code. In theory anyway. Sometimes it even works something like that.

Tim

Sounds like my approach to analog circuit design.

Of course I get criticized for simplistic designs (Bloggs in particular)... no matter that they always work.

...Jim Thompson

In message , dated Mon, 11 Sep 2006, Steve at fivetrees writes

When I first read that I thought it was an instruction!

Think how useful it would be with a good debugger! Just set a breakpoint on the GTSCH instruction, then single-step.

Why don't processors have this instruction?

What was that Western Digital machine that executed Pascal directly? It may have been the only CPU ever made without a jump instruction.

John

Pascal has a "goto" statement.

You aren't thinking of the Burroughs B5500, which ran Algol 60, are you? That's a machine I wish I had known more about. It struck me as being 20 years ahead of its time.

Ah. Western Digital Pascal MicroEngine:

Its native instruction set was UCSD p-code. I don't know if that means there was no jump instruction.

"Jim Thompson" wrote in message news: snipped-for-privacy@4ax.com...

My point exactly. I learned hardware engineering first, and I often think I gained a significant advantage in so doing.

I really really hate debugging, whether in hardware or software. Hardware people, for instance, learned how to avoid races long ago (synchronous design, in order to reduce the important variables down to a handful - i.e. clock rate and setup/hold times). They also learned how to make schematics readable (well, some of them did ;)). Etc. Engineering is engineering, and appropriate methodologies and a big dose of discipline will keep you out of trouble.

I tend to take the view that software practioneers too often see these as "constraints", and re-invent the wheel... by throwing things together and then spending large amounts of time finding out why it doesn't work, and finally releasing something that just about hangs together, except on the

Steve

Hello David,

There is also competition in SW. Not with operating systems though, at least not from a practical point of view. Linux doesn't run some stuff that I need to run. WRT to office, CAD and other stuff I am happily using non-Microsoft products. Because they are IMHO better.

It does? I'm shocked, shocked.

I had a friend working on a PhD in computer science at UCLA. On the final exam, he used a GOTO (this was in C) where it fit perfectly, and it cost him a letter grade.

John

... snip ...

It didn't. It executed the 'ideal Pascal machine' instruction set, i.e. P-code. One of the instructions was 'jump if negative'. Another was 'unconditional jump'.

#define DRAT BombOut( #define BOGUS #define ARGUMENT "The argument was too bogus to use");

DRAT BOGUS ARGUMENT

Taking computer "science" classes is the same as taking social studies... if you don't parrot the instructor you can lose more than just one grade.

I've already told of my "Surely Shirley" episode, where I got "F" in Pascal for using diagramming instead of outlining.

I think I'm going to buy PowerBasic.

Silvaco wants $250/day to lease their UTMOST (device modeling) software.

For that kind of money I'll just write my own iterative equation solver ;-)

...Jim Thompson

In the basic in the ZX80 there were several things you could do:

There was no real checking on the FOR-NEXT nesting so you could do some funny logic flows with them.

The NEXT also would take you out of a subroutine but leave the subroutine return point on stack.

Overeflows were not trapped in many cases.

The line number in a GOTO can be computed

You could assign a string and then parse and react to it on a character by character basis.

In article , John Larkin wrote: [....]

You should use the more modern "COME FROM" statement.

BTW: Any GOTO riddled code can have all of its GOTOs removed by a simple process:

Make the whole code section into a "while" loop around a "switch" statement. The index of the "switch" statement gets modified by each case to select the next statement. The exit is done by changing the variable in the "while" statement.

Start with:

if (a > b) then goto Line1 a = a-b Line1: something(a) exit

end up with:

while KeepGoing switch Index case 0: if (a > b) then Index=2 else Index=1 case 1: a = a-b; Index=2 case 3: something(a); Index=4 case 4: KeepGoing = FALSE end switch end while

This is obviously a process that could be automated.

All joking aside, this is usually a Really Bad Idea. (Exception: where the underlying language or command structure is so weird it's hardly worth learning.)

I've seen this principle in use - well-intentioned, but wrong-minded. It simply adds another level of complexity and won't be appreciated by those who *do* know the underlying language and wish to see it clearly. And as I've said (a fair few times), good C is readable C. (Substitute "C" for your language of choice.) I do realise that not all extant C is readable, but if you're writing it, and know it well enough to wrap another language around it, you're also able to write clear C.

I worked in a dept once where an earlier staffer had done as you describe - he'd turned C into Pascal via a bunch of macros. He wrote quite a lot of code. He left the company. Others took over what he'd done. The dept grew, and the expertise in C of the dept grew. They were still clearing out the last of the macros about 10 years later, and cursing him a lot. They evolved a (very good) coding standard, and stuck to it. It explicitly forbade such foolishness ;).

If you're working alone, of course, it's up to you. But my advice would still be: learn the language, don't wrap it in something else. Life's too short.

Steve

:) :)

I love it. Take ugly spahgetthi code and convert it to socially acceptable ugly spahgetthi code.

I wonder if there's a special level of hell for those who do things like this? ;)

Robert

Ok, so you've broken the code up into virtual lines/chunks, and run a line/chunk despatcher. Man, I'd hate to have to maintain that ;).

(The fact that you've actually used a closed construct was probably for illustrative purposes. If it were not, I'd say that spaghetti code remains spaghetti code, or at least a spaghetti sequence, regardless of how one encodes it.)

Steve