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

GnuCOBOL 3.1.1

sourceforge.net

Post reply on HN
Print view View original

111–120 of 232 posts

Re: GnuCOBOL 3.1.1

#111

Post by retrac »

rhabarba wrote: post #65
rovr138 wrote: post #57

Earlier quoted context omitted.

Most of the interfaces I've seen that interact with COBOL running on mainframes are built with Java. Not sure if this helps, but could also lead into working close/near with mainframes and COBOL.

Quite a few companies have specialized in migrating COBOL to C# or Java code, so I’m not surprised. I wonder why they choose those languages as one-trick ponies though. Seems like the “we only have a hammer” problem.

Java would be the safest bet for the "other" language known by a COBOL programmer.

Re: GnuCOBOL 3.1.1

#112

Post by goatinaboat »

the_af wrote: post #44
Koshkin wrote: post #17

I do not get all the hatred. The idea behind COBOL’s syntax is the same as SQL’s: it is merely yet another “Structured English Query/Programming Language” designed, initially, for non-programmers to be able to describe in words what it is they would like to accomplish in a way they could be understood by the computer.

The hatred comes from people like me, who have worked with COBOL and will tell you it's terribly frustrating to work with, needlessly verbose in multiple places where it doesn't need to be, and often used in banks for purposes which are the death of all you hold dear or interesting to work with. COBOL is not an interesting programming language these days, and you should not learn it unless you need it for your curren…

The reality: I've never met a really wealthy COBOL programmer -- or rather, one who was wealthy because he/she knew COBOL.

The pay is at the intersection of "knows COBOL" and "knows the problem domain inside out". The problem domains are not something most people would ever have been exposed to without getting in in the first place as COBOL programmers.

Re: GnuCOBOL 3.1.1

#113

Post by galoisgirl »

the_only_law wrote: post #72
enthd wrote: post #67

