Maybe you know this now, but for those that don't:
The limitation is due to punch cards - specifically IBM-format punch cards (which was pretty much the standard by the time COBOL was developed). Those punch cards had a layout of 80 columns by 12 rows:
https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_pun...
Each column would represent (more or less) a 12-bit "word" for each character on a line of code - so one card per line of COBOL code.
Now - note that the IBM PC (well, 5100 and earlier terminals too) had a layout of 80 columns by 24 rows. Why? Because you could (in theory) see a virtual representation of two punch cards one above each other. Whether this was actually used or not, or is an apocryphal or retcon'd reasoning I'm not sure; I've been told both.
There's also parallels and such with printers - standard printer width was 80 columns (for regular 8.5 inch wide paper - sans tractor-feed edges), while greenbar was 120 characters wide (using the regular font for most printers); I'm not sure why "40 extra characters" or "half-card" extra, but I bet it's related to IBM punch cards in some manner.
It still is. Which column (not row) a statement starts in matters and it's a syntax error to start the wrong statement in the wrong column. Sorry I don't remember any specific examples because it's been a few years since I last used COBOL.
I remember hearing that this had something to do with how the early COBOL programs were encoded on punched cards. Anyway there was some practical aspect to it that is now not an issue anymore with the changes to hardware.
It is not if you use free source format, which most new cobol programming is done in. Fixed source format does require the columns specifically, free source format lets you start wherever on the line you want, and extend for however long of a line you would like, but comments start with *>
You should check out IBM RPG and its various iterations, it's a whole lot worse than that.
But yes, you are correct.
So I had to eat a little crow.
Shortly after my gig, they went full scale IBM and built an IT department, as opposed to just a system 34 in accounting.
So no support calls for me.
One of my first gigs was working for a manager who loved RPG III. To the point where I was tasked with making a data collection interpreter using the same constructs RPG III is well-known for.
To this day, whenever someone mentions "RPG III" and what that project entailed, I think of the other one[0].
Generally, extra tabs and spaces do not change semantics; nor do new lines (when inlining statements you just can't imply the semicolon).
Go files run just fine without any indentation whatsoever. People often assume enforced formatting by the `gofmt` tool is mandatory for the compiler, but most of it is addressed at human beings for readability.
Here's the 'official' blog post about gofmt: https://blog.golang.org/go-fmt-your-code
Edit: downvotes don't change reality ; )
Try it yourself: https://play.golang.org/p/_bXvXryM5Ih — how incredibly ugly, and yet it runs just fine. Please hit format to clean your eyes.
That actually is a syntax error, as go enforces (that is they are not optional) trailing commas. gofmt only formats syntactically correct code.
The above example was just to make a point, and perhaps give insights into how the compiler works.
IMHO, Go's 'enforcement' of common formatting is powerful; it has an incredible compound effect which gains momentum as you get acquainted with the language.
I do remember thinking it's odd that a line has exactly 80 characters and putting an asterisk in the 7th or 8th row means the line is a comment.
This is probably not true these days with modern COBOL. But when I saw Python the first time, and that it enforces similar restrictions with intendation and then Golang following suite, I had to smile that such old concepts of enforcing style still are seen as useful today.
Often we just have to go back and see what others have done decades ago to get new ideas!