Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««34567»»

Early Software Expand / Collapse
Author
Message
Posted Monday, February 25, 2013 11:01 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 2:03 PM
Points: 1,334, Visits: 3,069
pdanes (2/22/2013)
It's not obsolete if it still does the job it was designed to do. I've written my share of FORTRAN, RPG, COBOL and who knows what else over the years. No idea if any of it is still running somewhere, but if so, great! There are plenty of tasks that need attention, without inventing silly make-work like replacing fully functional existing code.

Things are only obsolete if they can no longer perform their assigned function. COBOL does not fit that definition by any stretch of the imagination.

There are shops that develop new applications in COBOL today, and do an enormous amount of useful work. Just because it doesn't fit someone's idea of 'the latest and greatest' doesn't mean it's a bad idea to use it.


I agree, and as long as the thing does not change from what it was originally designed to do, then that is absolutely correct. However, as we all know, systems change over time. New enhancements/functionality are either made or required. That is just technology moving forward. Once those enhancements require a capability not currently in legacy PL's like FORTRAN and COBOL, that is when those systems must be upgraded or converted. Obsolute? No, but maybe in dire need of a 21st century face lift? Maybe.


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1423710
Posted Monday, February 25, 2013 11:08 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Tuesday, September 2, 2014 8:37 AM
Points: 751, Visits: 1,917
Carla Wilson-484785 (2/22/2013)
LOL! Does anyone remember APL, "A Programming Language"? That's what hooked me in 1975, because it was an interactive terminal (keyboard, no CRT) back when all the other computer programming classes at my university were key-punched cards with overnight processing. I used it to write some interactive basic statistics tutorials for the statistics class I had just taken (probability and permutations versus combinations).



Speaking of interactive, odd languages, I had quite a fascination with Forth. Basically reverse notation stack oriented environment, with a wonderful (dangerous) interaction between interpreter, compiler and application. Statements and functions could be immediate, or could be designated to come into play during compile/interpretation functions. The application could actually modify the interpreter and the compiler during runtime! With great power comes great responsibility.


...

-- FORTRAN manual for Xerox Computers --
Post #1423713
Posted Monday, February 25, 2013 11:44 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 9:40 AM
Points: 2,379, Visits: 2,744
Still a lot of great responses coming in. But I haven't seen a direct response to the fascinating question by Michael Valentine Jones:

Are there any set based languages besides SQL?


These two sound like possible candidates, but I am very curious to hear from people who have more expert knowledge on this topic.

http://readwrite.com/2011/07/01/new-set-based-programming-language-bandicoot

http://en.wikipedia.org/wiki/Claire_%28programming_language%29

- webrunner


-------------------
"Operator! Give me the number for 911!" - Homer Simpson

"A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
Post #1423724
Posted Monday, February 25, 2013 12:59 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 3:26 PM
Points: 1,675, Visits: 4,779
pdanes (2/22/2013)
It's not obsolete if it still does the job it was designed to do. I've written my share of FORTRAN, RPG, COBOL and who knows what else over the years. No idea if any of it is still running somewhere, but if so, great! There are plenty of tasks that need attention, without inventing silly make-work like replacing fully functional existing code.

Things are only obsolete if they can no longer perform their assigned function. COBOL does not fit that definition by any stretch of the imagination.

There are shops that develop new applications in COBOL today, and do an enormous amount of useful work. Just because it doesn't fit someone's idea of 'the latest and greatest' doesn't mean it's a bad idea to use it.

COBOL is obsolete in the same way that VHS tapes, the Latin language, and muzzle loaded rilfes are obsolete. Of course it's still widely in use, and still works the way it was originally intended, just like all those other things.
Post #1423754
Posted Monday, February 25, 2013 1:11 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 8:59 AM
Points: 2,084, Visits: 2,081
Eric M Russell (2/25/2013)
COBOL is obsolete in the same way that VHS tapes, the Latin language, and muzzle loaded rilfes are obsolete. Of course it's still widely in use, and still works the way it was originally intended, just like all those other things.


The point remains that there is wisdom in not re-writing an entire application for no other reason than to change the language.

Those who understand this still have COBOL applications working well today.

