GnuCOBOL 3.1.1
sourceforge.net
sourceforge.net
The other developers then spent time readding the comments
"good stable and low-stress jobs in the middle-range of local income"
You're essentially invalidating the opinion of whoever thought it was important to put a comment there in the first place and, unless it's done after a team discussion on the types of comments to include in code, it's being done unilaterally.
Bad comments are detrimental: some are outdated comments that were forgotten to remove or to update, and others were wrong or misleading to begin with. Some are just redundant (they might state the obvious) and might become misleading later on. Their existence is of historical interest in the best case.
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.
Technically most of Europe don't need convert to EUR, they already use Euros so they're also more likely to need to convert to USD.
As we build tools to make that plumbing easier for certain use cases, we might move around in the hierarchy to plug different things together, but I don't think anything has fundamentally changed in an alarming way. We're still just moving bits around!
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.
then you force it together with whatever you have at hand, and wrap it all in a thick layer of duct tape. That's exactly like software engineering.
That's an okay salary in absolute terms, but it's not a great one for a software engineering position. Even in a fly-over state.
But taking that job is basically career suicide. After 3-5 years of doing that, you'll be completely unemployable outside of insurance unless you spend time on your own learning useful skills. And if you do that, you're probably starting back down in a junior or mid-level role.
Anyone would be much better off getting an AWS cert and learning to write SQL.
I hate COBAL a lot, and incidentally for many of the same reasons I hate Java.
From personal experience: BNP Paribas is one of the biggest bank in the world, top 5 if you exclude Chinese state owned ones, and they pay mainframe related jobs like shit.
Being young, smart and with a whole career ahead, you have no future working has a COBOL developer, no one should spend his life picking up shitty code left by his elders decades ago.
Even in newer languages like Java, there is lot of work that is mostly application maintenance and adding new features to existing decade old applications. It is not bad work.
Would you say that to a civil engineer who works on infrastructure maintenance?
Computing is critical infrastructure in many areas of government and business. The solution to all problems cannot be “screw it, we’ll just rewrite in Go with a React frontend.” Some things should be rewritten and some should be maintained.
Funny to me how so many in this thread rag on COBOL, yet when other languages come up it is always 'well this language is good for abc but I wouldn't really do xyz in that one'. COBOL is extremely good at what it was designed for - data processing, and lots of it.
Well, the hardware that COBOL usually runs on is good for that, sure. And its usually (now) running legacy systems that no one wants the risk of reimplementing from the ground up. But is the language itself particularly well-suited to the task? I think that’s less clear. Certainly, I’ve never seen a coherent argument about how the language itself is superior to modern alternatives even for large scale data processing; if it was, it would be popular for greenfield projects in that domain, you’d think.
What modern language doesn’t have either fixed-point or arbitrary-precision decimals (or both) in either the core language or standard library?
I mean, sure, C doesn’t (and I don’t think C++ does), but those aren’t particularly modern languages.
The language combines presentation and storage in a way I've never seen in any other language. Let's say you have an 8 digit variable. You can then specify that the last two digits is represented by a different variable, and thus the second variable will only work on those last two digits.
This is useful when you have formatted fields, where you have a variable that holds an ISO 8601 date, with other variables representing the year, month and day parts.
In a language like Java, you need to create a class that holds this information, with separate methods to manipulate the individual components and formatting the output.
In COBOL you only need a few lines of declarations to do this.
The drawback is that now presentation is tightly associated with the data storage, meaning that changing presentation format can be a lot of work. This is why COBOL programs were so problematic during Y2K.
Despite producing some of the best engineering talent in the world it seems that French engineer are systematically underpaid.
And the visa issue is way overblown. It's easier than you think for a real engineer with experience.
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.
> 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.
This is a completely unfair assessment. Even if you're passionate about something, job stability and good pay are going to be the primary drivers in decisions about jobs. I doubt that most people choose, say, Java jobs because they're passionate about Java, or even software in general, for example.
From what I gather, most people leave the "passion" part of their work to part-time hobby work, allowing them to do both. If it then translates into money, good, but the few successes that have been put on blast have blinded people to the reality that passion != money.
> Even if you're passionate about something, job stability and good pay are going to be the primary drivers in decisions about jobs.
For a lot of people, yes. Not for all. And even then, it's hard to argue that COBOL is cool or interesting. It's just paying the bills, but nothing to get hyped or write gushing articles about. And there are more interesting programming jobs that will also pay the bills, anyway.
Unless there aren't.
Either way, you're judging people simply for taking a different path than you, which is completely unfair.
I didn't mean to judge people and in fact tried not to, though perhaps clumsily. I said it's fair to not be passionate about the job. Often I haven't felt passionate about it either, or even particularly motivated. And do note I have worked in COBOL, so I understand the need. I just don't like the language and I don't want to see people selling the idea that it's "interesting" or a particularly sound business decision to learn it -- like those articles that occasionally get posted to HN.
That's not what you said, though. This is what you said:
> If that's what you aspire to, and aren't passionate about software
Those are completely different sentiments and your original "aren't passionate about software" statement is the statement I took issue with.
This is one of those things that is easy to discuss in theory, but in practice it doesn't work that way, at least not in most cases. And in my experience working with COBOL at a bank: no, the employees weren't passionate about it. In fact, the only passionate employee was an old guru who wrote assembly code for the bank's mainframe.
You could take it to an extreme, and argue that working with malfunctioning computers, using only BASICA.COM for DOS, writing accounting software and getting paid mere cents for it, requires more passion -- after all, who would want to work like this if they didn't feel passionate about it -- but of course it isn't.
It's great to work in challenging or atypical projects, maybe with tools that are not the easiest or more ergonomical, but there's a baseline of comfort below which you're probably not passionate, just masochistic.
I leave my passion for when I log off the VPN.
I love my job, and I leave work at work so it stays that way.
[1]: https://grammarware.net/text/2020/babycobol.pdf [2]: https://slebok.github.io/baby/
What currency? The kroner is with about $.12 so that’s not particularly enticing.
Modern COBOL does not enforce CAPS LOCK anymore though - and you can even skip the 7-columns indentation if you wish!
Ok now I’m curious...
And, it was developed long before a lot of modern compiler theory was even thought of, so it's going to be a little unfamiliar to those used to "modern" languages.
COBOL is not an interesting programming language these days, and you should not learn it unless you need it for your current job.
> [COBOL was] 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.
Let me tell you a secret. It doesn't work for non-programmers. The complexity of "Z = X + Y" is no more or less than "ADD X TO Y GIVING Z", and bugs will happen at the same rate with either syntax. The added verbosity will only annoy you.
Another myth surrounding COBOL is that as its programmers age, there is a lack of them and therefore COBOL jobs are high-paying and you should learn it to make good money. The reality: I've never met a really wealthy COBOL programmer -- or rather, one who was wealthy because he/she knew COBOL. That's not where the money is. COBOL jobs are not particularly well-paying, and there are young people learning it, and no, they don't get awesome paychecks.
Not to mention that verbosity often distracts from meaning, leading to more place for bugs to hide.
But say this to non-programmers, and they vehemently deny it's true. And always cite a friend of their neighbor who made it good from COBOL. It's like they need to believe there's a shortcut out there to sure wealth as long as you're smart and work hard.
It wasn't designed to work, it was designed to please senior management.
Grace Hopper: “I used to be a mathematics professor. At that time I found there were a certain number of students who could not learn mathematics. I then was charged with the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would. […] They said, ‘Throw those symbols out — I do not know what they mean, I have not time to learn symbols.’ 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.”
Wouldn't it be easier to just use C/C++, and define macros like "PLUS" that explands to "+", "MINUS" that expands to "-", "BECOMES" that expands to "=", etc.?
Oops, COBOL predates C. :(
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.
I looked at jobs in my area and some don't require any experience, they train you.
There's also the kid who just bought a Mainframe: https://www.fastcompany.com/3063265/this-teenage-ibm-employe...
You just need a Linux PC with the IBM Z Development & Test Environment.
(Of course, ZD&T, even the “Personal Edition”, doesn’t exactly have hobbyist-friendly pricing.[0])
You can do cheaper (i.e., free) with Hercules, but only with older OS’s.
[0] https://www.ibm.com/products/z-development-test-environment/...
"these days"?? COBOL has been available on Windows since Windows 3.1, and was even a commercial success on DOS in pre-Windows days. Yes, it was principally used in finance on mainframes, but the mini- and micro-computer implementations were fully ANSI standard, and included extensions for CICS and other mainframe stuff.
(I worked on DOS COBOL runtime support, then OS/2, then Windows ...)
But COBOL jobs don't pay anywhere near that kind of coin, and they likely never will in my lifetime. The systems in place are solid enough that they can survive the resolving door of shitty, underpaid contractors who are hired to work on them. Nothing every improves, but it also never gets worse.
Out of curiosity I just made a short search for COBOL jobs in my area. The few I found actually pay less than my current Java job.
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.
The case of COBOL is of interest as there was a wave of articles this year suggesting there was some sort of anomaly on the market: tons of COBOL programs and not a soul alive to maintain them.
There’s probably something more like a legitimate short-term shortage in that case, because you have lots of immediate demand for changes (because of urgent business process changes) to stale legacy systems, so you really don’t have the luxury of waiting on long-term corrective mechanisms like retraining, price signalling through the pipeline for workforce entrants, etc., before the value opportunity is missed. COVID-19 and the resulting (many probably short-term) legal and business changes created a number of market anomalies of that kind.
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'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.
I'm having a problem with day 7 with the lack of hash tables.
Care to share your BASIC solutions?
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
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.
Sadly, I got jammed up with dealing with stream files on day 4, and then a C3 talk got accepted, so I haven't gotten much time to work on it since
My AOC code is also on GitHub: https://github.com/kimmeld/AOC2020
There are two things to keep in mind here:
First, UniVerse BASIC isn't the old BASIC like you'd find on an Apple ][ or C-64, nor is it the QBasic you'd find in MS-DOS. It has its own unique features, such as dynamic arrays.
Second, I'm taking advantage of UniVerse features where they make sense. When I do this I document it since the code only has a portion of the solution. So far, I've done these for an alternate version of day 4 and for day 7. In particular, I used a UniVerse file in place of a hash table for day 7.
More seriously is this release particularly notable in the COBOL world? I know very little about the language and I find it odd to find the Changelog of a minor release at the top of the frontpage.
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 are... but maybe I can get a job if I try these.
With a portfolio like that, you might want to look at why you can't get a job. You sound capable enough on the technical front, so there must be something else that's preventing you from advancing your career.
Not sure if this helps, but could also lead into working close/near with mainframes and COBOL.
It's what value you can provide with those that counts.
One of my earlier companies started with a policy against hiring folks who just knew PHP, even though that was our main language. We wanted folks who knew SQL, some JS, maybe some C or something to prove they were well-rounded and could think about tech as a whole.
We dropped that policy when folks started coming in with _just_ Ruby on Rails under their belt. They were destroying our project-based interview and blasting out projects in weeks that typically took us months. And we found that we could easily teach them the SQL they needed when they needed it.
I'm not saying it's _just that easy_ but if a dev hits my interview process and shows they can understand my customer's needs and build out a solution to those needs quickly, I _very much_ want to give them a job.
Do you mind sharing where you live? That’s such an odd concept to me.
Being in The Enterprise, I find it quite frustrating dealing with the new shiny every few years when there's rarely objective analysis behind being made to do so.
Beyond that, IBM has a ton of educational resources you could leverage. At one time they had a program where you could get an account on a mainframe, but I don't know if they do that any more.
Udemy has some mainframe/Cobol tracks. I assume other on-line training does as well.
There are a number of colleges that have mainframe focused degree tracks (Columbus State University has one). These days, you could probably find one that does it on-line.
You absolutely shouldn't learn COBOL before knowing which job you're aiming for. COBOL isn't an interesting or particularly useful language to learn.
Otherwise you're "putting the cart before the horse", so to speak. Plus listing COBOL in your resume can have a detrimental effect in future job interviews, at least at some companies.
The technology stack you choose early on is pretty vital to your career growth. A common way of growing your salary early on is to switch jobs every few years. And to do that successfully, you'll want to have a valuable skill-set that hiring managers are looking for.
For all the talk around here about "fundamentals" being what makes you employable, my experience shows that is not the case. For example, my company doesn't interview candidates without Javascript on their resume because they want people who know and have worked with it. I think it's a dumb policy, but I have no control to change it.
Curious to see a GNU project rely on SourceForge.
https://github.com/victorqribeiro/perceptronCobol
It was a challenge I was able to do in about 4 hours of code I didn't find that much harder to program in a Cobol (given that you use the right IDE, I wrote it in Gedit and the identation was a pain at first)
Otherwise if you live in the Midwest...uw oshkosh use to have one for free. The stipulation was that you had to remove it from the campus. And it weighed 3 tons
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.
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.
> He and his old computer friends played around with some applications that were on the platform, and even made an FTP server that put some data on the internet.
Per https://www.fastcompany.com/3063265/this-teenage-ibm-employe...
Speaking tangentially, there's a project on Sourceforge called Applewood Computers Accounting System https://sourceforge.net/projects/acas/
I had a look at it a few years ago, and decided it probably wasn't suitable for my purposes. Interestingly, I see that it was updated in June of this year. The original code stretches back decades, IIRC, and has been deployed in a commercial setting. I spoke to the author on one occasion.
I have a casual interest in retro stuff, so Cobol was kinda interesting to play with for awhile, but in the end I decided that it was hopelessly impractical.
- 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 Technologies products
- etc!
After couple of decades i learnt about Domain Specific Language (DSL) concept.
I started out coding COBOL and some assembler after learning Pascal and others during education. I now code in python, c, c# or whatever us best fit.
My opinion and experience suggests these are all DSL just as COBOL was probably one of the first. It is excellent for business logic and business transaction oriented data processing.
Like all languages and tools the in output is mostly unreliable garbage in the hands of the ignorant and unskilled/ill-disciplined.
I don't think the popularity of languages is as much to do with their technical merits add it is about the community that builds around each. Each community if like a tribe and the tribes have norms arising from their environment and common needs.
My 2c.
But I reckon the task is more code maintance and slight changes and less writing large amounts of code?
If you however want to build up something new and put your heart into it and revolutionize the world it probably isn't.
But the built-in types are collection types are anemic, it's similar to C in that regard. It's a relatively low-level language compared to other high-level languages. But if I were doing math/simulation stuffs, I would definitely consider using it again.
Just, please, no more embedded programs written in Fortran. That was a bad idea (unless it's doing complex math like for the radar system).
Assembly language is kind of cool, though!
Then what about this?:
import pandas as pd
from matplotlib import pyplot as plt
import numpy as np
import math
from __future__ import print_function
> Real programmers don't write in COBOL. COBOL is for COmmon Business Oriented Laymen who can run neither a business nor a real program.