[HN Gopher] COBOL: Thinking about it wrong
___________________________________________________________________
COBOL: Thinking about it wrong
Author : rbanffy
Score : 50 points
Date : 2023-03-02 21:12 UTC (1 days ago)
(HTM) web link (gcn.com)
(TXT) w3m dump (gcn.com)
| drewcoo wrote:
| COBOL (COmmon Business-Oriented Language) was designed by Grace
| Hopper to make it easier for business folks to write code.
|
| https://www.zdnet.com/article/cobol-grace-hoppers-gift-to-th...
|
| That goal a flop, so programmers had to take over.
|
| Wasn't there a Cucumber/Gherkin story here really recently? That
| grew out of Fit/Fitnesse (from Ward Cunningham of "tech debt" and
| "the wiki" fame), which was intended to have business folks write
| test cases to define how the delivered software would work. And
| as many people in the Cuke threads pointed out, Cuke fails, too.
| (As did Fitnesse.)
|
| https://en.wikipedia.org/wiki/FitNesse
|
| Bottom line: There is a ridiculous impedance mismatch between the
| business side of the house and engineering. Engineering attempts
| to create a programming language for MBAs is not a solution, but
| an expression of that mismatch.
| kps wrote:
| > COBOL was designed by Grace Hopper to make it easier for
| business folks to write code.
|
| Not quite; it (FLOW-MATIC, rather) was designed so that senior
| management could feel that they could read their organization's
| code.
|
| > I suggest a reply to those who would like data processing
| people to use mathematical symbols that they make the first
| attempt to teach those symbols to vice-presidents or a colonel
| or admiral. I assure you that I tried it.
| hiAndrewQuinn wrote:
| How would one even go about finding opportunities to program
| COBOL professionally? I feel like I'd actually go for it if I was
| able to do it remote, but mainframes conjure up this image for me
| of sitting next to a tiny green terminal somewhere deep
| underground, leashed to The Beast or Blue Giant or some other
| whimsically-named thing.
| greenyoda wrote:
| There's lots of software for emulating IBM 3270 terminals over
| TCP/IP using the tn3270 protocol.
|
| https://en.wikipedia.org/wiki/IBM_3270#Telnet_3270
| BlandDuck wrote:
| I have seen the COBOL issue come up a number of times, and I just
| don't get it. Am I thinking about this wrong?
|
| COBOL seems to be a straightforward language by modern standards.
| Any programmer with experience with imperative languages should
| be able to pick it up. Learning the language itself cannot be a
| real barrier.
|
| The barrier seems to be the enormous amount of legacy code that
| has to be digested and understood. But wouldn't that barrier be
| pretty much the same regardless of the programming language. I
| mean, if it were 800 billion lines of Perl code, would that make
| the problem any easier?
|
| So isn't the real problem that we have 800 billion lines of
| legacy code that needs to be understood and maintained; it just
| happens to be written in COBOL?
| agumonkey wrote:
| data definition syntax is quite strange at first but
| conceptually there's nothing special
|
| and yeah legacy code of really sauron like
| altacc wrote:
| You raise a good point. I can read COBOL to get an idea of what
| it is doing and how it is structured takes a little getting
| used to, but so do most languages.
|
| However, in my company (insurance) we have 3 COBOL systems
| (thanks to mergers) and one is on a rapid track for
| decommissioning not because it is COBOL, but because it is
| COBOL written in an obscure framework that was never popular
| and also coded in a non-English language, requiring knowledge
| of that language to understand the business logic. We can
| outsource some mainframe maintenance but not that one. The
| other mainframes will be around for at least the next 10/15
| years.
| edw519 wrote:
| _So isn 't the real problem that we have 800 billion lines of
| legacy code that needs to be understood and maintained; it just
| happens to be written in COBOL?_
|
| No.
|
| 800 billion lines of COBOL = 1 million lines of BASIC
|
| A gross exaggeration, of course, but after 7 years of COBOL, I
| discovered BASIC and instantly became 10X of my former self.
|
| I would never go back. I get enough overhead from my bosses. I
| don't need it from the tech too.
| ipaddr wrote:
| Your experiences aren't as straightforward as moving from perl
| to php but sure anyone can pick it up but it is a journey. I
| remember finally getting jcl language clicking for me and
| feeling like I accomplished something.
| JohnFen wrote:
| You're not thinking wrong. COBOL is, compared to modern
| languages, very straightforward. It's also very different,
| though, and so it can feel alien to programmers who only know
| the new stuff.
| rbanffy wrote:
| No direct experience with either, but, from what I
| understand, a COBOL application written to run in CICS looks
| a lot like a serverless app, with the difference that the
| company owns the multi-million dollar server.
| JohnFen wrote:
| This is sorta true. CICS is a whole different topic all by
| itself, and is independent of COBOL. I've written CICS
| applications in COBOL, C, C++ and even Java.
| SoftTalker wrote:
| COBOL the language is pretty simple, you're right. I learned it
| in a few weeks in my first job out of college in the early
| 1990s.
|
| Even today, you can grab Gnu COBOL and learn the language.
|
| What takes longer is understanding the whole architecture of
| mainframe software. JCL, CICS, etc. It's quite foreign to
| anything you learned about programming for Unix. And there
| really aren't any free or open-source resources to learn it, as
| far as I know.
| poulsbohemian wrote:
| >What takes longer is understanding the whole architecture of
| mainframe software. JCL, CICS, etc. It's quite foreign to
| anything you learned about programming for Unix. And there
| really aren't any free or open-source resources to learn it,
| as far as I know.
|
| This could be what you mean, but isn't the problem here one
| of access? I know just enough about JCL, CICS, etc to be
| dangerous, and never found any of the mainframe systems to be
| that difficult to learn (it's all basically batching,
| queueing, scheduling...) but without _access_ to a mainframe,
| it 's kind of a non-starter to actually get hands-on with any
| of this stuff. IE: thanks to the multi-decade shift to open
| source, we've got generations that have that skill set
| because it was accessible.
| SoftTalker wrote:
| Yeah it was over 30 years ago. I'm sure with more
| experience it might have been easier conceptually. I didn't
| have any trouble with COBOL but found the whole mainframe
| environment to be rigid, crusty, and difficult to
| understand and use compared to the Unix systems I had used
| in school.
| markphip wrote:
| Some other good points have been raised about what makes it
| complex, I will add another.
|
| I never learned Cobol, but I learned programming in the 90's on
| the AS/400 where Cobol and RPG were the primary 2 languages. I
| obviously used RPG. They are both easy to learn and powerful
| for what they were meant for but they are also commonly used to
| create massively monolithic programs where massive transaction
| programs are all written in a single file or with a lot of
| "copybooks". It makes it a lot harder to reason in your head
| what is going on as well as the side effects. Things like unit
| tests are just non-existent so it is just difficult to make
| changes because of the potential consequences. Especially when
| these monoliths are handling such important data.
|
| We wrote our RPG in a very API driven fashion where we avoided
| monoliths. I think you pay a small performance penalty for this
| but it always made our code easier to maintain.
|
| Of course it also takes a very long time to compile these
| programs so the Edit/Compile/Debug cycle is not fun or
| productive.
| zerd wrote:
| I only have minor experience with COBOL, but in my mind the
| issue is that those 800 million lines of code don't have a
| single unit test, because testing COBOL is really hard. Which
| makes it dangerous to do any refactoring.
|
| Specifically the snippets I've seen do some in-line SQL to get
| its data, some business logic and then updates. The logic is
| rarely in a procedure that takes parameters, because that
| doubles the number of lines of code you need. So the only way
| to test it is to bring up a database, insert some test data,
| assert and clean up the database again. Which is a lot harder
| since "insert some test data" gets complicated because of
| different constraints and triggers etc. Then running it
| regularly is harder than it should, there's no SQLite
| equivalent database so you typically need to run it on a
| mainframe etc.
|
| I've worked on replacing a piece of functionality from COBOL to
| Java, and I was working from the business requirements that was
| basically a large spreadsheet of conditions and results. E.g.
| if age > 67 and not retired but have more than 3 kids, etc then
| this value. The code I wrote was gnarly because of all the
| combinations of different conditions, nested ifs 3-4 layers
| etc. And then there was ambiguity if multiple conditions hit,
| which one took precedence. I asked if I could look at the
| equivalent COBOL and the actual logic was about 10 lines long
| (not including headers, comments etc). Wish I had seen that
| before I started coding. It was quite readable and well
| commented too. So the actual language isn't _bad_, but the lack
| of tooling around it is severely lacking.
| nickpeterson wrote:
| I know hindsight is 20/20, but that feels like the perfect
| setup for a rules engine like Drools.
| heisenbit wrote:
| 1) popup
|
| 2) only opinion no meat
|
| 3) paper pointed to is a one pager with stats incl. numbers from
| stackoverflow
|
| Not saying that there is not an argument to be made that the
| Cobol/Mainfram approach has it advantages. It is a straight
| jacket but some applications are really efficient compared with
| what is done these days.
| benjaminpv wrote:
| COBOL was actually in the CS curriculum for my university, a fact
| that several of my friends brought up when the 'COVID is
| prompting a real need for COBOL programmers in light of the need
| to change benefits rules and unemployment!' stories were a
| regular feature on the nightly news.
|
| 'You should do it, man!' Yeah, sure. I'd already suffered through
| the liquidation of my entire department in 2018, the prospect of
| the heat around COBOL dying down and facing that once again with
| the additional stain of 'oh, what've you been doing? Cool,
| popular JS frameworks? No, COBOL? Pass.' on my CV during my next
| round of interviews didn't seem at all appealing.
|
| That mentality should set the expectation for _anyone_ looking
| into a COBOL job. It 's not just this job, it's the next one.
| sillybov3456 wrote:
| This is all based on a myth though, primarily the myth that
| "only COBOL" developers are a common thing (people believe this
| for COBOL even though it's never really been a thing for other
| languages, wasn't even ever really a thing on mainframes,
| increasingly they are majority Java).
|
| What I'm getting at is that you aren't going to find a ton of
| jobs where you are working on COBOL but somehow avoiding Java
| when the two are connected at the hip on the platforms they are
| used on.
| haskellandchill wrote:
| You don't really want to work with those people anyway. Some
| hiring managers will see it as a cool thing. As long as you do
| a project in whatever you want to target next to stay fresh you
| shouldn't have any problems except from those who hire
| superficially.
| JohnFen wrote:
| > 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.
| [deleted]
| 7thaccount wrote:
| It's the same reason why I opted to spend only minimum time
| with the dying tech in my old role and find something more
| broadly applicable. You're super important until you're not, so
| general tech that is useful in many areas is a lot safer.
|
| Cobol ain't going away anytime soon, but it certainly might
| limit what jobs you can get other places depending on the
| hiring algorithm.
| guestbest wrote:
| Even important people aren't compensated based on their
| importance but their marketability. Also, pay is usually just
| enough to prevent employees from leaving to a competing jobs.
| Too much institutional knowledge can ironically leave an
| employee uncompetitive in the market.
| avgDev wrote:
| If you know COBOL and know other languages and are fluent in
| "current" tech, then I see nothing wrong with consulting for
| $300 an hour doing some COBOL.
|
| Company I work for still uses AS400, which has been released in
| 1988 just after I was born. We have a dev who supports it. This
| isn't a small company either.
|
| COSTCO is still using and a lot of huge organizations.
|
| I'm focused on newer tech C#, .NET, Blazor but I do interact
| with DB2 database which is the backbone of that old system.
|
| At one of my interviews somewhere I mentioned that a lot of
| apps I'm writing are just extending AS400 and the dude
| interviewing me was really hyped up. He has spent a lot of time
| with the green screen in his younger years. The job had nothing
| to do with AS400, but that conversation got me an easy offer.
| [deleted]
| bluGill wrote:
| Most consultants cannot get $300/hour for COBOL though. It is
| those who have specific other knowledge - like experience in
| the system before they retired who can get that much.
| [deleted]
| LangIsAllWeNeed wrote:
| Ya Cobol is the future!
| aeschinder wrote:
| In the 1980s, COBOL was taught in my computer database class. I
| actually used my COBOL skills at the federal government Veteran's
| Affairs job I had for several years after college.
|
| If you are always chasing the latest language and get high on
| syntactic sugar, you are likely going to be a problem for
| management if you work at an IT shop because you'll be writing
| important one-off programs in various languages that people after
| you will be required to support or rewrite.
|
| John Carmack wanted to hire only C++ devs when he was at Oculus
| but had to relent and hire JavaScipt bros because of Meta.
|
| TCO isn't just a question on your business class exam.
| xiaodai wrote:
| I would do cobol if it's 2000 a day
| jmclnx wrote:
| > That last application garnered plenty of attention during the
| pandemic when state UI systems running COBOL were unable to
| handle the unprecedented flood of new applicants
|
| COBOL was _not_ the issue, it was all the "webizied" front end
| developed for people to use via a browser that had the issues. A
| couple of articles came out with details that, as usual, the
| mainstream press ignored.
| W-Stool wrote:
| People that have not been exposed to legacy industries (banking,
| insurance, etc) would simply not believe how many of these
| large/huge companies run the majority of their business on an IBM
| mainframe running COBOL code. I've seen it firsthand and I didn't
| believe it. For them, it just works.
| sillybov3456 wrote:
| Its peak hacker news to come up with a term like "legacy
| industry".
| santoshalper wrote:
| I suspect they mean "systems that use a lot of legacy
| technology" rather than "banking and insurance are legacy
| business models", but it is HN, so who knows. Either way,
| pretty amusing.
| chocolatelab82 wrote:
| One of the slides by some IBM consultants presenting at the
| financial firm I used to work stated "Western Civilization runs
| on the mainframe." Considering how much banks still use
| mainframes, this is probably true.
| LeonenTheDK wrote:
| I recently listened to a podcast episode which featured a
| gentleman who teaches mainframe related things at a
| university in the US and is deeply involved with the Open
| Mainframe Project. His statistic was 95% of financial
| transactions touch a mainframe somewhere along the way.
|
| From what I know, considering it's not "just" banks but
| pretty much any long running financial business (IE insurance
| companies), I believe it's one of the most used but least
| talked about technologies out there.
| rbanffy wrote:
| If you like to listen to podcasts and are curious about
| mainframes, get Terminal Talk. It's a lot of fun and the
| mainframe ecosystem is a completely alien biosphere totally
| different from the Unix space we are more used to see.
| JohnFen wrote:
| Not just financial businesses. For instance, I worked on a
| product also used by one of the largest package shipping
| companies. A couple of their key systems consisted of
| mainframes running COBOL code.
| mrobins wrote:
| Can confirm. In a past life I had the pleasure of auditing
| the COBOL code of a major US insurer. They had a separate
| program for every line of service (Auto/GL/etc.) that would
| read every claim record and produce their actuarial tables.
|
| It was pretty fascinating to see how it all came together.
| Also despite the languages age after analyzing it for a
| length of time it was clearly elegant for that type of
| financial processing.
| 3pt14159 wrote:
| 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 the software languages we use
| really do matter. If all Ruby interpreters disappeared
| overnight it would cause global havoc. Real panic. Trillions of
| dollars of damage.
|
| But because we've learned to rely on these languages continued
| existence we can undervalue any one of them, including COBOL. I
| don't because I've thought about it and concluded that we're
| essentially building on things akin to writing or mathematics.
| Our building blocks are vital, even if they're easy to take for
| granted.
| kjs3 wrote:
| _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.
| moomin wrote:
| I'm pretty sure I'm thinking about it right. How much COBOL code
| can run on a regular Ubuntu machine? What's the package manager
| for OSS packages? What test frameworks are in common use?
|
| You know you're in trouble when "There's a syntax file for
| VSCode." is the height of your modernity.
| II2II wrote:
| That would be like claiming PowerShell is irrelevant because it
| is not on the typical Ubuntu machine. While it is irrelevant to
| the typical Ubuntu user, the world is a diverse place and
| computing is no exception.
|
| That being said, I feel that the article made very weak
| arguments so I don't blame anyone for perpetuating the
| stereotypes. These are things such as mentioning which
| industries it is used in, but not being specific as to how it
| is used (which is important since COBOL seems to be a domain
| specific language) and relying upon authority when claiming it
| is modern.
| bitwize wrote:
| > How much COBOL code can run on a regular Ubuntu machine?
|
| All of it. GNU Cobol exists, as do proprietary solutions from
| companies like Micro Focus that target the JVM and .NET (which
| is what you're looking for for a real COBOL solution).
|
| But why is it so important to run COBOL on Ubuntu? If you need
| Linux, create a Linux LPAR on your mainframe.
|
| > What's the package manager for OSS packages?
|
| COBOL code runs Western civilization. Not having muh NPM is a
| feature, not a bug.
|
| > You know you're in trouble when "There's a syntax file for
| VSCode." is the height of your modernity.
|
| Dude. COBOL has entire modern IDEs written for it.
| VulgarExigency wrote:
| There are several programming languages with package managers
| that work better than NPM. Not having one is not a positive
| no matter how you try to spin it.
| JohnFen wrote:
| I think this is a point that reasonable people can disagree
| about.
| YeGoblynQueenne wrote:
| 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_.
| msla wrote:
| > You are not going to be installing the latest hot js
| framework on a mainframe.
|
| I think IBM would disagree with you, given how much
| they've pushed Linux (and, therefore, Linux web servers
| running Node and kin) on their mainframes. You won't be
| installing much of anything like that on a midrange
| system, but Linux on Z is pretty well established.
| YeGoblynQueenne wrote:
| Doesn't that depend on the client company, rather than
| IBM? I'm going with what I know from the one
| (big,financial) corp that I worked in with COBOL on
| mainframes; there, we didn't use linux at all.
|
| Anyway those environments are downright sclerotic (the
| worst thing about working with COBOL that nobody
| mentions). They didn't even let me install Firefox on my
| work laptop. They had people doing web dev, obviously,
| but the mainframe teams were more, let's say,
| conservative.
| anadem wrote:
| > COBOL has entire modern IDEs written for it.
|
| In fact the very first visual compile/debug environment was
| written in COBOL over 40 years ago: Micro Focus's Animator
| (from which Microsoft paid to use the patents in their Visual
| products iirc).
| msla wrote:
| It's the same problem z/OS has: There's no hobbyist community
| so it remains obscure. Yes, you can run 1980s-era System/370
| software under Hercules, but IBM keeps anything remotely
| modern under lock and key even though you'd think it would
| benefit IBM to have people indoctrinate themselves into the
| Blue Worldview.
| YeGoblynQueenne wrote:
| >> If you need Linux, create a Linux LPAR on your mainframe.
|
| Or use the super secret hidden unix mode.
|
| (and get stuck in an ed prompt. Fun times ?).
| RobotToaster wrote:
| I assume GnuCOBOL can run on GNU/Linux.
|
| https://gnucobol.sourceforge.io/
| msla wrote:
| GnuCOBOL not only runs on Linux, it's pretty far along
|
| https://gnucobol.sourceforge.io/faq/index.html
|
| > GnuCOBOL implements a substantial part of the COBOL 85,
| COBOL 2002, COBOL 2014 and upcoming COBOL 202x standards, as
| well as many extensions from existing COBOL compilers.
|
| It's also in the Ubuntu package repos, from a quick check.
|
| The GCC Cobol aspirant recently gained compliance with
| Cobol-85
|
| https://lwn.net/Articles/922951/
|
| There is active Free Software development on Cobol tools.
| 1bent wrote:
| My mom learned COBOL while she was getting a degree in
| accounting; according to her, the language is such a clear
| mapping from narrative jargon usage in accounting and bookkeeping
| that she was using features her class hadn't covered, in test
| solutions, without realizing it, until her teacher asked if she
| was studying outside materials.
|
| My conclusion was, if ever I want to do business data
| (transaction) processing, I'll learn it.
|
| I also programmed a mainframe, with JCL on punch cards, in
| assembler and PL/1, in college; I'm glad I did; without that
| experience it might be hard to appreciate how radical and
| revolutionary unix was.
| jimt1234 wrote:
| My mother built her career on COBOL from the mid-70s to the
| late-90s. She's retired now, but still talks about what a great
| language it is. She tried learning Java in the late-90s, toward
| the end of her career, but hated it. _" What's an object?
| Everything? Everything is an object? That's just dumb."_ LOL
|
| And yeah, she still gets offers for consulting work, but she
| wants no part of it. She's done working.
| mattnewton wrote:
| I have never written cobol, but I wonder if there is a market for
| a COBOL transpiler to something like C#/Java/typescript, or even
| python would be a viable business?
| sidpatil wrote:
| The US DoD recently migrated some of their COBOL systems to AWS
| GovCloud. One of the steps was automated translation of COBOL
| to Java.
|
| https://tsri.com/news-blog/u-s-department-of-defense-mainfra...
| cutler wrote:
| So it's true - Java is the new COBOL.
| yobbo wrote:
| I suspect it's not the language itself but the systems already
| in place. Transpiling to something else wouldn't help.
| JohnFen wrote:
| Yes. I know of companies that run mainframe emulators purely
| to keep using the existing COBOL codebase that was written
| for them.
|
| They go to that level of weirdness because replacing the
| existing codebase would not only be much more expensive, but
| would introduce a great deal of risk that they aren't willing
| to take on.
|
| A transpiler would not really address the needs of that sort
| of company.
| NeutralForest wrote:
| It's a mix of both, I know that some companies do make a good
| living writing transpilers to languages like Java or C#. But
| it also require lots of business knowledge to keep track of
| the changes so you're definitely right in that aspect.
| GartzenDeHaes wrote:
| There are companies that specialize in this area such as
| Microfocus and Fujitsu.
|
| A long time ago, I wrote a Tandem COBOL to C# and WPF
| translator (https://github.com/GartzenDeHaes/cobol2cs). The key
| bits are:
|
| - COBOL UI's run in a customer written environment that
| provides security, navigation, and session data. In the system
| that I wrote, there's a WPF application that provides these
| services.
|
| - Convert SCREEN COBOL to C#. The Tandem uses a VT6530 that is
| similar to an extended IBM 3270. There are client-side
| protected fields and scrollable areas that need to be emulated
| in WPF.
|
| - Convert COBOL servers to C#. The Tandem has a 3-tier
| architecture where the screen programs talk to services running
| in a middle tier through an network layer called PATHWAY. These
| can be converted to classes and be created on demand in C#.
|
| - Remote access to SQL/MP databases. Tandem has a Java Servlet
| environment that can be used as a data access layer. The
| transpiler generates these Servlets and the C# data access
| layer.
| santoshalper wrote:
| This article is extremely disingenous.
|
| * Can you build "modern" style software in COBOL? - Sort of yes.
|
| * Should you build a new system today using COBOL? - Absolutely
| not.
|
| * Is ANY of the COBOL code you run into in the wild going to be
| architected in a recognizable way to modern sofware engineers? -
| lol no.
| hosh wrote:
| I grew up hearing COBOL as a joke language, until one day, I
| learned that COBOL has the most accurate arbitrary precision
| math, surpassing modern languages. This is crucial for financial
| applications. When I then think about how it doesn't seem any
| more verbose than SQL, COBOL seems to me like a very respectable
| language.
|
| Somewhere early in my career, I worked with an accounting app
| that thought a double float is good enough for a ledger. It was
| not. We spent too much time trying to track down discrepancies
| when closing the book for the year, only to find out that a
| double float is not precise enough for bookkeeping. Lesson
| learned.
| valenterry wrote:
| > I learned that COBOL has the most accurate arbitrary
| precision math, surpassing modern languages.
|
| Maybe that was true 20 years ago.
| dragonwriter wrote:
| 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.
| docandrew wrote:
| Ada's support for fixed-point arithmetic is worth looking at
| too for financial apps.
| scarygliders wrote:
| As someone who learned COBOL in British college in the late
| 1980's, I can confirm that the language was/is quite readable and
| accessible. I still have the COBOL textbook from back then;
| Andrew Parkin, COBOL For Students, second edition, ISBN
| 0-7131-3477-1
|
| I distinctly remember at the time really enjoying learning to
| code in it - it spoke to my logical-thinking (but quite young)
| brain a lot.
|
| However, after college, for whatever reason I didn't use that
| COBOL knowledge at all. If only I knew then what I know today -
| that COBOL is still somewhat in demand and that if only I kept in
| with it over the years, I could quite probably have made quite a
| good living from it.
|
| Young me was quite naive and silly ;)
| nyerp wrote:
| Popup ad with 15 second delay was too annoying. Didn't read the
| article.
| smarks wrote:
| Click on the link to skip the delay.
| yobbo wrote:
| > with 800 billion lines running in production systems daily
|
| Unrealistic. This would be equivalent to 100.000 linux kernels.
| Hardwired8976 wrote:
| not really, cobol is really verbose and there is heavy use of
| macros
| ElfinTrousers wrote:
| Even after a 44% bump, the salaries for COBOL positions aren't
| impressive compared to other specialties. And that's before the
| quality-of-life question.
| ptero wrote:
| The quality of life may not be bad at all. I have a relative
| who maintains old code for a public utility (I think most of it
| is PL/1). While the salary is not FAANG-like it is OK and the
| job security and the sane 9-5 schedule with the opportunity to
| work remotely are pretty big benefits for someone on the wrong
| side of 60. My 2c.
| kjs3 wrote:
| Yeah...I know quite a few Cobol programmers. They make good,
| not extravagant, money. But they also have low job stress, no
| 'crunch mode'. Production changes are very carefully
| considered and controlled because of the consequences of
| botching one. No 'move fast and break things'. They're home
| with the family at a reasonable time every day. So it's a
| tradeoff, and a good one for many people.
| MelvinButtsESQ wrote:
| COBOL is easy. JCL is the hard part.
| JohnFen wrote:
| _shiver_
|
| That's a fact. A couple of years ago, I had to brush off my JCL
| skills for a job. It reminded me of why I was so happy when I
| didn't have to use JCL anymore.
| cratermoon wrote:
| COBOL is good for dealing with money because it was built with
| the sort of numeric types required as a natural part of the
| language. Popular programming languages treat them as an
| afterthought and provide awkward library functions, if they
| have anything at all.
| AndrewDucker wrote:
| C# has Decimal built in. Enough precision for any money-
| related calculation.
| ElectricalUnion wrote:
| Lots of languages have Decimals (and arbitrary precision
| integers for another example) builtin, but they're usually
| never the default.
| YeGoblynQueenne wrote:
| On the bright side, you can generate all your JCL with Rexx.
| bitfhacker wrote:
| Or with chatGPT!!
| SoftAnnaLee wrote:
| I keep hearing about COBOL and how there is demand for it. But
| I'm wondering if there are any avenues to learning how to write
| COBOL and get experience writing the kind of code that these
| industries require?
___________________________________________________________________
(page generated 2023-03-03 23:01 UTC)