Those who don't understand it waste time and money re-inventing the wheel.
Post #1423760
Posted Monday, February 25, 2013 2:38 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 7:06 AM
Points: 204, Visits: 203
Ditto on the TI-99/4a!..and much the same experience as the OP...writing small programs to solve algebra and physics problems. I even bought the Extended Basic cartridge but the cassette interface went out, and I never really got to use it. I still have the console, joysticks, and all the cartridges. I assume it would still work if I plugged it up. Does anyone remember the Scott Adams Adventure games?
Post #1423779
Posted Monday, February 25, 2013 2:59 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 1:57 PM
Points: 2,359, Visits: 1,431
Dave62 (2/25/2013)
Eric M Russell (2/25/2013)
COBOL is obsolete in the same way that VHS tapes, the Latin language, and muzzle loaded rilfes are obsolete. Of course it's still widely in use, and still works the way it was originally intended, just like all those other things.


The point remains that there is wisdom in not re-writing an entire application for no other reason than to change the language.

Those who understand this still have COBOL applications working well today.

Those who don't understand it waste time and money re-inventing the wheel.


Dave,

Would you suggest developing a massive new system that is PC friendly in COBOL?

You see I do not believe COBOL is obsolete, but I do believe that it is "contained" for the most part and that most new development will be in a non-COBOL platform.

Yes I have written COBOL, three mainframe versions and AS-400 to boot. Have not touched it for almost 17 years. And some if it still runs well. But all new is in something else.

M.


Not all gray hairs are Dinosaurs!
Post #1423787
Posted Tuesday, February 26, 2013 6:29 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 8:59 AM
Points: 2,084, Visits: 2,081
Miles Neale (2/25/2013)
Dave,

Would you suggest developing a massive new system that is PC friendly in COBOL? ...

Definitely not.

I do .NET development and SQL Server development/administration. The last company I worked for had a lot of COBOL running on an AS400. We would leave the COBOL alone as long as it was running fine and didn't need anything new added. As soon as maintenance issues or new features came up we would work on a conversion path.

We had no need, interest, or time to bother with re-writing it just for the sake of changing the language.
Post #1424052
Posted Tuesday, February 26, 2013 9:54 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 1:57 PM
Points: 2,359, Visits: 1,431
Dave62 (2/26/2013)
Miles Neale (2/25/2013)
Dave,

Would you suggest developing a massive new system that is PC friendly in COBOL? ...

Definitely not.

I do .NET development and SQL Server development/administration. The last company I worked for had a lot of COBOL running on an AS400. We would leave the COBOL alone as long as it was running fine and didn't need anything new added. As soon as maintenance issues or new features came up we would work on a conversion path.

We had no need, interest, or time to bother with re-writing it just for the sake of changing the language.


Dave,

I think that you and I are on common ground. Don't fix what isn't broken.

Thanks...


Not all gray hairs are Dinosaurs!
Post #1424161
Posted Tuesday, February 26, 2013 10:25 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 3:26 PM
Points: 1,675, Visits: 4,779
Miles Neale (2/26/2013)
Dave62 (2/26/2013)
Miles Neale (2/25/2013)
Dave,

Would you suggest developing a massive new system that is PC friendly in COBOL? ...

Definitely not.

I do .NET development and SQL Server development/administration. The last company I worked for had a lot of COBOL running on an AS400. We would leave the COBOL alone as long as it was running fine and didn't need anything new added. As soon as maintenance issues or new features came up we would work on a conversion path.

We had no need, interest, or time to bother with re-writing it just for the sake of changing the language.


Dave,

I think that you and I are on common ground. Don't fix what isn't broken.

Thanks...

I agree that most of these legacy COBOL processes should be left in place unless there is a return on investment to re-write them. When it comes to batch processing flat files, I guess COBOL is state of the art, if that's the limit of your current data processing needs. For many organizations, going from COBOL to a relational SQL database wouldn't be just an upgrade of programming code, but also an upgrade of the hardware, OS, and staff as well.

Likewise, I've got a 2002 mini-van that was paid for several years back. It gets 15 MPG, drips oil, and one of the sliding doors doesn't work right, but I have no plans to replace it with a new $$,$$$ hybrid until the thing stops running. Especially since I'm not the family member who drives it every day.
Post #1424173
« Prev Topic | Next Topic »

Add to briefcase «««34567»»

Permissions Expand / Collapse