OT: Arithmetic order of operations

Oceanographers still use Fortran because of the massive library built up of subroutines that are just plug-in and play although half a century later

No, but half of my degree project was programmed in FORTH (the other half was in Pascal).

So do most programmers.

In assembly language, every branch is a GOTO.

I found it very useful, admittedly a long time ago in the days of 8-bit micros. Working on embedded systems with limited resources, a tiny Forth interpreter could be built into each system so that with only an attached serial terminal you had an interactive development and test environment. You could build little test words to exercise basic functions one at a time and gradually build them into the complete system function. Those little test words would still be there in the final system and could be used for diagnostics and testing.

A second serial line from each system could be connected to a computer (a port on a shared PDP-11 usually) to download developed code so you didn't have to type it in every time before it got ROM'd.

'Twas fun, and much cheaper than an emulator for each system.

nib

FLUELLEN: If the enemy is an ass and a fool and a prating coxcomb, is it meet, think you, that we should also, look you, be an ass and a fool and a prating coxcomb, in your own conscience now?

I'm pretty sure that as far back as the Z80, Zilog included CALL and RET instuctions that call and return from a subroutine, automatically incrementing, pushing and setting the Program Counter during a CALL and popping the Program Counter during a RET.

plural noun: parentheses

1. a word or phrase inserted as an explanation or afterthought into a passage which is grammatically complete without it, in writing usually marked off by *brackets, dashes, or commas*.

Parentheses in this context is highly ambiguous.

Yes, in common usage its a poncy way of saying 'brackets' but brackets is unambiguously these ().

FORTH and Fortran have nothing to do with each other (I used Fortran until

Of course. But the danger is Assembler is the temptation to use it at random. Learning not to is what I was referring to.

Fluellen was obviously referring to our Motor-Mouth Deputy PM.

Yes, That always amuses me about the 'goto is EVIL' fanatics.

The problem is they learnt that from academics who have some weird idea that 'structured programming' is some ideal bug free methodology.

In the end the only criteria is readability.

Sometimes goto's make a program far far simpler.

Indeed C includes the statements 'break' & 'return' as well as longjmp() and goto as means of unconditionally breaking program flow.

The case statement is full of explicit gotos

e.g. case x:......

...break; //explicit go to end of switch statement case y....

Which is easier?

int x() { if (p ){ // 400 lines of indented code } } or int x() { if (!p ) return; // 400 lines of unindented code }

Of course, but how is that relevant?

CALL ADDRESS is simply

PUSH IP, JMP ADDRESS in one instruction

and RET is simply POP IP in one instruction

Are you trying to make the point that a call is actually a GOTO?

In fact every single CPU code is a GOTO (next instruction, or somewhere else)

Not bug-free, but bug-reduced.

criterion.

Implicit, Shirley. The point being you just put the break; in and don't have to worry that you mistyped the destination label.

The latter, obvs, which is what I therefore do. Trouble was that Pascal, as originally conceived, didn't have a Return statement. You use the former if you are a single-entry-single-exit fanatic.

Anyway Pascal was intended as a TEACHING language, rather than a PRODUCTION language. Trouble was, it bred a generation of graduates who thought it was the bees-knees but who had to extend the original language for it to be in any way useable in a real-life context. This led to a plethora of incompatible Pascals.

Really the efforts made by whoever it was that created all these compsci languages was to impose a way of thinking on the programmer.

Anyone can write good clean structured assembler and they can also write incomprehensible but fully structured PASCAL as well.

I was taught by more experienced programmers that thinking logically and having self contained blocks of code, carefully documented' was far more important than following some abstract set of principles.

And the ability to abort completely and utterly when some fatal flaw was encountered 15 levels deep in subroutines without having to return an error code all the way up the chain was the only time I used longjmp() outside building a multitasker.

No explicit. Break is an explicit statement

As indeed is a curly brace

But that *is* an abstract set of principles :-)

But not CODING principles. THINKING principles

There is the code, and there are the comments. One is an instruction to a CPU, the other is the specification of a human.

The stupidity of compsci academics was to try and make the code 'self documenting'

My presumption is you're associating your own character with a Welsh Captain attracting mockery over their own pedanticism.

While I agree you are technically correct when it comes to programming languages, BODMAS is still taught in all UK primary schools and it seems fitting to stick to the list it conveys.