Jabo

We have some programs we use at work that were written in Cobol. We have basically 2 options, learn Cobol or convert to another language. I'm assured by the guy who wrote them that Cobol is easy to pick up, but which would be easier/quicker? Either way I'm going to have to have at least a rudimentary understanding of Cobol to work with.

lectricpharaoh

This statement is the truth of it. If you decide to keep the COBOL codebase, and maintain it, you (as in 'someone at the company', not necessarily you in particular) are going to need to learn it. If you choose to convert the COBOL codebase to another language to ease maintenance and upgrade issues, you will need to learn it to accomplish this, which means you're gonna need to pick up at least the basics, either way. How much you'll need to learn depends on the volume and complexity of the code involved.

As to the issue of whether or not to convert, you can only make that decision after reviewing the code. Do this, form an opinion of which makes more sense, and present your business case to management, as they will have the ultimate say in the matter. As long as you can justify your position in terms of the bottom line, odds are they'll be on board.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

Jabo

I'll be working with the guy who wrote the programs, so permission isn't an issue. He either wants me to learn Cobol, or he wants to learn VB. I think, as a matter of pride, he'd rather see his programs left in Cobol, but he has pressures from others to convert.

Adak

I would vote to convert the program, but perhaps not to VB. Forget what the original programmer wants - this is the business's program, and the business's benefits in this, should be the only consideration. Who cares what the original programmer would like to do or to learn for his next language?

Grow a pair, and learn who you work for, and to whom you owe a fiduciary relationship. It's not "Joe the Programmer"!

You have to look further ahead - new hires will be replacing the original programmer and yourself eventually, and they won't know COBOL, either. So keeping the program in COBOL will lead to a whole string of employee's or contractors having to learn COBOL.

Beyond the obvious expense, there's a definite drop in the quality of the code, likely to occur.

Rather than acquiesce to what he likes, I'd consider Python, Java, and C++ (not necessarily using OOP), and look to the long term future benefit of having the program in a language that new programmers would probably know, already.

IMO VB is not a popular language. What's your opinion?

Jabo

It's not about my balls, it's about what is going to make more sense lol. Thanks for the input guys!

melbolt

If it were me I'd learn cobol. Mainly because the programs already do what they're supposed to, the only situation where I'd convert them would be if the program is going to change signifigantly in the future. Besides, cobol is a valuable resume builder, a lot of companies still run cobol programs because they do what they need them to do and its not worth spending the money to rebuild them for no reason at all.

__________________
I have never let my schooling interfere with my education. -Mark Twain-

Xbox live gamertag: melbolt

Infinite Recursion

The only companies I have seen that run Cobol have been banks. The fact is, you will have to learn a bit of Cobol either way. If you find Cobol to be easy to code in and the source is relatively small... keep it in Cobol. Otherwise, convert it to a mainstream language, C++/C#/Java/Python, so that the programmers after you that are tasked with maintaining it will not have to learn Cobol.

I worked with several C programmers when I first came on board at my current job. The first thing I did was covert all of their "babies" to C++. If you inherit the project, you make the decision on which language to maintain the application in.

__________________
http://jasonpowers.net

"There are a thousand hacking at the branches of evil to one who is striking at the root."

Arla

Missing some information on what the problem is, my "variables" on whether to change it

1. How big/complex are the programs? The bigger more complex, the more of a job it's going to be to convert them to another language, and the more likely you'll introduce unintended bugs

2. What platform is it running on, mainframes are almost the exclusive domain of cobol, while I've rarely seen cobol run on mid-range or PC.

3. How significant are future changes going to be? if it's minor bug fixing here and there, it's far easier to leave the program that's working where it is, if it's major changes.revisions maybe it's time to document what it does and move it to some other language.

That's my high level thoughts at least.

Adak

Call it spine then, if you like. You mentioned the concerns of the original programmer twice in your post.

Somehow, you never mentioned the concerns of *your employer* in your description!

IMO a sensible solution is to look ONLY to the concerns of the one who pays you, and not to the feelings of the original programmer.

Jabo

It's not about whether or not I have the gall to change his program. It's his program to do what he wants with it. He's giving me a chance to gain some experience in programming in a professional environment, and it's his decision. The pressures he's receiving is from the server admin, but we're a small (relatively) group and it's going to go the way it goes, if you know what I mean. He has expressed that someone is going to have to maintain the applications when he leaves (sooner or later), so....

Point is, it's not an imperative to convert, and it's not an imperative to keep it in Cobol, it's not that big a deal either way as long as it works and works well. Let me put it this way...the only issues with his program have been network related, from what I'm told. So would it make more sense to convert to a language with more robust networking capabilities, or is this not even an issue with Cobol.