Hacker News Reader

Comment by kerng | Hacker News Reader

Have not dealt too much with COBOL but learnt it a while ago. It was one of the easier languages to comprehend quickly. I thought it was well suited for input and data processing focused applications.

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!

View on HN

> I do remember thinking it's odd that a line has exactly 80 characters

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.

>> This is probably not true these days with modern COBOL

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.

This was the case with Fortran 77 too, and for the same reason (punch cards). But modern Fortran (F90 through F2018) no longer requires formatting by column.

Good point. I think maybe one reason is that COBOL is valued for its consistency, with the same code often running on modern machines that was written 50 years ago or so (at least that was the received wisdom when I was working at a COBOL shop). Perhaps the same is not the case with FORTRAN?

>>It still is

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 *>

So offsides syntax errors like Python. But immutable instead of arbitrarily dependent on context. Seems simpler and more modular to be able to look at a line of code and determine if the whitespace is correct.

> 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.

You should check out IBM RPG and its various iterations, it's a whole lot worse than that.

As someone who spent serious time in RPG III in a previous lifetime, I would not advise anyone whose welfare I cared about or was responsible for to go look at RPG.

But yes, you are correct.

There is RPGII code I wrote back in the 80's that is still in daily use today. Most of the people who know I wrote the code have passed on, so the support calls have stopped.

Partway through that particular gig, the IBM CE came by and installed COBOL. (For many years, I had ranted about how much I hated COBOL.) So I transitioned all the RPG code to COBOL and what a relief.

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.

> As someone who spent serious time in RPG III in a previous lifetime, I would not advise anyone whose welfare I cared about or was responsible for to go look at RPG.

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].

0 - https://en.wikipedia.org/wiki/Rocket-propelled_grenade

Golang doesn’t have semantic indentation.

I don't know why you're being downvoted, this is true.

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.

I've seen go code fail to compile because a closing } was on the next line and there wasn't a trailing comma. I'd fully expect a formatter to handle that kind of minutiae for me.

Oh absolutely, do use gofmt, always.

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've seen go code fail to compile because a closing } was on the next line and there wasn't a trailing comma.

That actually is a syntax error, as go enforces (that is they are not optional) trailing commas. gofmt only formats syntactically correct code.

I get that a formatter should reject syntactically incorrect code, but I question why it's syntax error in the first place. Coming from using black with python, I generally leave the trailing comma there but for the compiler to care seems weird when there's a standard formatter available.

The compiler cares because they want to enforce this standard (and it may make the parser slightly simpler). That there is a mix, or at least a non-obvious break between what the compiler enforces and what the formatter will accept and produce is an inconsistency in go, I suppose, but not necessarily worse than arbitrary decisions made in other languages.

Reply on news.ycombinator.com