Is it a lost cause?

what stupidity Commercial programming is the raison d etre for programming. anything else is just playing

In your apparently limited experience.

Everywhere I worked, those were Programmer/Analysts.

Separating the functions leads to dis-function.

Perhaps.

Or use a different compiler.

I learnt a lesson from a PPOE which had _really_ high monetary values hanging directly on the correctness of complex computations.

Do TWO systems. With public specs, and public comms protocols, and have verifiers running on all external (and some internal) interfaces.

And don't share a single bit of hardware or software between the two systems.

Nor have the two development teams interact through any private means, have all communications public.

We can actually get there today, with Linux and BSD and carefully selected hardware and tools. Gives the bugs a run for their existence.

-- mrr

Its true enough that it was batch processing in the 70s - necessarily so because, even in 1968, most data was stored on mag tape because of the cost and limited capacity of disk drives. That was when I started: we had a pair 8MB disks and six tape drives. So large master file had to be stored on multiple tapes at somewhere around 12MB per 2400ft x 1/2" reel.

By '71 or so we had a pair of 60MB disks and were running George 3, so we had some terminals: ASR-33 Teletypes plus one 'glass Teletype' so called because although it used a CRT, it wasn't capable of anything more than showing lines of text and scrolling.

However, despite the limited computers, we wrote and ran everything from small payrolls and accounting systems up to the full systems needed by a magazine distributor to handle accounts, magazine inventory, and that used an optical mark reader (remember those?) to record details of magazine deliveries and returns and a paint manufacturing systems the dealt with stock control and the process of paint mixing. This was in NZ.

Depending on your musical taste you may have indirectly met my last large COBOL system. From 1983 until the BBC stopped using ICL mainframes this interactive system handled all the details of program making for Radio 3. As well as maintaining the music and performer catalogues the system tracked program production, from proposal through production, scheduling, initial broadcast and and subsequent reuse. To do this it had to keep track of the licensing details and of every transmission of each and any part of the works in each broadcast. It was popular too -it was originally intended for use by just the 8 people in the music planning office, but producers liked it to and it ended up in 40 terminals.

So much for small, simple COBOL systems, what?

Too right. I remember one who designed a system that was OK through program testing but that proved impossible to run in production. IIRC the data flow between programs was the problem but I had no involvement with that system so I don't know the details.

Yep, but the logic in a lot of these systems can be a lot more esoteric than yo might think, particularly on the sales and order taking side. One system I built for a toy manufacturer had to handle orders denominated in dozens, bakers dozens, double bakers dozens, by the gross, trailer or railcar load - all with their different discount structures. Then there were additional discount schemes, special discount schemes for particular customers and overrides to any and all of this due to face-to-face deals. And, of course, the system had to track salesmen's commissions.

