So I imagine that most readers of this list have heard that a number of US
states are actively looking for COBOL programmers.
If you have not, the background is that, in the US, a number of
unemployment insurance systems have mainframe backends running applications
mostly written in COBOL. Due to the economic downturn as a result of
COVID-19, these systems are being overwhelmed with unprecedented numbers of
newly-unemployed people filing claims. The situation is so dire that the
Governor of New Jersey mentioned it during a press conference.
This has led to a number of articles in the popular press about this
situation, some rather sensational: "60 year old programming language
prevents people filing for unemployment!" E.g.,
https://www.cnn.com/2020/04/08/business/coronavirus-cobol-programmers-new-j…
On the other hand, some are rather more measured:
https://spectrum.ieee.org/tech-talk/computing/software/cobol-programmers-an…
I suspect the real problem is less "COBOL and mainframes" and more
organizational along the lines of lack of investment in training,
maintenance and modernization. I can't imagine that bureaucrats are
particularly motivated to invest in technology that mostly "just works."
But the news coverage has led to a predictable set of rebuttals from the
mainframe faithful on places like Twitter; they point out that COBOL has
been updated by recent standards in 2002 and 2014 and is being unfairly
blamed for the present failures, which arguably have more to do with
organizational issues than technology. However, the pendulum seems to have
swung too far with their arguments in that they're now asserting that COBOL
codebases are uniformly masterworks. I don't buy that.
I find all of this interesting. I don't know COBOL, nor all that much about
it, save for some generalities about its origin and Grace Hopper's
involvement in its creation. However, in the last few days I've read up on
it a bit and see very little to recommend it: the type and scoping rules
are a mess, things like the 'ALTER' statement and the ability to cascade
procedure invocations via the 'THRU' keyword seem like a recipe for
spaghetti code, and while they added an object system in 2002, it doesn't
seem to integrate with the rest of the language coherently and I don't see
it doing anything that can't be done in any other OO language. And of
course the syntax is abjectly horrible. All in all, it may not be the cause
of the current problems, but I don't know why anyone would be much of a fan
of it and unless you're already sitting on a mountain of COBOL code (which,
in fairness, many organizations in government, insurance and finance
are...) I wouldn't invest in it.
I read an estimate somewhere that there are something like 380 billion
lines of COBOL out there, and another 5 billion are written annually
(mostly by body shops in the BRIC countries?). That's a lot of code; surely
not all of it is good.
So....What do folks think? Is COBOL being unfairly maligned simply due to
age, or is it really a problem? How about continued reliance on IBM
mainframes: strategic assets or mistakes?
- Dan C.
(PS: I did look up the specs for the IBM z15. It's an impressive machine,
but without an existing mainframe investment, I wouldn't get one.)
Hello:
Im apologize for the OT but Im desperately looking for the answer to a
question regarding BitKeeper and, since I heard about its vitues and
also about it becoming open source in this list, I thought you guys
wouldn't mind helping me find the answer to my problem.
I've been using Git for some time now, but after hearing here about BK,
Im trying it out to see if I can change to it. At the moment I'm quite
happy with it and I very much like it's smaller than Git.
In Git I use a remote SSH "original" repo instead of a public (HTTP)
service, since I want to have distributed copies (several workstations
and laptops) and a "non interactive" copy on a server of mine. I'm not
sure I am making a lot of sense, since I'm not very expert on Git either
(I just use a few basic functions) and English isn't my first language.
What I actually need/want is to create a remote SSH repo from my local
(working) repo. I haven't found how to do that neither in the
documentation nor the Users Forum. Alas I havent found a mailing list to
subscribe to and ask for help. That's why I'm asking you guys for help.
Again sorry for the OT and thank you so much for reading until here. :)
Cheers,
Ángel
Way back then, when dinosaurs strode the earth and System/360 reigned
supreme, we were taught to slash our zeros and sevens (can't quite find
the glyphs for them right now) in order to distinguish them from Oscars
and Ones for the benefit of the keypunch girls (yes, really; I had the
hots for one of them at one time, but someone else took her) on those
green sheets.
In the time-mean I also saw a slash through "Z" (Zulu, Zed, Zee) in order
to distinguish it from a "2" (FIGURES TWO); WTF? And you *never* slashed
your ones, lest thou ended up with the contents of an 029 chad-box over
thine head...
These days, I merely slash my sevens by habit and it doesn't even raise an
eyebrow; even Oz Pigeon Post's mail mangler seems to accept it[*].
What're other bods' experiences?
[*]
Don't even mention Redfern, OK? Just don't... And as for getting off at
Redfern, well, I did a few times when I had a contract job around there.
-- Dave, bored at home
Remember I learned slashing my zeroes, small bar in sevens and zets,
curly letter X.
This was when a studied Mathematics fro a while at the University of
Technology in Delft, the Netherlands.. I think it had to do with
avoiding misunderstandings in scribbled formulars in a time we still
did a lot of real writing semester papers. This was around mid-70tish
for me.
Anybody feel like a text/voice chat on the ClassicCmp Discord server in about 13 hours, say 2200 UTC?
#coff and the General voice channel.
I'll pop on for an hour but start whenever you feel like.
Cheers, Warren
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On Thu, 19 Mar 2020, Mike Markowski wrote:
>> I've been using my trusty HP-42S for so long that I can hardly remember
>> how to use a "normal" calculator :-)
>
> When my classmate's calculator died during an engineering exam, he asked
> if he could borrow my spare. I handed him my HP 32s and after a minute
> he whispered, "Where's the equals key?" He gave my calculator back.
> :-)
I did that to a financial controller in a previous life; she was not
amused... Hey, it was the only calculator that I had! I could see her
helplessly looking for the "=" key, then I took pity on her.
-- Dave
+COFF
On 3/20/20 8:03 AM, Noel Chiappa wrote:
> Maybe I'm being clueless/over-asking, but to me it's appalling that
> any college student (at least all who have _any_ math requirement at
> all; not sure how many that is) doesn't know how an RPN calculator
> works.
I'm sure that there are some people, maybe not the corpus you mention,
that have zero clue how an RPN calculator works. But I would expect
anybody with a little gumption to be able to poke a few buttons and
probably figure out the basic operation, or, ask if they are genuinely
confused.
> It's not exactly rocket science, and any reasonably intelligent
> high-schooler should get it extremely quickly; just tell them it's
> just a representational thing, number number operator instead of
> number operator number.
I agree that RPN is not rocket science. And for basic single operation
equations, I think that it's largely interchangeable with infix notation.
However, my experience is, as the number of operations goes up, RPN can
become more difficult to use. This is likely a mental shortcoming on my
part. But it is something that does take tractable mental effort for me
to do.
For example, let's start with Pythagorean Theorem
a² + b² = c²
This is relatively easy to enter in infix notation on a typical
scientific calculator.
However, I have to stop and think about how to enter this on an RPN
calculator. I'll take a swing at this, but I might get it wrong, and I
don't have anything handy to test at the moment.
[a] [enter]
[a] [enter]
[multiply]
[b] [enter]
[b] [enter]
[multiply]
[add]
[square root] # to solve for c
(12 keys)
Conversely infix notation for comparison.
[a]
[square]
[plus]
[b]
[square]
[square root]
(6 keys)
As I type this, I realize that I'm using higher order operations
(square) in infix than I am in RPN. But that probably speaks to my
ignorance of RPN.
I also realize that this equation does a poor job at demonstrating what
I'm trying to convey. — Or perhaps what I'm trying to convey is
incorrect. — I had to arrange sub-different parts of the equation so
that their results ended up together on the stack for them to be the
targets of the operation. I believe this (re)arrangement of the
equation is where most of my mental load / objection comes from with
RPN. I feel like I have to process the equation before I can tell the
calculator to compute the result for me. I don't feel like I have this
burden with infix notation.
Aside: I firmly believe that computers are supposed to do our bidding,
not the other way around. s/computers/calculators/
> I know it's not a key intellectual skill, but it does seem to me to
> be part of comon intellectual heritage that everyone should know,
> like musical scales or poetry rhyming. Have you ever considered
> taking two minutes (literally!) to cover it briefly, just 'someone
> tried to borrow my RPN calculator, here's the basic idea of how they
> work'?
I'm confident that 80% of people, more of the corpus you describe, could
use an RPN calculator to do simple equations. But I would not be
surprised if many found that the re-arrangement of equations to being
RPN friendly would simply forego the RPN calculator for simpler
arithmetic operations.
I think some of it is a mental question: Which has more mental load,
doing the annoying arithmetic or re-arranging to use RPN.
I believe that for the simpler of the arithmetic operations, RPN is
going to be more difficult.
All of this being said, I'd love to have someone lay out points and / or
counterpoints to my understanding.
--
Grant. . . .
unix || die
