Re: "... there will always be a niche market for every language but if you mean 'come back' like COBOL would become the average developer's language of choice I would curtly retort with a sharp 'ha.'"
Quite true - the "average developer" has to deal with the environment he/she is in. If that environment is not COBOL, then COBOL makes no sense at all.
HOWEVER... where the environment IS COBOL, it makes perfect sense, does it not? Why get rid of COBOL just because it's COBOL??
The ONLY "come back" COBOL needs to make is to come back out from under the ginormous mountains of ignorance and 80' - 90's client server marketing hype and mythology, into being understood as the superb language of choice for developing solid, portable (if properly standardized) mainframe business applications...
COBOL make a "comeback"? HAH! -- it never left in the first place !
my bad -- I thought that the terms, "resident Slashdot denizens" and "intelligence" were mutually exclusive if not/and/or an oxymoron (as opposed to real morons -- or in addition to real morons, or the same as real morons... ?)
nope - I'm my own person -- nobody's shill... (shill indeed!... what a shilly idea) - just Columbus all over again - tellin' the flat-lined world folks that the world is round... sail on, silver girl
VETERAN COBOL PROGRAMMER (1974 - 2008) HERE SPEAKING! PLEASE LISSEN UP! (ignorance is a costly commodity that few people or businesses can afford).
If you read through these posts "statistically" you will find a preponderance of gripes and "apples-to-oranges" comparisons. Poorly-written, poorly maintained, old, old, OLD code is - you guessed it, REALLY unpleasant for everyone (we seem to have that point of view well-covered). How many 40-year-old JAVA apps has anyone worked on lately, hmmm?
NEWS FLASH! GET THIS! please! (don't be ignorant). Believe it or not, there is a HUGE difference between "COBOL", and poorly-written, poorly maintained, old, old, OLD code that happens to be written in COBOL. Did you get that?
What is getting bashed is poorly-written, poorly maintained, old, old, OLD code - and people are mistakenly thinking they are bashing COBOL - a bit ignorant, you might say?
Moving on to the bright side - as a few have tried to point out here, besides the all-too common, all-too prevalent preponderance of poorly-written, poorly maintained, old, old, OLD code - there ARE companies running their businesses RATHER HAPPILY on some WELL-WRITTEN, WELL-MAINTAINED, new, clean, modularized code that just HAPPENS to be written in (are you READY!) - ta-dah!: COBOL!!!! Yeah! Honest - it happens.
OK - yeah - these are mainframes - they're the machines that suck up, and hold, and process, and route, and re-route, the billions of transactions that all you little JAVA applets and PERL folks toss around out there. OK - to be fair - I would NOT want to have to try to do some of the customer-facing stuff you guys do - not in COBOL -- in fact I couldn't. COBOL is not intended to do everything. So I am not belittling ANY other language. Just understand, NO language is any better than it's deployment and/or maintenance. But COBOL DOES let me design, develop, and maintain HUGE apps - almost anywhere in the world - EASILY! Hard to Learn? Why heck, I've bought my house, cars, you name it, using about a dozen or so words: OPEN, READ, WRITE, MOVE, ADD, SUBTRACT, COMPUTE, IF, AND, OR, ELSE, NOT, END, PERFORM, GO TO (we don't like to use that one a lot), CLOSE, STOP RUN. Now - that wasn't so bad, was it?
To the REALLY bright side - you should just SEE what can be done on an Unisys Clearpath or Libra (running with a fiber optic disk sub-system) using COBOL85 (or higher) with intrinsic functions, scope terminators, etc, etc, using WFL (a highly-programmable "jcl"), DMSII and COMS - FULLY-AUTOMATED DATABASE ROLLBACK AND RECOVERY, ZERO transaction loss (out of billions)... Oh awright, I know, mainframes are not for everybody...
My heartfelt sympathy goes to those who have suffered, and are currently suffering under code which is the result of years of neglect, abuse, mismanagement, political decisions (sadly, "IBM" JCL, VSAM,... etc.). Sadly - you have not a CLUE as to just how good COBOL can be - and it's not likely that many of you ever will.
PS - there are PLENTY of sites on the web for those who are interested in lowering their CIQ (COBOL Ignorance Quotient).
Meanwhile, let's not continue to confuse bad code that is written in COBOL with COBOL itself, and let's all educate ourselves about a language that has billions of lines of code -- most of them fairly potable, and maintained by only 90K pprogrammers.
OK - VETERAN COBOL PROGRAMMER (1974 - 2008) HERE SPEAKING! PLEASE LISSEN UP! (ignorance is a costly commodity that few people or businesses can afford).
How many 40-year-old JAVA apps has anyone worked on lately, hmmm?
OK - NEWS FLASH! GET THIS! please! (don't be ignorant). Believe it or not, there is a HUGE difference between "COBOL", and poorly-written, poorly maintained, old, old, OLD code that happens to be written in COBOL. Did you get that?
What is getting bashed is poorly-written, poorly maintained, old, old, OLD code - and people are mistakenly thinking they are bashing COBOL - a bit ignorant, you might say?
As a few have tried to point out here, there ARE companies running their businesses RATHER HAPPILY on some WELL-WRITTEN, WELL-MAINTAINED, new, clean, modularized code that just HAPPENS to be written in (are you READY!) - ta-dah!: COBOL!!!! Yeah! Honest - it happens.
To be fair - COBOL is not intended to do everything. So I am not belittling ANY other language. Just understand, NO language is any better than it's deployment.
But COBOL DOES let me design, develop, and maintain HUGE apps - almost anywhere in the world - EASILY! You should just SEE what can be done on an Unisys Clearpath or Libra (running
with a fiber optic disk sub-system) using COBOL85 (or higher) with intrinsic functions, scope terminators, etc., etc., using WFL (a highly-programmable "jcl"), DMSII and COMS - FULLY-AUTOMATED DATABASE ROLLBACK AND RECOVERY,
ZERO transaction loss (out of billions!).
My heartfelt sympathy goes to those who have suffered, and are currently suffering under code which is the result of years of neglect, abuse, mismanagement, political decisions (sadly, "IBM" JCL, VSAM,... etc. - I, too have worked with some COBOL installations from the pits of hell). Sadly, you have not a CLUE as to just how good COBOL can be - and it's not likely that many of you ever will.
There are PLENTY of sites on the web for those who are interested in lowering their CIQ (COBOL Ignorance Quotient). Meanwhile, let's not continue to confuse bad code that is written in COBOL with COBOL itself.
WHEW! Is this a religious war or something?
OK - VETERAN COBOL PROGRAMMER (1974 - 2008) HERE SPEAKING! PLEASE LISSEN UP! (ignorance is a costly commodity that few people or businesses can afford).
If you read through these posts "statistically" you will find a preponderance of gripes and "apples-to-oranges" comparisons. Poorly-written, poorly maintained, old, old, OLD code is - you guessed it, REALLY unpleasant for everyone (we seem to have that point of view well-covered). How many 40-year-old JAVA apps has anyone worked on lately, hmmm?
OK - NEWS FLASH! GET THIS! please! (don't be ignorant). Believe it or not, there is a HUGE difference between "COBOL", and poorly-written, poorly maintained, old, old, OLD code that happens to be written in COBOL. Did you get that?
What is getting bashed is poorly-written, poorly maintained, old, old, OLD code - and people are mistakenly thinking they are bashing COBOL - a bit ignorant, you might say?
OK - moving on to the bright side. As a few have tried to point out here, besides the all-too common, all-too prevalent preponderance of poorly-written, poorly maintained, old, old, OLD code - there ARE companies running their businesses RATHER HAPPILY on some WELL-WRITTEN, WELL-MAINTAINED, new, clean, modularized code that just HAPPENS to be written in (are you READY!) - ta-dah!: COBOL!!!! Yeah! Honest - it happens.
OK - yeah - these are mainframes - they're the machines that suck up, and hold, and process, and route, and re-route, the billions of transactions that all you little JAVA applets and PERL folks toss around out there. OK - to be fair - I would NOT want to have to try to do some of the customer-facing stuff you guys do - not in COBOL -- in fact I couldn't. COBOL is not intended to do everything. So I am not belittling ANY other language. Just understand, NO language is any better than it's deployment and/or maintenance. But COBOL DOES let me design, develop, and maintain HUGE apps - almost anywhere in the world - EASILY! Hard to Learn? Why heck, I've bought my house, cars, you name it, using about a dozen or so words: OPEN, READ, WRITE, MOVE, ADD, SUBTRACT, COMPUTE, IF, AND, OR, ELSE, NOT, END, PERFORM, GO TO (we don't like to use that one a lot), CLOSE, STOP RUN. Now - that wasn't so bad, was it?
NOW - to the REALLY bright side - you should just SEE what can be done on an Unisys Clearpath or Libra (running with a fiber optic disk sub-system) using COBOL85 (or higher) with intrinsic functions, scope terminators, etc, etc, using WFL (a highly-programmable "jcl"), DMSII and COMS - FULLY-AUTOMATED DATABASE ROLLBACK AND RECOVERY, ZERO transaction loss (out of billions)... Oh awright, I know, mainframes are not for everybody...
My heartfelt sympathy goes to those who have suffered, and are currently suffering under code which is the result of years of neglect, abuse, mismanagement, political decisions (sadly, "IBM" (JCL, VSAM,... etc.)
Sadly - you have not a CLUE as to just how good COBOL can be - and it's not likely that many of you ever will.
(oops-- just had a spike in my transaction volume - I'm almost at 30% capacity - gotta go - ta-ta)... tum-de-dumm (love my Unisys)
PS - there are PLENTY of sites on the web for those who are interested in lowering their CIQ (COBOL Ignorance Quotient).
Meanwhile, let's not continue to confuse bad code that is written in COBOL with COBOL itself, and let's all educate ourselves about a language that has billions of lines of code -- most of them fairly potable, and maintained by only 90K pprogrammers.
Slashdot Mirror
Re: " ... there will always be a niche market for every language but if you mean 'come back' like COBOL would become the average developer's language of choice I would curtly retort with a sharp 'ha.'"
Quite true - the "average developer" has to deal with the environment he/she is in. If that environment is not COBOL, then COBOL makes no sense at all.
HOWEVER ... where the environment IS COBOL, it makes perfect sense, does it not? Why get rid of COBOL just because it's COBOL??
The ONLY "come back" COBOL needs to make is to come back out from under the ginormous mountains of ignorance and 80' - 90's client server marketing hype and mythology, into being understood as the superb language of choice for developing solid, portable (if properly standardized) mainframe business applications ...
COBOL make a "comeback"? HAH! -- it never left in the first place !
my bad -- I thought that the terms, "resident Slashdot denizens" and "intelligence" were mutually exclusive if not/and/or an oxymoron (as opposed to real morons -- or in addition to real morons, or the same as real morons ... ?)
nope - I'm my own person -- nobody's shill ... (shill indeed! ... what a shilly idea) - just Columbus all over again - tellin' the flat-lined world folks that the world is round ... sail on, silver girl
VETERAN COBOL PROGRAMMER (1974 - 2008) HERE SPEAKING! PLEASE LISSEN UP! (ignorance is a costly commodity that few people or businesses can afford). If you read through these posts "statistically" you will find a preponderance of gripes and "apples-to-oranges" comparisons. Poorly-written, poorly maintained, old, old, OLD code is - you guessed it, REALLY unpleasant for everyone (we seem to have that point of view well-covered). How many 40-year-old JAVA apps has anyone worked on lately, hmmm? NEWS FLASH! GET THIS! please! (don't be ignorant). Believe it or not, there is a HUGE difference between "COBOL", and poorly-written, poorly maintained, old, old, OLD code that happens to be written in COBOL. Did you get that? What is getting bashed is poorly-written, poorly maintained, old, old, OLD code - and people are mistakenly thinking they are bashing COBOL - a bit ignorant, you might say? Moving on to the bright side - as a few have tried to point out here, besides the all-too common, all-too prevalent preponderance of poorly-written, poorly maintained, old, old, OLD code - there ARE companies running their businesses RATHER HAPPILY on some WELL-WRITTEN, WELL-MAINTAINED, new, clean, modularized code that just HAPPENS to be written in (are you READY!) - ta-dah!: COBOL!!!! Yeah! Honest - it happens. OK - yeah - these are mainframes - they're the machines that suck up, and hold, and process, and route, and re-route, the billions of transactions that all you little JAVA applets and PERL folks toss around out there. OK - to be fair - I would NOT want to have to try to do some of the customer-facing stuff you guys do - not in COBOL -- in fact I couldn't. COBOL is not intended to do everything. So I am not belittling ANY other language. Just understand, NO language is any better than it's deployment and/or maintenance. But COBOL DOES let me design, develop, and maintain HUGE apps - almost anywhere in the world - EASILY! Hard to Learn? Why heck, I've bought my house, cars, you name it, using about a dozen or so words: OPEN, READ, WRITE, MOVE, ADD, SUBTRACT, COMPUTE, IF, AND, OR, ELSE, NOT, END, PERFORM, GO TO (we don't like to use that one a lot), CLOSE, STOP RUN. Now - that wasn't so bad, was it? To the REALLY bright side - you should just SEE what can be done on an Unisys Clearpath or Libra (running with a fiber optic disk sub-system) using COBOL85 (or higher) with intrinsic functions, scope terminators, etc, etc, using WFL (a highly-programmable "jcl"), DMSII and COMS - FULLY-AUTOMATED DATABASE ROLLBACK AND RECOVERY, ZERO transaction loss (out of billions)... Oh awright, I know, mainframes are not for everybody ...
My heartfelt sympathy goes to those who have suffered, and are currently suffering under code which is the result of years of neglect, abuse, mismanagement, political decisions (sadly, "IBM" JCL, VSAM, ... etc.). Sadly - you have not a CLUE as to just how good COBOL can be - and it's not likely that many of you ever will.
PS - there are PLENTY of sites on the web for those who are interested in lowering their CIQ (COBOL Ignorance Quotient).
Meanwhile, let's not continue to confuse bad code that is written in COBOL with COBOL itself, and let's all educate ourselves about a language that has billions of lines of code -- most of them fairly potable, and maintained by only 90K pprogrammers.
OK - VETERAN COBOL PROGRAMMER (1974 - 2008) HERE SPEAKING! PLEASE LISSEN UP! (ignorance is a costly commodity that few people or businesses can afford). How many 40-year-old JAVA apps has anyone worked on lately, hmmm? OK - NEWS FLASH! GET THIS! please! (don't be ignorant). Believe it or not, there is a HUGE difference between "COBOL", and poorly-written, poorly maintained, old, old, OLD code that happens to be written in COBOL. Did you get that? What is getting bashed is poorly-written, poorly maintained, old, old, OLD code - and people are mistakenly thinking they are bashing COBOL - a bit ignorant, you might say? As a few have tried to point out here, there ARE companies running their businesses RATHER HAPPILY on some WELL-WRITTEN, WELL-MAINTAINED, new, clean, modularized code that just HAPPENS to be written in (are you READY!) - ta-dah!: COBOL!!!! Yeah! Honest - it happens. To be fair - COBOL is not intended to do everything. So I am not belittling ANY other language. Just understand, NO language is any better than it's deployment. But COBOL DOES let me design, develop, and maintain HUGE apps - almost anywhere in the world - EASILY! You should just SEE what can be done on an Unisys Clearpath or Libra (running with a fiber optic disk sub-system) using COBOL85 (or higher) with intrinsic functions, scope terminators, etc., etc., using WFL (a highly-programmable "jcl"), DMSII and COMS - FULLY-AUTOMATED DATABASE ROLLBACK AND RECOVERY, ZERO transaction loss (out of billions!). My heartfelt sympathy goes to those who have suffered, and are currently suffering under code which is the result of years of neglect, abuse, mismanagement, political decisions (sadly, "IBM" JCL, VSAM, ... etc. - I, too have worked with some COBOL installations from the pits of hell). Sadly, you have not a CLUE as to just how good COBOL can be - and it's not likely that many of you ever will.
There are PLENTY of sites on the web for those who are interested in lowering their CIQ (COBOL Ignorance Quotient). Meanwhile, let's not continue to confuse bad code that is written in COBOL with COBOL itself.
WHEW! Is this a religious war or something? OK - VETERAN COBOL PROGRAMMER (1974 - 2008) HERE SPEAKING! PLEASE LISSEN UP! (ignorance is a costly commodity that few people or businesses can afford). If you read through these posts "statistically" you will find a preponderance of gripes and "apples-to-oranges" comparisons. Poorly-written, poorly maintained, old, old, OLD code is - you guessed it, REALLY unpleasant for everyone (we seem to have that point of view well-covered). How many 40-year-old JAVA apps has anyone worked on lately, hmmm? OK - NEWS FLASH! GET THIS! please! (don't be ignorant). Believe it or not, there is a HUGE difference between "COBOL", and poorly-written, poorly maintained, old, old, OLD code that happens to be written in COBOL. Did you get that? What is getting bashed is poorly-written, poorly maintained, old, old, OLD code - and people are mistakenly thinking they are bashing COBOL - a bit ignorant, you might say? OK - moving on to the bright side. As a few have tried to point out here, besides the all-too common, all-too prevalent preponderance of poorly-written, poorly maintained, old, old, OLD code - there ARE companies running their businesses RATHER HAPPILY on some WELL-WRITTEN, WELL-MAINTAINED, new, clean, modularized code that just HAPPENS to be written in (are you READY!) - ta-dah!: COBOL!!!! Yeah! Honest - it happens. OK - yeah - these are mainframes - they're the machines that suck up, and hold, and process, and route, and re-route, the billions of transactions that all you little JAVA applets and PERL folks toss around out there. OK - to be fair - I would NOT want to have to try to do some of the customer-facing stuff you guys do - not in COBOL -- in fact I couldn't. COBOL is not intended to do everything. So I am not belittling ANY other language. Just understand, NO language is any better than it's deployment and/or maintenance. But COBOL DOES let me design, develop, and maintain HUGE apps - almost anywhere in the world - EASILY! Hard to Learn? Why heck, I've bought my house, cars, you name it, using about a dozen or so words: OPEN, READ, WRITE, MOVE, ADD, SUBTRACT, COMPUTE, IF, AND, OR, ELSE, NOT, END, PERFORM, GO TO (we don't like to use that one a lot), CLOSE, STOP RUN. Now - that wasn't so bad, was it? NOW - to the REALLY bright side - you should just SEE what can be done on an Unisys Clearpath or Libra (running with a fiber optic disk sub-system) using COBOL85 (or higher) with intrinsic functions, scope terminators, etc, etc, using WFL (a highly-programmable "jcl"), DMSII and COMS - FULLY-AUTOMATED DATABASE ROLLBACK AND RECOVERY, ZERO transaction loss (out of billions)... Oh awright, I know, mainframes are not for everybody ...
My heartfelt sympathy goes to those who have suffered, and are currently suffering under code which is the result of years of neglect, abuse, mismanagement, political decisions (sadly, "IBM" (JCL, VSAM, ... etc.)
Sadly - you have not a CLUE as to just how good COBOL can be - and it's not likely that many of you ever will.
(oops-- just had a spike in my transaction volume - I'm almost at 30% capacity - gotta go - ta-ta) ... tum-de-dumm (love my Unisys)
PS - there are PLENTY of sites on the web for those who are interested in lowering their CIQ (COBOL Ignorance Quotient).
Meanwhile, let's not continue to confuse bad code that is written in COBOL with COBOL itself, and let's all educate ourselves about a language that has billions of lines of code -- most of them fairly potable, and maintained by only 90K pprogrammers.