Even the Radio 3 music system had its moments. For starters, many classical music works don't have names (Beethoven's 5th Symphony is one, though the 3rd does [Eroica]) and some works have multiple versions and arrangements of these, so your catalogue had better be able to handle all this as well as dates from 55BC (a piece by Euripides) into the future and had to handle a range of dates of varying accuracy and type (financial quarters and years, birth/death/composition dates of varying accuracy (exact, to the month, just a year, when somebody flourished, the century,...)

Put all this type of stuff together and the system complexity soon builds up.

Now add the type of user, which may have to cover restricted access by person or role of user as well as providing an interface that is equally usable by the people who use it all day, every day as well as the people who only use it once every month or two.

More complexity to build in.

And the whole thing has to provide acceptable response times, as well as being reliable and easy to maintain.

Compilers can still have bugs despite extensive test data collections and continuous build&test tools.

I find it worthwhile to maintain a set of regression test data and scripts for my various libraries and applications. Do you?

Have you ever done any significant COBOL programming? It's not my favorite language, but I've seen (and written) some pretty complex code in it. IME most COBOL programmers are "programmer/analysts"; I've only worked one place that had a separate analyst group, and there the programmers had to do double the work to make sense of the cr@p the analysts generated.

Only after I stopped using code like this (and Cobol entirely) I came up with a scheme to pair a character variable or two with the alterable goto. Whenever the goto is altered you could set the corresponding character var to the blue of the target label. To be doubly sure set a second to indicate where the alter occurs. This should make it much easier to debug.

I worked at CTG before it was CTG (Marx-Baer), and our usual modus operandi was to bid the systems analysis and design. The customer could than hire us to do the implementation, do it themselves in-house, or presumably hire someone else to do it. This was a good guarantee of producing implantable systems, since we'd work on a fixed-price contract to do the implementation.

Paul Strassman has a description of the problems with Xerox COIN distributed order-entry system in _The Computers Nobody Wanted_ (which I almost got pulled into). As I recall the problem is that almost all the salesmen and reps each had a different commission structure, so it almost had to be programmed on an individual basis. At least you presumably got your system to work.

Now Now! stop trolling

In the days when computers cost half a bananas republic's GDP, that might have been the case.

If you look carefully at what I wrote, I said that it was *designed* to do simple programming on large data sets.

That it ended up doing more than that, is not relevant to my original point. Which was that it was designed for a certain task.

AS far as the second comment goes, I lived with a cobol analyst programmer, who was definitely of the opinion that coders had to be given very explicit instructions, or garbage resulted.

She was ex a very large data processing house indeed. Big IBMs

That was the model I was taught as part of my A level in CS back in

Yep that's been the norm for most of my career to date - although there is the occasional outbreak of Architects who produce documents with minimal information content but maximal words and diagrams.

What there is in most larger places is a grading from junior dev, developer, senior dev and in larger places some higher grades (names vary) with the general expectation that the higher up the chain the more you focus on design and the hard bits and the more you mentor those lower down the chain.

As does preventing the developers (PROG/ANAL - had to go) from talking to the users.

Yes, we did. In this case there were special deals for the larger customers, but all the salesmen sang from the same sheet IIRC, though their ability to strike deals that differed from the customer's special deal might have been a problem, in practise the deal entry screen's ability to override the deal sheet seemed to do the trick.

Did you ever do time at Smiths Industries in Cricklewood? This sounds a lot like the way their analysts worked.

At a PPOE with FORTRAN77 thirty years ago, I used ASSIGNED GOTO to simulate recursion. I think one could as easily use CALCULATED GOTO for that also.

me trolling, it was Gareth that made the stupid derogatory (& trolling comment) about commercial programming.

Oh and for clarity my definition of commercial programming is anything in a business environment so:-

software packages to run on users computers (windows, Mac, Linux, OS9, Amigaos, Flex even C64 and BBC Micro Operating systems for new computers Firmware for embedded micro-controllers in products. Computer games

I also do not rule out Open Source, if the individuals or groups are running them in a business like way.

Playing is the sort of hacking I now do at home for my on self gratification & education.

IBM's documentation seems to disagree with you.

That's a fair description of IBM's RPG, but I don't think it was ever true of COBOL.

OK, COBOL was clearly designed around file handling and dealing with formatted data rather than doing scientific or engineering calculations, but apart from that its pretty hard to see and inherent limits to the type and size of jobs it was meant to tackle.

One indication of this is that COBOL has had built-in support for overlay handling since I first learned it in about 1970, while to the best of my knowledge this has never been included in the language syntax of C, the Algols or any languages derived from them.

I'll also accept the argument that COBOL was designed on the, in my view flawed, assumption that there are a bunch of developers who can understand logic written in pseudo-English together with all the implications of MOVEing data between heterogeneous variables but who are totally incapable of dealing with a block structured language using pseudo-mathematical notation.

Can't comment: I've never worked with a bunch of pure coders. Trainees, sure, but that's different.

That said I've also worked with some terrible so-called programmers. T remember one who didn't understand that, in the absence sentences that affect control flow, control falls through from one parahraph to the next. Why else would he write code like this:

PARA-1. NOTE in-line code here. GO TO PARA-2. PARA-2. NOTE still more inline code. GO TO PARA-3. PARA-3. NOTE .... and so ad infinitum.

And another bod who didn't understand the concept of arithmetical error handling. He could not be convinced that a computer could do something sensible with a divide by zero error or result overflow and it was therefore a badly designed machine if the entire mainframe didn't halt when this happened. Small wonder that, on a site rife with nicknames, he was known as 'Brain Cell' because we were certain he only had one.

There is neither stupidity nor trolling to assert that commercial data processing is simple and sanitised for second-rank programmers compared to real-time systems.