GCC 15 is close: COBOL and Itanium are in, but ALGOL is out

Version 15 of the GNU Compiler Collection is getting close to release, and as it does, some changes are not going to make it. The latest status report isn't hugely informative, but says that it's "open for regression and documentation fixes only". The report shows there are just 17 priority-1 bugs left. One major new feature …

[MarkMLl]

ALGOL-68 is out

ALGOL, i.e. -60, was never in: and they're very much different.

However an interesting question is whether The Unisys (nee Burroughs) implementations of ALGOL hew to the -60 or -68 language: I've got limited time to delve into the manuals right now.

I was, however, looking at a 1970ish Burroughs ALGOL compiler a couple of days ago and noticed that they'd not adopted a trivial tweak to the language to eliminate the notorious "dangling else" issue: and that tweak was published by the CACM as "Revised Report on the Algorithmic Language ALGOL 60" in 1963.

So extrapolating from that unfortunate example I'd expect them to still be using ALGOL-60 "warts and all", and a very quick perusal of their ALGOL manual dated 2023 appears to confirm that.

https://public.support.unisys.com/aseries/docs/ClearPath-MCP-21.0/86000098-519/86000098-519.pdf 4-61 p259

with their systems programming language NEWP being structurally similar.

So while ALGOL-68 remains of broad interest to language history nerds, only its influence- on Ada, PL/SQL and so on- is really relevant.

[nijam]

Re: ALGOL-68 is out

> So while ALGOL-68 remains of broad interest to language history nerds, only its influence- on Ada, PL/SQL and so on- is really relevant.

Actually, Algol-68 was a fairly clean language that addressed some of the hidden assumptions about type abstractions in more widely-used languages. I'm fairly sure it was never a real influence on Ada and that like, or they would have been the better for it.

And yes, I too was taught Alogol-68 in a formal progrmming course, and it left me uncomfortably aware of the defects in every language I learnt subsequently.

[MarkMLl]

Re: ALGOL-68 is out

> I'm fairly sure it was never a real influence on Ada and that like, or they would have been the better for it.

That authors of the "Minority Report" on ALGOL-68 i.e. Wirth et al. were contracted by the HOLWG to advise on the early stages of Ada development.

As such, even if they didn't like what ALGOL-68 matured into, they were well-informed on the issues that needed to be addressed by any successor to ALGOL-60.

[swm]

Re: ALGOL-68 is out