Ah COBOL, oddly enough I started my first dev job in COBOL in the banking industry(I'm in my 30s and started my professional coding career in my 20s), I have mixed feelings about it...it's a weird language but it has it's place, I wouldn't advise anyone to jump into a COBOL career path unless you are doing it for a job and a job alone.

I would kill to get a personal mainframe though. Read a story some time ago about some guy who snagged one from a government auction. Sadly they never have anything cool when I look.

You can get a free account on one, for example in Master the Mainframe.

Sure, it's not half as cool as having the machine like that guy, but you don't need to reinforce the floor in your house, so there's that.

Re: GnuCOBOL 3.1.1

#114

Post by Jtsummers »

galoisgirl wrote: post #100
Mister_Snuggles wrote: post #52

This seems like a great candidate for a future Advent of Code! Old languages have a special place in my heart, so doing Advent of Code with them is kind of fun. I'm doing this year's in UniVerse BASIC[0] which traces its roots back to Pick[1] which is only six years newer than COBOL, but manages to be less well-known. [0] https://news.ycombinator.com/item?id=25250582 [1] https://en.wikipedia.org/wiki/Pick_operating_s…

I'm doing in COBOL: https://github.com/GaloisGirl/Coding/tree/master/AdventOfCod... I'm having a problem with day 7 with the lack of hash tables. Care to share your BASIC solutions?

You can do it without hash tables.

If you're able to create a graph structure with references/access/pointer types or whatever COBOL uses you can have records with contents similar to:

  record Bag:
    string : Description
    array of Bag Pointer : Children
    array of Integer : Count
Where the indexes into the two arrays correlate. Since, as you parse, you don't know where the children may be, you can use an array to store the bags as you read them in. And in a second pass construct the graph proper. You may also want a set of pointers up to the bags containing a bag, but it's not, strictly, needed.

If I were doing this year's in C, I'd have done something like that since it, also, doesn't have a built-in hash table/dictionary.

Re: GnuCOBOL 3.1.1

#115

Post by simias »

the_only_law wrote: post #88
simias wrote: post #81

Earlier quoted context omitted.

To be clear I wasn't making a judgement of value, I was just stating matter-of-factly that I've been a professional dev for over 15 years and while I did occasionally encounter some more niche languages I haven't actually bumped into a COBOL listing if I wasn't specifically looking for it. Fortran, Scheme, Haskell, Erlang, Modula? Occasionally. COBOL, never.

> Modula Ok now I’m curious...

FreeBSD's old CVSup was written in Modula-3: https://docs.freebsd.org/doc/3.0-RELEASE/usr/share/doc/handb...

Re: GnuCOBOL 3.1.1

#116

Post by xioxox »

roel_v wrote: post #34
hackbinary wrote: post #9

COBOL, Assembler, and FORTRAN are actually kind of cool.

Having spent much of my time in Fortan 90 the last couple of months - I'm going to have to go ahead and disagree with you on this one. You know all these people saying "when will I ever have to write mu own hash table?" Well, when you start working in Fortran.

Me too... the lack of decent non-array containers is frustrating. The string handling is also painful (seemingly TRIM everywhere). I've also hit several compiler bugs trying to use fairly new features.

Re: GnuCOBOL 3.1.1

#117

Post by the_only_law »

simias wrote: post #115
the_only_law wrote: post #88

Earlier quoted context omitted.

> Modula Ok now I’m curious...

FreeBSD's old CVSup was written in Modula-3: https://docs.freebsd.org/doc/3.0-RELEASE/usr/share/doc/handb...

Neat, I’ve been down a rabbit hole with many of Wirth’s languages a few times, but never properly learned them. I think I tried to get some Modula 2 or Modula 3 gcc frontend to work a while back with little luck.

Re: GnuCOBOL 3.1.1

#118

Post by the_af »

goatinaboat wrote: post #112
the_af wrote: post #44

Earlier quoted context omitted.

The hatred comes from people like me, who have worked with COBOL and will tell you it's terribly frustrating to work with, needlessly verbose in multiple places where it doesn't need to be, and often used in banks for purposes which are the death of all you hold dear or interesting to work with. COBOL is not an interesting programming language these days, and you should not learn it unless you need it for your curren…

The reality: I've never met a really wealthy COBOL programmer -- or rather, one who was wealthy because he/she knew COBOL. The pay is at the intersection of "knows COBOL" and "knows the problem domain inside out". The problem domains are not something most people would ever have been exposed to without getting in in the first place as COBOL programmers.

I don't disagree with you. But note most people learning COBOL won't get those high-paying jobs; they'll instead end up maintaining legacy and boring corporate systems. And COBOL isn't a particularly interesting language to learn: in the spectrum between boring cutting edge, COBOL lands on the far side of "very boring"!

Re: GnuCOBOL 3.1.1

#119

Post by nescioquid »

Jakobeha wrote: post #109
the_only_law wrote: post #71

Earlier quoted context omitted.

I’ve always heard COBOL devs referred to as either highly paid consultants keeping critical applications alive for corporations or wage slaves maintaining a painful app for below average pay.

I've heard it's the computer science equivalent of a plumber or janitor. The job doesn't sound particularly fun, but because of this it's high demand and great pay. It's a good job if you accept that work isn't fun, and you don't care about climbing the ladder, you're just looking for a decent, reliable income.

An alarming amount of software development, especially now, is little more than plugging part A into part B. The major trend of software development has been to increase the degree of similarity between software developers and plumbers.

Re: GnuCOBOL 3.1.1

#120

Post by galoisgirl »

Jtsummers wrote: post #114
galoisgirl wrote: post #100

Earlier quoted context omitted.

I'm doing in COBOL: https://github.com/GaloisGirl/Coding/tree/master/AdventOfCod... I'm having a problem with day 7 with the lack of hash tables. Care to share your BASIC solutions?

You can do it without hash tables. If you're able to create a graph structure with references/access/pointer types or whatever COBOL uses you can have records with contents similar to: record Bag: string : Description array of Bag Pointer : Children array of Integer : Count Where the indexes into the two arrays correlate. Since, as you parse, you don't know where the children may be, you can use an array to store the…

Thanks! I'll give that a try over the week-end.
Post reply on HN