Hacker News Reader

Comment by t1m | Hacker News Reader

I remember showing my "systems analyst" brother-in-law my second year university schedule when I was planning which courses I would take that fall.

"You don't have any Cobol, PL/1, OS360 Assembly Language or APL on here", he observed.

"I am going to focus on C, Unix and operating systems. I want to write compilers for microprocessor based computers".

When he finished laughing, he called me "unemployable" and said, "microprocessors will never be used for anything but toys. Take COBOL!"

Since then, I have made a point of not even looking at COBOL code. I have been in the presence of COBOL, but have averted my eyes.

View on HN

There was once a programmer who wrote software for personal computers. "Look at how well off I am here," he said to a mainframe programmer who came to visit. "I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self-consistent and easy-to-use. Why do you not quit your present job and join me here?"

The mainframe programmer then began to describe his system to his friend, saying, "The mainframe sits like an ancient Sage meditating in the midst of the Data Center. Its disk drives lie end-to- end like a great ocean of machinery. The software is as multifaceted as a diamond, and as convoluted as a primeval jungle. The programs, each unique, move through the system like a swift-flowing river. That is why I am happy where I am."

The personal computer programmer, upon hearing this, fell silent. But the two programmers remained friends until the end of their days.

The Tao of Programming, 8.3 http://www.mit.edu/~xela/tao.html

The wise programmer is told about Tao and follows it. The average programmer is told about Tao and searches for it. The foolish programmer is told about Tao and laughs at it.

From the Tao of programming, 1.2:

The Tao gave birth to machine language. Machine language gave birth to the assembler.

The assembler gave birth to the compiler. Now there are ten thousand languages.

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.

4.2:

The Master was explaining the nature of Tao to one of his novices.

"The Tao is embodied in all software -- regardless of how insignificant," said the Master.

"Is the Tao in a hand-held calculator?" asked the novice.

"It is," came the reply.

"Is the Tao in a video game?" asked the novice.

"It is even in a video game," said the Master.

"Is the Tao in the DOS for a personal computer?" asked the novice.

The Master coughed and shifted his position slightly. "The lesson is over for today," he said.

That is how I feel every time I learn a new web framework.

In 1999, a COBOL programmer, tasked with updating bank software for the year Y2K switch, became overwhelmed.

"Look at all of this code!" he exclaimed. "I'll never be able to fix it all in time!"

Horrified by the media depictions of apocalypse brought by financial meltdown and software-launched nuclear warheads, all because of the Y2K bug, he became very anxious.

So, he went to the cryogenic freezing facility and told them, "Wake me up when Y2K is over."

He laid in the cryotube and gently fell asleep as the cold began to overtake him.

The next thing he knew, he was laying on a bed in a warm room, bright lights and white walls giving the room a certain sterility. A doctor in a lab coat was standing over him holding a clipboard.

"Oh, thank heavens!" said the programmer. "We've made it out alive!"

"Yes," said the doctor. "The year is 2999, and it says in your chart you know COBOL?"

And yet, if you didn't mind that kind of work, you could have been making a fortune from 1999 to now. You'll be retired before COBOL is no longer used.

There is a large market for maintaining legacy COBOL, SNOBOL, and various esoteric assembly codebases. Additionally APL and its derivatives are not entirely dead.

SNOBOL should be looked at, if for nothing else, for its string handling (add a brief look at Icon right afterwards). I would have killed to take APL in college, but despite having to program on an IBM 370 mainframe, no classes were offered. I'm still a little ticked.

It's never too late to start playing with APL. I started around the time GNU APL was released (a few years ago), and I'm having fun with it.

I also ended up writing the Emacs integration for it. Please give it a try.

I have over the years played with it, but I was rather annoyed that having to put up with all the disadvantages of using an IBM 370 that we didn't get some advantages.

There's a nice overview of APL here: http://www.zerobugsandprogramfaster.net/essays/5b.html

I've been interested in getting into this market. Can you point me to these jobs?

And depending on when your brother-in-law made the statement, he stood just as much of a chance or greater of being right than you did. COBOL will always be around (those 80 billion lines of code don't maintain themselves), but microprocessor and PCs could have broken any number of ways. Granted, a good knowledge of C and Unix will go a long way and be applicable to whatever ends up "winning", but it was no guarantee to the exact language and OS that would keep one employed.

> those 80 billion lines of code don't maintain themselves

They kind of do sometimes. I know a guy who makes part of his living maintaining the emulation system that runs COBOL.

My interests in C, compilers, small computers and Unix at the time wasn't driven by career aspirations. I was just genuinely interested those things. Maybe I was "unemployable".

* I was just genuinely interested those things.*

Meh, I'm down with that. I would be a much richer man today had I chosen more wisely. But I would not be a happier man.

Maybe I was "unemployable".

Despite my comment to the (somewhat) contrary, as long as you're not specialist in BeOS or the like, in software you'll almost always make money doing what you like to do. Again, whatever ends up winning, the abstractions and concepts you pick up will generally prove useful where ever you end up. You might not be raking in the Benjamins like your SAP buddy over there pulling down $350K/year, but you'll be relatively wealthy and happy.

In the late 80's, my academic advisor said he wouldn't sign off on me taking a COBOL class because that was a business department IT class and would not go with the rest of my studies[1]. I wasn't really into the idea anyway and filled my schedule with other classes. I do wonder what other CompSci departments at the time were doing.

1) EE was the sole teacher of FORTRAN and I decided against that also, more from a teacher problem than a lack of desire to learn FORTRAN which I later did (without the all caps).

Why the business department? Were they still under the illusion that COBOL would allow business types to write their own code?

You know, I really didn't know then or now. The Business school taught COBOL and RPG on, I do believe, an AS/400 they owned separate from the rest of the computer infrastructure. I might be remembering wrong, but I was pretty sure that was the story[1]. I think it was something to do with the information systems degree requirements.

1) my Dad did IT on an AS/400, I still hear "wand in" instead of login.

[edit] looks like the new requirements are a bit more inline with today's world http://business.und.edu/undergraduate/school-of-entrepreneur...

We had it too (I went to a mixed IT-business university). I think the idea was to get some perspective on what COBOL is, so if you're managing a company one day and IT people you hire tell you that something is hard to do, or takes too much time because the system is in COBOL, you know what they're talking about and don't think that they're just messing with you.

Reply on news.ycombinator.com