In college I wrote an ALGOL-68 compiler. I was at the December 1968 meeting that "finalized" the report. It is a fairly clean language with a garbage collector (although the specification didn't require collecting everything but it could have). It had a strict type system and clarified many type issues. The two-level syntax made the standard somewhat hard to read until you got used to it.

All in all, I thought it was a step forward in language development.

It answered the question as to why you can write:

x := 2

but not:

2 := x

I did not write all of the transput though.

[Scene it all]

Re: ALGOL-68 is out

I once worked on the Bliss compilers at DEC. That was a language in which "2=X" made perfect sense but you probably would not like the result. It means "Store the address of X into memory location 2." Maybe if you were setting up interrupt handlers that would be OK, and Bliss was targeted at applications like that.

[rafff]

Re: ALGOL-68 is out

Re Burroughs "Algol 60"

I once had a job writing a translator from Burroughs Algol to PL/1. As I remember it (it was a long time ago) the Algol dialect was somewhat weird, with instructions for extracting bits from the OS' memory, and a very strange IO system.

[Yes Me]

Re: ALGOL-68 is out

Are you by any chance confusing Burroughs Algol, which was very close to the original Algol 60 report, and ESPOL, which was Burroughs system programming language based on but extended from Algol, which they used instead of assembler to write the operating system?

I have in front of me the 1973 "Algol Primer for Burroughs B6700" by de Souza and Manley of Otago University, and the I/O doesn't strike me as strange. There's no memory access as such; that definitely existed in ESPOL but I don't have an ESPOL manual.

[MarkMLl]

Re: ALGOL-68 is out

> I have in front of me the 1973 "Algol Primer for Burroughs B6700" by de Souza and Manley of Otago University, and the I/O doesn't strike me as strange. There's no memory access as such; that definitely existed in ESPOL but I don't have an ESPOL manual.

Even at the application level, Burroughs ALGOL was a bit odd because they'd borrowed FORTRAN-style format notation. And code written by Burroughs themselves often grouped all the formatting in a table at the start of the deck, which could make it very difficult to follow.

There's ESPOL documentation at Bitsavers.

[MarkMLl]

Re: ALGOL-68 is out

> I once had a job writing a translator from Burroughs Algol to PL/1. As I remember it (it was a long time ago) the Algol dialect was somewhat weird, with instructions for extracting bits from the OS' memory, and a very strange IO system.

That sounds suspiciously like the B5700, which had a completely separate set of "stream instructions" for character processing which- apart from anything else- bypassed all memory protection.

I take it that you're aware of Paul Kimpel's emulator.

[Ian Mason]

Re: ALGOL-68 is out

Boroughs algol was always a direct algol 60 descendent. Not a hint of '68 to it.

[MarkMLl]

Re: ALGOL-68 is out

> Boroughs algol was always a direct algol 60 descendent. Not a hint of '68 to it.

But that does not necessarily apply to whatever's currently being shipped by Unisys, which is why I checked.

[Anonymous Coward]

Re: ALGOL-68 is out

> "ALGOL-68 is out, ALGOL, i.e. -60, was never in"

Yes, but if ALGOL-68 is the failed successor to a once-popular-but-long-obsolete language, and was itself never widely-used in the first place (regardless of its academic importance), it seems odd that it- particularly- was one being considered for inclusion (even if it ultimately wasn't) when countless other more common and better-known languages weren't?

[Simon Harris]

Algol-68 is the only language that I've been formally taught. When I started university in 1982 to study Electronic Engineering, we had to do a 1 term course in programming and, the university having an ICL mainframe at the time, Algol-68 was the language of choice.

It was the Algol 68-R version produced by the Royal Radar Establishment, with user guides produced by the Ministry of Defence.

I have never used it since. Every other piece of programming I did in my university days was either BASIC, Fortran or assembly code.

[Gene Cash]

When I did community college (2 year institution between high school and university) we did FORTRAN and COBOL on an Xerox punchcard machine. I've never used either language or punched cards since.

We were graded on number of runs: 1=A, 2=B, etc. I dodged this by using RPG to print a listing of my cards to proofread. I got a "talking to" but I successfully argued that it was a legitimate workflow that had not been ruled illegal.

I also find it amusing that on my Devuan machine, freecad, libreoffice, and gimp-gutenprint eventually require libgfortran5 through a series of dependencies. e.g. gimp-gutenprint -> libgimp-3.0 -> libgegl-0.4 -> libumfpack6 -> libgfortran5

[Gene Cash]

The magic on Debian to show a dependency graph:

apt-rdepends libgfortran5 --state-follow=Installed --state-show=Installed -d -r | fgrep -v "size=" | fgrep -v "concentrate=true" | dot -Nmargin=0.03,0.02 -Grankdir=LR -Nheight=.1 -Nwidth=.1 -Nfontsize=8 -Tgif -o /tmp/graph.gif

[An_Old_Dog]

Proofreading Punched Cards

I learned FORTRAN in high school via a book; punched card decks were submitted via our math teacher to an IBM 1130 at a local college; they had an offline, punched card accounting machinery (PCAM) device, plugboard wired to produce an "80/80" line-printer listing for proofreading.

In uni, the magic phrase, COPYSBF, INPUT,OUTPUT under KRONOS, and later, NOS, got us the same result.

(COPYSBF c.f. COPY Space Before, to add a line-printer carriage control character in front of each line. This leading space resulted in single-vertically-spaced lines.)

[MartyHeyman]

Re: Proofreading Punched Cards

Ahh ... fond thoughts. There was an 1130 in the corner somewhere when I started with IBM in '67. Fun machine. I think I/we ran PLANCODE on it (early spreadsheet-like software).

Kronos is another lost treasure. U. Minnesota gifted me hours on theirs when we were talking about whether IBM had an alternative. I loved Kronos. And IBM did not have a viable alternative in spite of all my bosses insisting otherwise.

Thanks for a moment of happy nostalgia.

[Anonymous Coward]

RE: I've never used ... punched cards since.

I use punch cards every night. I built a night stand out of punch cards while I was at University. Was upcycling a word in 1979?

It's hex shaped on the top and bottom with a smaller hex column between them. And a pull out drawer for my glasses. Only made with punch cards and white Elmer's glue.

[that one in the corner]

> Algol-68 is the only language that I've been formally taught.

Ah ha, we have an expert among us! Come in, come in, welcome to the party.

Um, do you think you could take a look at this? (lifts fanfold to show a nasty little rash of syntax errors) I looked it up on the web and I may have twisted a W-grammar.

[Martin Gregorie]

I had a brief bout of Algol68R and liked it

..but my first programing experience was with Algol 60 of Wellington Universitiy's Elliott 503, back in 1968 before I joined the ICL Service bureau in Wellington.

In 1967 I was supporting George 3 on the British Steel Lab's 1904 in Battersea when we installed the RSRE Algol68R compiler, so of course I had to learn enough of the language to check the compiler out out. I soon found out that I liked A68R a lot and found it was very little harder to write than Algol60.

Soon after that we discovered that the George 3 Job Accounting program was getting crashed by some of the jobs the Lab was running: because these job logs were so long that they caused the G3 job accounting system program to overflow RAM, at which point its execution pointer would wrap to zero before overwriting the accounting job's accumulators, address pointer,etc and crashing the accounting job, which was, like most 1900 G3 support utilities, written in PLAN. My solution was to rewrite the job accounting program in Algol68, which resulting in a fairly small and rather quick program which solved could handle the longest job logs at that time.

Shortly after that the contract ended and I hopped in my series 2 Landrover station wagon, together with my GF, her daughter, and an Australian nurse and headed for Kathmandhu in Nepal (via the Hippy Trail and Kanyakumari - the southernmost point in India, Calcutta and Darjeeling and then back after some Himalayan trekking and the HippyTrail again. This got us back to the UK after 10 months and an estimated 40,000 miles of travelling. The return trip happened soon after the first Afghan revolution and almost exactly 12 months before the Shah got tossed out of Iran (and his secret police switched allegance to the Ayatollah).

Once back in London, I revisited friends in the Battersea Lab to discover that there had been a bug in the Algol68 accounting program. This was never fixed because my G3 replacement guru couldn't or wouldn't learn Algol68R and had also accidentally(?) erased my A68 program's source!.

[martinusher]

Re: I had a brief bout of Algol68R and liked it

>and had also accidentally(?) erased my A68 program's source!.

I've met this sort of thing during my working life a handful of times. Its definitely not a trick of the light, instead I've tried by never figured out the motivation for doing this. (Personally, I'm more like an amoeba -- anything good that's out there & I'll absorb it.)

The 68R compiler was a very practical subset of Algol. Very easy to use, very logical (especially given the year) and it leaves you a bit jaded about most other languages -- you use them because that's what's needed but you just don't believe in them!

[UCAP]

OMG - COBOL

As a post-grad research student in the 1980s, I spent 3 years taking tutorials on COBOL for both under- and (MSc) post-grads. That got dumped on me since I was the only person in the CompSci department other than the lecturer who gave the COBOL who actually new anything about the language (or at least, the only person who would admit to it).

Just so the students know what was about to hit them, I would start the first tutorial comparing a C "Hello World" program against the corresponding COBOL programming.

[Martin Gregorie]

Re: OMG - COBOL

There are MUCH worst programming languages than COBOL - RPG and FORTH to name just two of them.

[rafff]

Re: OMG - COBOL

COBOL and RPG are both very good at what they do, but neither is intended for writing compilers or OSs. RPG, in particular, does a job that is hell to program in C/C++/Java; the skeleton that you have to wrap around the actual guts of the report generator is many times the size of the actual job.

FORTH, on the other hand, is a mathematician's delight but a programmer's nightmare.

[that one in the corner]

Re: OMG - COBOL

I, for one, was overjoyed to get hold of the Forth-83 ROM for my BBC Micro. So much easier than loading the cassette Forth into the Atom and '83 had a round-robin task scheduler, great fun. A lot easier to write library code in than BASIC, even BBC BASIC.

But then again, I also enjoyed using the microProlog ROM so was clearly having a masochistic streak at the time.

[An_Old_Dog]

Re: OMG - COBOL

You can create a nightmare in COBOL via the ALTERS ... GOTO construct. (I've never used it.)

In Forth, the nightmares come from programs written by programmers showing off how "smart" they are by their changing -- inside their program! -- the way the compiler works.

[jlturriff]

Re: OMG - COBOL...via ALTERs ... GO TO

So true. At one of my early jobs I was tasked with maintaining one of these monstrosities. Fortunately it worked reliably, if obscurely; otherwise I probably would have done more harm than good trying to modify it.

Later versions of COBOL allowed an ALTERed GO TO to have a null target, which at least made it a bit easier to recognize what was happening; the older versions required a paragraph name on the GO TO, so recognizing its ALTERableness was difficult.

At another job I inherited something similar but even worse: an Assembler program whose author had obscured its logic by using EQUate directives to refer to branch instructions and modifying said instructions the way ALTERs do in COBOL. The combination of EQUates and modified branches made it just about impossible to figure out what it did. :-(

[Roland6]

Re: OMG - COBOL

I’m not sure I would wish to write an OS in Algol 68. My understanding is that Algol 68 was/is more of a language that harnesses OS features such as heaps and garbage collection.

[gnasher729]

Re: OMG - COBOL

I love Forth. I also have a book about Forth programming. Every few years I open it, read a few pages, and I hate Forth. Then some time later I love it again. I’ve even written about 20 lines of Forth code at some point.k

[Roland6]

Re: OMG - COBOL

>” I would start the first tutorial comparing a C "Hello World" program against the corresponding COBOL programming”

I presume you would startle second tutorial with a COBOL program and compare that against the corresponding C programming ie. Demonstrate when COBOL is used for what it was intended it can be concise etc.

[Madre O'Fender]

Re: OMG - COBOL

Upvoted for the recognition.

I would have been one of those who wouldn't admit to knowing anything at all about COBOL.

Which wasn't entirely true, COBOL did take up one stream of lectures ("Business Computing") for a semester of my 1970s post-grad CS course, and taught me everything I'd ever need to know about it.

Which was that I never wanted to see it again, and therefore should not mention it in polite company, or on my CV.

[isdnip]

I'm not an actual programmer though I know a bit of the history. ALGOL-68 is not the an update of -60, but a different language. Lots of interesting ideas but not deemed practical. Apparently it was hell to write a compiler. A friend of mine in the 1970s was working on a language, MARY, which was described as an implementable version of ALGOL-68. But it didn't catch on either. Instead we get most stuff in C, which combines the power of assembler with the ease of use of assembler and the security of assembler.

People raised on C and that type of minicomputer systems-programming language do not get the beauty of COBOL, which was purpose built to do boring work and does it pretty well. It just can't be used to do fun stuff. It does however pay the bills, quite literally, including the decimal (not floating point!) arithmetic.

[Vincent Manis]

Although I was never actually involved in the ALGOL-68 effort, my grad supervisor was one of the Editors of the Report, and so I know a fair bit about it. It was not “hell” to write a compiler for it, as long as you made a few minor restrictions, none of which really harmed any real program. The compiler my friends were working on was never finished, because it refused to make any of these restrictions, so for example, it had to compile “(...50-pages-of-code...)” correctly. Not only that, but that compiler was written in Wirth's horrible worse-than-assembly-language PL360!

There were two major blunders in ALGOL-68: first, the ghastly two-level syntax used for description was impenetrable to anyone trying to learn the language, resulting in syntax rules with names like “SOID NEST2 out CHOICE STYLE clause” (I picked that one at random from the Report, and, yes, capitalization was significant), and second, there was no concrete syntax, meaning that programs were almost automatically not portable between implementations. The former was remedied by Lindsey and van der Meulen's “Informal Introduction to ALGOL-68”, the latter was never remedied.

One additional blunder was only apparent several years later. ALGOL-60 had no I/O, which everybody realized was a disaster (implementations from Univac, CDC, Burroughs, and IBM added their own custom I/O). So the designers of ALGOL-68 created an elegant “transput” library (they did like to speak in neologisms), which was firmly anchored in punched cards and line printers: a file was a 3D array of characters. This at a time when operating systems, starting with Unix, began treating files as a 1D array of bytes. A very uneasy fit!

Even with all these mistakes, ALGOL-68 was a significant contribution to programming languages, and doesn't deserve the condemnation and contempt sometimes heaped upon it. Still, even though I somewhat disagree with the authors of the Minority Report (Dijkstra, Wirth, Hoare, et al) about ALGOL-68, I do agree with Tony Hoare that ALGOL-60 was “not only an improvement on its predecessors, but also on nearly all its successors”.

[that one in the corner]

> the ghastly two-level syntax used for description was impenetrable to anyone trying to learn the language,

I found myself reading the Wikipedia page on W-grammars earlier today and I remembered why my lecturer thought I'd be intrigued by it; little things like

> The consistent substitution used in the first step is the same as substitution in predicate logic, and actually supports logic programming; it corresponds to unification in Prolog

Yay! Your grammar representation is insanely powerful, could itself be used to write complete programs (but not in a form that most programmers were used to) and, as a formalism for defining a language, having your grammar being formally undecidable is - not really appreciated. Yes, you want something more powerful than Backus Naur, but it is posible to go too far...

The only ALGOL variant I've actually coded in (so far - the compilers mentioned in TFA are in the notebook, one day, Real Soon Now) was SIMULA-67, which was great fun. Shame I never got to use in the outside world, but it was a good introduction to OOP.

[An_Old_Dog]

Control Data Corporation ALGOL-60

Having learnt (and mostly-forgotten) the CDC version of ALGOL-60, I do remember being annoyed that I had to type keywords 'IN' 'SINGLE-QUOTED' 'UPPER-CASE' 'ONLY'.

Was it only the CDC version which had that restriction?

[IvyKing]

Re: Control Data Corporation ALGOL-60

It might very well have a CDC only restriction. The 6000/7000 series machines were not amenable to 7 or 8 bit characters, hence the upper case only restriction imposed by 6 bit characters. String processing on those beasts was -um- interesting, though SNOBOL worked fine.

[jlturriff]

Re: Control Data Corporation ALGOL-60

In the days of punch card computing, IBM's and NCR's compilers (I don't know much about other vendors') only recognized uppercase letters because their keypunch machines could only directly produce uppercase letters (there were no Shift keys on keypunch machines); e.g. pressing the alphabetic keys on an IBM keypunch produced 12-1, 12-2, 12-3, ... hole combinations for A, B, C, ...; to make lowercase letters one would have to re-punch the card with additional 0 holes (12-0-1, 12-0-2, 12-0-3, ...), and there was no easy way to do that.

Even today, example code in manuals for many of the older languages put the words that the compiler recognizes in all caps and variable names in lowercase, and a lot of programmers of those languages do that as well, though it's more sensible to do the opposite because the variable names should stand out.

As terminals took over from punch card for writing code this restriction quickly disappeared, and (on IBM systems, e.g.) languages like Rexx superceded EXEC. It took a bit longer for IBM's COBOL and FORTRAN compilers to get that capability, and to also get rid of the 80-column restriction (which is a welcome relief in COBOL with its long variable names).

[Roland6]

Re: Control Data Corporation ALGOL-60

>” example code in manuals for many of the older languages put the words that the compiler recognizes in all caps and variable names in lowercase, and a lot of programmers of those languages do that as well, though it's more sensible to do the opposite because the variable names should stand out.”

Interesting and valid point: do you emphasise the control flow (“algorithm) or the data structures in your program?

[Vincent Manis]

Re: Control Data Corporation ALGOL-60

I never used IBM OS/360 ALGOL-60, but I was recently looking at its language manual on Bitsavers, and it too required apostrophes around key words. I did use an ALGOL-60 system on the IBM 7044 in the late 1960s; it too required apostrophes, but also the keywords were in French, as the compiler was written at the Université de Grenoble. One said 'DEBUT' X := X+1; Y := Y/2 'FIN'.

I should point out that lower case in those days was not an option. The character sets used prior to the mid 1960s, such as BCD and Fieldata, were generally 6-bit, and simply didn't have room for iit. And even the world moved to 8-bit bytes (7-bits on PDP-10), the printers couldn't handle them: a 63-character print train on an IBM 1403 printer could print substantially faster than a 95-character train. I remember well into the 1970s having to specify special job status, and worse turnaround, for jobs requiring lower case.

[Vincent Manis]

Re: Control Data Corporation ALGOL-60

Edit: according to the IBM 1403 manual on Bitsavers, the TN print train had a 120-character set. I would therefore expect it printed at half the speed of the standard 60 (not 63) character train.

Ancient technology is so amusing!

[jake]

Re: Control Data Corporation ALGOL-60

My 1403 with the TN chain[0] runs at the same speed as when it's running the ALL CAPS chain I use for PL/I ... Depending on the actual characters being printed, of course.

[0] No typo, she's an early 1401 from before the train upgrade. She started life as a Model 1 and was field-modified (by IBM) into a pseudo Model 3 in about 1974. If you squint, she kinda acts like an N-1, but without the fancy sound deadening. She does about 23 pages (~1400 lines) of 11X14 (132 columns) per minute. Can crank up to over 6 feet per second if the printout contains a lot of blank lines. She can empty a box of fan-fold faster than you can kill the print process. That's a joke (kinda), the print buffer is only 140 characters (of core), so killing the process, if you can, stops the printer pretty quickly. Yes, she'll spit out a lovely arc of paper if allowed. Not recommended .... folding it all back up is a pain in the butt, and it's getting expensive (if you can find it).

I don't have much use for her these days, mostly banner printing and old Fortran/COBOL code. I'm going to keep her around anyway, just for the shock value. The silly thing is LOUD at full-chat. If anyone is wondering, I keep her on rubber isolated feet, in a box made of two layers of 1 inch lead-foam with two inches of rock wool in between and a triple-glazed plexi window ... the neighbors are thankful.

[Roland6]

Re: There were two major blunders in ALGOL-68

With hindsight, I suspect other blunders, which has contributed to the side lining of Algol 68 was the need to be taught the language, and that it required some previous exposure to Algol (60) like programming languages.

These considerations probably also impact other languages such as Ada. The question is to what extent Rust is any different.

[BinkyTheMagicPaperclip]

Weeeelll.. I think it's a stretch to call COBOL beautiful - very useful and proficient at specific tasks yes. Annoyingly verbose, although to be fair I never covered it deeply and it's been a long time.

You can very definitely do a lot of fun stuff with it, especially if you use COBOL.NET, and even before then too - it just took more work than using C.

[Roland6]

> Annoyingly verbose

To type, however, if you have ever used a COBOL-to-C translator, a surprising amount of C is produced.

Given the choice I would prefer to maintain the original COBOL to the C version of the same.

[BinkyTheMagicPaperclip]

Doesn't sound particularly surprising to me! COBOL is considerably higher level, and the decimal arithmetic is very useful with fewer gotchas than the delights of floating point..

People have coded games in COBOL, and interfaced to unusual systems, it's just not very common.

[Roland6]

> Apparently it was hell to write a compiler.

I suspect much depends on your experience. I remember Borland discovered C was a very different beast to Pascal, hence the couple of years delay in releasing Turbo C.

I think to attempt to write an Algol 68 compiler, you would need to have a good understanding of the advanced topics in Aho and Ullman dragon books. (Ie. The bits you can ignore when writing a C compiler.)

[Vincent Manis]

No, it really was difficult to write a compiler that complied completely with the Report, because there were strangenesses and no permissible restrictions. I need only mention the difference between the roman and italic dot (yes there really was a difference), or the fact that the compiler my friends worked on had to have an entire pass devoted to deterining how parentheses were used. Make reasonable restrictions, and ALGOL-68 became not much more difficult to implement than any other modern language.

People writing compilers in those days didn't have the Dragon Book, because it didn't exist yet. However, they all knew about the latest and greatest parsing techniques, which eventually went into the first edition of Aho and Ullman. I remember learning about LR(k) and LALR(1) parsing from the papers that introduced these techniques.

[Falmor]

Upvote for a mention of the dragon book. Still have my copy from university around somewhere.

[Ilgaz]

Reading opportunity for all

The https://en.wikipedia.org/wiki/Burroughs_MCP "Burroughs MCP" is a piece of technical writing art on Wikipedia. That OS is really something unique.

[spold]

Algol;

Algol 60;

On an ICL 1902 mainframe;

And the program on paper tape;

Those were the days!

****ERROR Missing semicolon at line 4****

You lot don't know what you are missing! Whippersnappers.

I were programming when you were but knee-high to a grasshopper.

Now CESIL - there was a language.... hey let's have Visual-CESIL++

Is it Friday yet? I think I need a lie down.

;-)

[AGK]

GCC will not be complete until it supports MUMPS.

[An_Old_Dog]

MUMPS

@AGK:

%%$@!&&~

... or something like that. "Friends don't let friends do MUMPS."

[Bitbeisser]

MUMPS is a disease, any way you look at it...

[Herby]

Incomplete GCC

How about supporting BASIC?

Of course someone won't think it is a joke and actually do it.

[Antony Shepherd]

Lords of COBOL

It's easy to forget that COBOL is still a thing.

I wrote one COBOL program back in the mid-80s. I was doing HNC Computer Studies at Barnsley College, using a Honeywell Bull DPS6.

Fast-forward to 2015 when I was going through stuff in my Dad's house prior to its sale, and I came across a listing of that program on wide green-lined fanfold.

I was very tempted to take it with me, but thought better of it.

Apart from 'something to do with divisions' I've pretty much forgotten everything I ever knew about COBOL, or Jackson Structured Programming, for that matter, as I never had to use either again!

[Michael Hoffmann]

I love these threads. They show that fellow Regtards are at least of my own age and in many cases way above that, making me feel like a spring chicken!

I still learned FORTRAN, and even a smattering of PL/1, but never had to do COBOL nor ALGOL (Pascal was already around and the Hot New Thing).

[Marcus A.]

You don't understand real joy until you've used COBOL to run a CODASYL database.

[EricPodeOfCroydon]

Ah... Micro Focus CIS COBOL on the ICL DRS20... those were the days!

[Ian Mason]

The characterisation is unfair

The characterisation of algol 68 as "over-complex" is both unfair and untrue. Any competent programmer could pick up Woodward & Bond's 99 page "ALGOL 68-R User's Guide" and learn and use 99% of the language in a single day. In fact it's gloriously simple and regular, or "orthogonal" as the algol 68 designers liked to describe it.

I challenge anybody to learn 99% of C++, Swift, Go, or Python in the same timescale.

Unloved, probably true, but that just demonstrates how rare good taste is.

[An_Old_Dog]

Re: The characterisation is unfair

It sounds like I'd like reading that book.

Critical question: if I wrote programs using the 99% which I could learn from that book, could I bitten on the ass by my ignorance of the remaining 1%?

[Roland6]

Re: The characterisation is unfair

Writing is one thing, getting the program to correctly compile(*) is another.

(*) in the case of Algol 68 “correctly compile” means all of your logic compiling, not due to mismatched nesting large parts of the source are ignored or treated as comments, so code compiles and runs! ….

Personally, I believe your really need to the taught, as that way you get to understand and better appreciate the world view and power of the language.

[Liam Proven]

Re: The characterisation is unfair

> The characterisation of algol 68 as "over-complex" is both unfair and untrue.

For clarity, I was comparing it to Algol-60 and older languages, not to later ones.

Ian Mason... _that_ Ian Mason? If so, hello, esteemed long-ago mentor!

[jlturriff]

So, just how important is it that GnuCOBOL translates COBOL to C and compiles that to machine code?

And just out of curiosity, who is the developer/maintainer of gCOBOL?

[Liam Proven]

> So, just how important is it that GnuCOBOL translates COBOL to C and compiles that to machine code?

I think -- and do please bear in mind that although I'm nearing 60, all this stuff is way before my time -- that it would matter for complex multi-module programs that call one another. It could also matter if one were trying to put this stuff into a CI/CD pipeline.

> And just out of curiosity, who is the developer/maintainer of gCOBOL?

Both are the team at CobolWorx as far as I can tell. It is possible that's a one-person company, but I can't say for sure.

After a series of acquisitions, these days, Micro Focus more or less owns and controls all the important COBOL compilers for COTS kit.

This is possibly a slight oversimplification, but it looks to me like it's pretty close to the case: if you are running production COBOL workloads, then if you are not building it with IBM tools and running on an IBM OS on IBM hardware, then you are probably using Micro Focus tools.

It looks to me like the 2 GNU COBOL projects, the 1st generation and revamped 2nd generation, are a determined and professional effort, possibly via several levels of obscured sponsorship, to get a real usable production-ready all-GPL Cobol toolchain out there.

GCC is still a very important tool, but the new hotness in building C variants is LLVM and Clang and related projects. That's where the money is going now. Apple uses and sponsors it, all Apple OSes are built with it, Rust is built with it, etc.

Intel used to maintain its own line of highly-regarded high-performance C compilers. For 30-odd years it was the only compiler other than GCC you could build the kernel with. Intel recently dropped them and moved to LLVM, as I reported here:

https://www.theregister.com/2022/10/14/kernel_61_will_contain_fixes/

LLVM increasingly looks like the future, and GCC is heading in the direction of being a legacy tool, a reliable old stalwart.

[that one in the corner]

> It could also matter if one were trying to put this stuff into a CI/CD pipeline.

I'll admit that I've never been involved in anything that was claimed to be "CI/CD", the closest I've come is just having an automated build machine keeping a beady eye on the master source repository and firing off a fresh build whenever there is a commit. As soon as that build is done, everyone would be (able to) use ths outputs. Across various teams and projects, the first using RCS because CVS was still not invented.

In none of those setups, the build would take "generate C then compile the C"[1] in its stride - the worst issue being making sure you knew how many C modules were going to be generated.

Given that, can anyone say if Liam is right and such transforms, generally or in particular with respect to GnuCOBOL, why a CI/CD pipeline would have trouble?

[1] In this context, nothing special about C of course, and the generating pipeline could be anything required: take a Pic file, use it to generate a BMP, convert that to hex and wrap it into a C static array - of course, these days you'd do your watermark logo starting from SVG...

[GNU Enjoyer]

LLVM is not going to be the future.

As weakly licensed software has no future - such software will keep getting made proprietary over and over again until it is destroyed.

Lots of money may give you faster development, but it won't give you freedom.

When it comes to compiling fine GNU software, GCC's simply optimizes better and always will.

[MartyHeyman]

(also [e-mail]) -- COBOLworx is a subsidiary project of https://symas.com, the OpenLDAP guys. The team is part of an 18 person company almost 26 years old. COBOLworx offers commercial technical support for both GnuCOBOL and GCC COBOL.

We joined GnuCOBOL some years ago because we needed an Open Source COBOL for another project. GnuCOBOL's approach of producing C as an intermediate language works well. The binaries are small and fast. GCC optimization is good. But the fact that GCC's code generators think the program iis C causes complexities for debugging (gdb). We hacked cbl-gdb for that some years ago ... it works. The first source level debugger for COBOL.

GCC COBOL is a clean start based on the latest standard (ISO-IEC 1989:2023) and it is a proper front-end. That simplifies gdb support and should improve GCC optimization but that's unproven. There are language features we haven't gotten to (JSON, XML, Report Writer, Object Oriented Programming) but they're in the roadmap, some if not most by GCC 16. We publish frequent builds from our development tree.

Microfocus swept up most of the older proprietary compilers. Then they were bought by Rocket Software. Microfocus is very much the Big Dog on modern platforms. GnuCOBOL can recompile Microfocus code quite handily. GCC COBOL will evolve to be able to do the same.

Re: CLANG and LLVM. GCC COBOL can bootstrap on an LLVM system producing native code to the same application binary interfaces. If there is active development of COBOL front-end for that technology we will follow it closely.

[Herby]

Microfocus Cobol

Just remember: Microfocus COBOL is written in (drum roll) Microfocus COBOL.

Let that one sink in for a while.

[desht]

Re: Microfocus Cobol

The MF COBOL compiler is indeed written in COBOL, but it compiles to INT code, an intermediate form which runs on a virtual machine, mostly written in C.

There's also the code generator which emits GNT code, native code for the platform it's on, with a common object file format across systems, also loaded by the C runtime. That's also written in COBOL iirc, but it's been a long time so I could be wrong on that.

Reference: I used to work on the C runtime.

[jake]

Re: Microfocus Cobol

Into the late 80s. and possibly a hair beyond, Micro Focus Workbench was written in Micro Focus COBOL, but Micro Focus COBOL, not being self-hosting, was written entirely in C.

Source: Some legacy code that I'm asked to help maintain occasionally. Scientific instrumentation sometimes lasts for decades after the sell-by date.

_{Nice work if you can get it ... both fun, and quite lucrative.}

[Anonymous Coward]

Re: Microfocus Cobol

I therefore assume Animator was written in C and used the INT code.