Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

COBOL: Thinking about it wrong

gcn.com

Post reply on HN
Print view View original

111–116 of 116 posts

Re: COBOL: Thinking about it wrong

#111

Post by YeGoblynQueenne »

moomin wrote: post #107
YeGoblynQueenne wrote: post #31

Earlier quoted context omitted.

What exactly would you package manage if you had a package manager for COBOL? You will never get paid to work on any COBOL code that isn't proprietary, and sealed with the blood of innocent victims. You are not going to be installing the latest hot js framework on a mainframe .

I know you’re attacking my point but I think you’re actually agreeing here. COBOL is tied to proprietary stuff running on big iron, and its claims to modernity are window dressing.

>> I know you’re attacking my point but I think you’re actually agreeing here.

I am, but I don't think your point is a bad thing- especially if it means less javascript :)

Re: COBOL: Thinking about it wrong

#112

Post by jasomill »

skissane wrote: post #91

COBOL (or at least some of its dialects) has some really weird features I’ve never seen anywhere else. For example, only just the other day I learned that IBM mainframe COBOL has a “REVERSED” clause on its OPEN statement, which opens an input file for reading backwards . Apparently it only works for fixed length record format files, and only for files stored on tape. It relies on the fact that the (non-SCSI) IBM main…

IBM 3590 and 3592 SCSI drives support the "READ REVERSE" SCSI command[1] which (in variable-block transfer mode) is equivalent to the "READ BACKWARD" channel command.

For application details, see Knuth volume 3 [2], which even has a fold-out chart illustrating tape (and tape operator) movements involved in various sorting algorithms[3].

In brief, reading backwards allows you to use tape as a stack.

[1] https://www.ibm.com/support/pages/system/files/inline-files/...

[2] https://archive.org/details/B-001-001-250/page/299/mode/1up

[3] https://archive.org/details/B-001-001-250/page/n356/mode/1up

Re: COBOL: Thinking about it wrong

#113

Post by valenterry »

hosh wrote: post #110
dragonwriter wrote: post #74

Earlier quoted context omitted.

It was not, but for the most part languages don't default to arbitrary precision (i.e., sinple mathematical operators with decimal literals typically gets you binary floating point, not arbitrary precision decimal), even if they have arbitrary precision available at the language or standard library level.

Guess I was wrong. It’s fixed point, and also what you said — COBOL defaults to it. It still makes it easier to write software that need to do a lot of calculations like that. https://medium.com/the-technical-archaeologist/is-cobol-hold...

Yeah so that article also mentions something that I'd like to highlight:

> Overall we assume that the reason so much of civil society runs on COBOL is a combination of inertia and shortsightedness.

Well, there's more to it. Unfortunately, the better a programming language is, the easier it is to understand, change and also replace code.

And in reverse, a bad language is therefore harder to replace and more likely to stay.

Mind that I'm not saying that cobol is bad or was a bad choice. This is really a general thing, but I believe it applies to cobol at the current time.

Re: COBOL: Thinking about it wrong

#114

Post by AndrewDucker »

cratermoon wrote: post #100
AndrewDucker wrote: post #12

Earlier quoted context omitted.

C# has Decimal built in. Enough precision for any money-related calculation.

Which of the top 10 languages from the Tiobe index have a decimal type baked* into the language? * Is a type in the standard library "baked in"? I lean towards no, but I'll give the language A for effort anyway.

  1) Python - added to the standard library in 2003.
  2) C - no.
  3) Java - BigDecimal in the standard library.
  4) C++ - no.
  5) C# - built in.
  6) VB - Currency type kinda does what you'd want, but   doesn't scale down very far.
  7) Javascript - no.  (Use https://github.com/MikeMcl/bignumber.js)
  8) SQL - Yes.  But check your dialect.
  9) PHP - No.
  10) Go - No.  (Use https://pkg.go.dev/github.com/shopspring/decimal)

Re: COBOL: Thinking about it wrong

#115

Post by 3pt14159 »

kjs3 wrote: post #37
3pt14159 wrote: post #18

Earlier quoted context omitted.

I would argue that, despite the design failures, more of modern society runs on JavaScript. I know that it is hard to accept, but a crappy piece of ten year old JS with JQuery submitting a basic XHR request to a server to book a seat on an airplane or at a show matters just as much as your insurance operation that squeezes out a fraction of a point of return for an insurance package. We live in a world where many of…

book a seat on an airplane The web site might be JS, but actually booking the seat is in all likelihood going through PARS/IPARS. Which runs on an IBM mainframe.

Ultimately, maybe. But there's a whole lot a middleman hawkin' Ruby on Rails out there.

Re: COBOL: Thinking about it wrong

#116

Post by JohnFen »

SamuelAdams wrote: post #92
JohnFen wrote: post #25

Earlier quoted context omitted.

> the additional stain of 'oh, what've you been doing? Cool, popular JS frameworks? No, COBOL? Pass.' on my CV That's pretty much the last thing that I'd worry about. A company that evaluates potential hires that way is not a company that's worth working for, in my opinion. And most companies I've encountered wouldn't think that way.

You would be surprised. Don’t get me wrong I would love for companies to not show prejudice based on a candidate’s current tech stack. However once you are outside of the SV bubble you will notice a lot of companies dismiss candidates based on their tech stack. The only time I’ve ever seen an inexperienced tech stack hire is from personal referrals from someone already working at said company.

> once you are outside of the SV bubble you will notice a lot of companies dismiss candidates based on their tech stack.

My experience is entirely outside the SV crowd.

Post reply on HN