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

141–150 of 232 posts

Re: GnuCOBOL 3.1.1

#141

Post by kjs3 »

rovr138 wrote: post #57
speeder wrote: post #37

Earlier quoted context omitted.

Because I already know: C, C++, Obj-C, C#, Php, Lua, x86 ASM, ARM ASM, Linoleum (some ASM-like esoteric languagE), BASIC (not VB), Java, Python, JS, MushCODE (it is derived from LISP), SQL and some application specific scripting languages. I started coding when I was 8, I am 32 now, and in my government-issued employer list, I had zero employers. My dad knows COBOL and MUMPS, and kept talking about how horrible they…

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.

For a while a lot of them were in Smalltalk, but Java pretty much owns it these days.

Re: GnuCOBOL 3.1.1

#143

Post by kjs3 »

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.

I remember that story. I don't think he ever got it working. There's a lot to getting a real mainframe running, starting with some onerous licensing terms for the software. And the cost to power one would be ugly.

There were some actual 'personal mainframes' made by IBM. The PC/370 was a PC or PC/AT with a set of ISA bus mainframe processor addin cards. The PC became the I/O processor. The PC/390 was a later version based on a PS/2 running OS/2. All long obsolete now.

Re: GnuCOBOL 3.1.1

#144

Post by kjs3 »

nonesuchluck wrote: post #128
the_only_law wrote: post #93

Earlier quoted context omitted.

I’m curious too, my understanding is that 90% of COBOL work is done in older mainframes (or ported from older mainframes to newer ones) and likely uses whatever IBM compilers. I don’t think I’ve ever heard of GnuCOBOL being used outside of learning.

In my (very limited) z/OS experience, COBOL by itself is necessary but not nearly sufficient. COBOL code is used inside a framework of highly proprietary software and system services: - DB2 (database is builtin to the mainframe) - GDG (Generation Data Groups, versioned file system) - ACL (IBM's original access control lists) - JCL (automation, parameters, logging) - SyncSort (data sorting, joining) - various CA Techn…

Don't forget CICS (OLTP component). But spot on...a mainframe is an ecosystem, not a language.

Re: GnuCOBOL 3.1.1

#145

Post by TheOtherHobbes »

hansor wrote: post #62

Its awful that most people here are criticizing COBOL, yet they don't even know it, but they just "heard bad things about it". In my country and in Sweden it is quite easy to get good and stable job in banking/insurance/consulting business with Cobol on Z/OS. Salary is around 10-30k PER MONTH. Around 3x more then in let's say Java.

Recently I had a look at some COBOL out of curiosity, and as someone used to modern languages it appeared very verbose and awkward - far less complex conceptually, but the syntax itself is not at all lightweight.

It seemed to be more or less as expected - fairly straightforward and apparently easy to learn, but unattractively bureaucratic.

My understanding is that you don't get paid the top money for knowing the language but for being able to understand and maintain/revise the kinds of systems it operates - which is a whole other level of skill and experience, and not something you can just pick up in a few evenings of side projects.

Re: GnuCOBOL 3.1.1

#146

Post by the_af »

hansor wrote: post #62

Its awful that most people here are criticizing COBOL, yet they don't even know it, but they just "heard bad things about it". In my country and in Sweden it is quite easy to get good and stable job in banking/insurance/consulting business with Cobol on Z/OS. Salary is around 10-30k PER MONTH. Around 3x more then in let's say Java.

At least for me, I criticize from experience: I worked with COBOL, and think it's an awful, unfun language, commonly used for unfun projects. And COBOL jobs don't pay particularly well where I live, either.

> In my country and in Sweden it is quite easy to get good and stable job in banking/insurance/consulting business

Yes, that much is true: a stable job in banking/insurance. Mostly maintaining clunky legacy systems. If that's what you aspire to, and aren't passionate about software -- which is perfectly fine! -- I guess learning some COBOL is a reasonable career choice.

Re: GnuCOBOL 3.1.1

#147

Post by kjs3 »

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.

Do you have some weird constraint where you can't use 3rd party libraries? Yeah, hash tables aren't built into the language, but libraries to provide them are all over the place. See for example http://fortranwiki.org/fortran/show/Hash+tables. Or you could a C function. Or C++ in some compilers.

Re: GnuCOBOL 3.1.1

#148

Post by dragonwriter »

galoisgirl wrote: post #97
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…

> COBOL jobs are not particularly well-paying, and there are young people learning it, and no, they don't get awesome paychecks. Yup. All the articles on the shortage of COBOL programmers is actually companies whining that they can't find cheap labor. If they paid well, they'd have their pick of young and old.

> All the articles on the shortage of COBOL programmers is actually companies whining that they can’t find cheap labor.

The word “COBOL” isn’t necessary in that sentence.

And, for that matter, “programmers” could be replaced with any skilled work field for which such complaints exist.

An actual shortage of labor (where the demand curve is above the supply curve at all price points) is theoretically possible, but in the real world nearly 100% of complaints about labor shortages are really complaints that the intersection of the supply an demand curves are at a point that results in purchasers of labor making less profit from whatever they are buying that labor for than they’d like, and laborers making more than those employers would like.

Re: GnuCOBOL 3.1.1

#149

Post by nescioquid »

cle wrote: post #124
nescioquid wrote: post #119

Earlier quoted context omitted.

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.

That kind of reductionist argument can be made for any kind of software development...we're all just plumbing bits around at the end of the day. If you're a web dev, you're plugging web tech, if you're a backend dev it's network protocols and storage tech, if you're a kernel dev it's instruction sets and memory buffers. As we build tools to make that plumbing easier for certain use cases, we might move around in the…

Of course, you're absolutely right in your reductive view, but it is not what I was trying to suggest.

I remember an explanation that Sussman gave for why MIT retired the SICP course, replacing with it a course in which students program robots with Python.

He said (and I'm badly paraphrasing) that one used to be able to scale up your reasoning about how a piece of software works in a similar way to how you do it when looking at a circuit diagram: you have these little components with discrete behaviors and you can simply combine them and be able to predict the result.

Today, however, as programmers (to a greater extent than before) we create systems by cobbling together large, opaque, libraries whose properties are poorly described and require one to essentially "do science" on those black boxes.

And the trade-off is that we're often better off plugging A into B, and hence there's a lot more of that sort of line work in industry.

edit: I should say that I don't much like that sort of work, but it was unwarranted to say it is 'alarming' that the trend has gone this way.

Re: GnuCOBOL 3.1.1

#150

Post by beezle »

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.

Surprised still using fortran 90. Thought everything now is 95 or 2003 and up.
Post reply on HN