Hacker News Reader

COBOL has a worse construct than this.

ALTER LABEL1 TO PROCEED TO LABEL2

This will cause any gotos to LABEL1 to be redirected to LABEL2.

This is worse than older Fortran's arithmetic IF[0].

[0] https://en.wikipedia.org/wiki/Arithmetic_IF

Metaprogramming. Nice.

It's self-modifying code, which is not the same thing as metaprogramming, which utilizes unexpanded expressions (often macros) which then get expanded in the final evaluation.

The term meta programming in languages like Ruby and many others tends to be taken to include the language ability to dynamically alias (or create) methods at runtime. I don't think I can remember having seen it used to mean something as restrictive as you suggest

I am much happier knowing this thank you

Happy as in happy to never need to touch something like that

Yes it just fills me with appreciation for what I've taken for granted

(although working in javascript of course any function can get redefined at any time so some things never change)

https://en.wikipedia.org/wiki/COMEFROM

But COMEFROM is a joke. Dynamic scope for goto labels is apparently real.

Looks good to me!

That construct is very useful when the memory is measured in few kilowords and the call stack is tiny.

Cobol was first used in computers that are equivalent to $1.5 PIC18 microcontrollers https://www.microchip.com/paramchartsearch/chart.aspx?branch...

yeah, it's funny. This would be like car people (or pick any other group) in forums, pointing to some super popular car made 50 years ago and then making fun/light of all the crazy stuff the best engineers at the time felt was necessary.

Arithmetic IF and COBOL's ALTER statement were reasonable solutions at the time but that doesn't make them any easier to use or understand in the present.

That arithmetic IF sounds really useful for the kind of numerical applications typically written in Fortran. Isn't it only bad because every other language uses IF as a boolean conditional?

Arithmetic IF directly matches a hardware instruction on the IBM 704.

This was the first computer with a Fortran compiler.

IF (VALUE) 10, 20, 30

The three arguments after the value are labels that the program jumps to.

The equivalent of this line in C is something like this:

  if (value < 0)
  {
    goto 10;
  }
  else if (value == 0)
  {
    goto 20;
  }
  else
  {
    goto 30;
  }

Fortran 77 added logical IFs that work like most other programing languages.

You can do that (or worse) in C too.

#define LABEL1 LABEL2

Is there any language that can be worse than a macro and #ifdef-ridden C? I'm only half joking.

#define's are a compile time construct though. I think the parent is describing a statement that alters the runtime location of a label.

Your C #define is done at compile time. This Cobol's alter example [1] seem to do so at runtime. Thus labels can be considered modifiable points. Actually, it's kinda interesting... does it support chains? Alter A->B and B->C, does GoTo A call C? If i now alter X->A then A->D and GoTo X, where do you end up? C? D? Hope you can at least undo that with something like alter A->A. Actually, I probably don't even want to know. Hope using it gives a big warning in whatever tools Cobal devs use.

[1] https://riptutorial.com/cobol/example/19820/a-contrived-exam...

I don't think it is "MOVE NEXT SENTENCE". The NEXT SENTENCE clause is part of an IF statement. COBOL is usually coded with every statement a sentence, terminated with a period. The exception is nested statements (such as IF statements), where you don't apply a period inside the nesting. The NEXT SENTENCE clause is used to exit the nested logic and continue at the next statement after the period.

Of course, your point stands, and this has been a long standing issue for COBOL, especially since a missing or extra period is probably still syntactically correct.

I just finished refactoring a couple of COBOL programs to remove all of the periods from PD code - which is how I prefer it. Can't wait to see how it goes at code review!

https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/...

> Thats right, in a language where everything looks like it's yelling at you, you have to find a little tiny period to find where execution resumes.

In old non-proportional fonts on old CRT screens with low resolution, "." was a pretty noticable glyph. Typewriters tend to have rather noticable periods, too.

That convention truly was a child of its time.

I know that refers to an even earlier period but... it is funny how in telegrams (real telegrams, not the chat application) the period was replaced by the STOP word because it could be often misprinted, because it was really tiny and a printing artifact could be read as a period.

So I think what you said it's true: conventions are indeed children of their times.

Sure, Dijkstra said BASIC ruins you, but this is actually a nice incremental improvement over what your 1980s home computer had to offer.

> you have to find a little tiny period to find where execution resumes. No labels, just a tiny couple of pixel round period.

Totally naive to COBOL here, why do you have to do it? You said you wrote some regexes for the pull and transform, why not pipe the source to a program that finds that period for you?

I don't think it would have been a hassle for him specifically (could always just ctrl/cmd + f....), he's moreso lamenting the fact that this is an actual feature i.e., if you actually wanted to program in COBOL for some reason you'd actually have to deal with this, which makes its inclusion insane.

Yeah, it wasn't an issue of doing CTRL-F, it was about making sense of that flow when the control jumps you multiple screens of code.

The problem isn't finding the destination, its what alternately happened been source and destination.

Also, if your reading on paper, CTRL-F isn't available. You're scanning those pages by hand. When you're sitting there, highlighter and pen in hand to make annotations and point out important shit, its a problem. End up with circles around the periods and arrows point to it with comments like "this is how we got to x from y."

Edit: also if you end up at the same place regardless of the source or from multiple sources. You can't keep the code for a level to find everywhere a jump emds up there.

Or even a simple script that would convert source code from all-caps to the usual normal-language sentences and then back.

Like a different font?

Like

   "sentence".capitalize()

In Python.

In 2003, when I went through this headache, I wasn't even aware of Python. Might have barely made 2.0 at that time.

COBOL programs reside on mainframe computers, an environment that's entirely alien to someone who's used to UNIX-like environments where you have something like a pipe.

I'm not sure how and on which machines COBOL code is written and compiled these days but I reckon that piping it to grep, or similar tools, might simply not be an option on those machines.

FYI on IBM mainframes, MVS has included an integrated Unix environment since 1993 [0]. This continues to be developed and supplied with the latest versions of z/OS :)

Here's someone asking about doing just that:

https://serverfault.com/questions/356574/can-i-run-grep-agai...

[0] https://en.wikipedia.org/wiki/MVS#MVS/XA

(Edited to go back even further than OS/390)

Today they write/edit COBOL programs in IBM WebSphere Studio Application Developer (today named IBM Rational Application Developer for WebSphere Software) which is a commercial version of Eclipse with several mainframe related plugins. So they use usual Eclipse editors with remotely located files and they can find these periods without grep - just with CTRL+F...

My experience was that while the IDE was available and picked up by newer developers, the majority of developers at the mainframe shop where I worked avoided it as much as possible for pretty much the same reasons seasoned UNIX devs prefer working via command line and text editor.

A pretty good account of a "new to mainframes" person figuring out how to make their first Cobol program on z/OS: https://medium.com/@bellmar/hello-world-on-z-os-a0ef31c1e87f

> While decyphering the remaining logic, I discovered what I think is the most evil programming construct I've so far seen;

Wait, you never heard about exceptions?