Declining Cobol job market

In the 10 years I've been a Cobol/Unix contract programmer (13 gigs), demand for Cobol in
the US has slowly been declining. Demand is now so low that it's unreasonable to continue
pursuing Cobol jobs. With sadness, I'm switching my specialty to PL/SQL and affiliated
server side Unix tools. While working as a Cobol programmer, I spent more time solving SQL
problems than Cobol problems. Now I find there are a large number of shops doing 100% of
server side programming in PL/SQ. Apparently, there are more PL/SQL shops than Cobol
shops. How lame, but that's reality.

"Robert" <no@e.mail> wrote in message
news:clu6b4lndhsm8i8bdald9fsgjh238a8v9m@4ax.com...
> In the 10 years I've been a Cobol/Unix contract programmer (13 gigs),
> demand for Cobol in
> the US has slowly been declining. Demand is now so low that it's
> unreasonable to continue
> pursuing Cobol jobs. With sadness, I'm switching my specialty to PL/SQL
> and affiliated
> server side Unix tools. While working as a Cobol programmer, I spent more
> time solving SQL
> problems than Cobol problems. Now I find there are a large number of shops
> doing 100% of
> server side programming in PL/SQ. Apparently, there are more PL/SQL shops
> than Cobol
> shops. How lame, but that's reality.

I share your regret, Robert, but I don't think it is lame. I first
encountered a shop that had moved to 100% SQL around 6 years ago, in the
U.K. Working in that environment I could see why they did so, and it made
sense. It was far from lame. They had better tools and better facilities
using SQL than they did using COBOL. They were moving to implement a
corporate package (Siebel) which took 24 months, and meantime it was
necessary (and my responsibility) to keep the legacy systems (and the
Business) running. It simply would not have been possible had we continued
to maintain COBOL.

The world has moved on; COBOL people, for the most part, haven't.

I wish you every success with your endeavours to sell your PL/SQL skills
which are both marketable, and which I have seen from posts here, you are
more than competent with.

COBOL still has some life in it, but there is little money to be made and,
as you pointed out, it is a declining market (not just in the USA...)

I hope COBOL people who are comfortably employed remain so until they are
ready to retire. I think many can. Young people should add COBOL knowlwedge
ot their tool kits, but are unlikely to make a living from it as we did.

Perhaps some of those currently working might like to document what they
know (techniques in coding, standards, favourite shortcuts, etc.) for a
rising generation who will be unfamiliar with COBOL but may need to maintain
Legacy code for some time yet.

Pete.
--
"I used to write COBOL...now I can do anything."

On Aug 25, 11:04*pm, Robert <n...@e.mail> wrote:
> In the 10 years I've been a Cobol/Unix contract programmer (13 gigs), demand for Cobol in
> the US has slowly been declining. Demand is now so low that it's unreasonable to continue
> pursuing Cobol jobs. With sadness, I'm switching my specialty to PL/SQL and affiliated
> server side Unix tools. While working as a Cobol programmer, I spent moretime solving SQL
> problems than Cobol problems. Now I find there are a large number of shops doing 100% of
> server side programming in PL/SQ. Apparently, there are more PL/SQL shopsthan Cobol
> shops. How lame, but that's reality.


Well, while is unarguable that COBOL jobs have declined in quantity
over the past decade, I
have noticed that people who can "get the job done" are in ever
greater demand these days.
Doesn't matter if the do it in COBOL or Sanskrit, if it gets done on
time, works, and is
fast enough, it's a success.

A lot of COBOL programmers (and RPG programmers, and Assembler
programmers, and PL/1,
and Pascal, and Fortran, and <pick a "legacy" language of your choice>
programmers
actually fall right into that job description.

Most "web programmers" don't. Amazing - COBOL programmers can learn to
wrangle the web, but
web jockies seem to be unable to handle COBOL.

Now I wonder what that means...

-Paul

"PR" <paul.raulerson@gmail.com> wrote in message
news:e41e894f-f8aa-4e3f-9b6b-932190cacd0d@8g2000hse.googlegroups.com...
On Aug 25, 11:04 pm, Robert <n...@e.mail> wrote:
> In the 10 years I've been a Cobol/Unix contract programmer (13 gigs),
> demand for Cobol in
> the US has slowly been declining. Demand is now so low that it's
> unreasonable to continue
> pursuing Cobol jobs. With sadness, I'm switching my specialty to PL/SQL
> and affiliated
> server side Unix tools. While working as a Cobol programmer, I spent more
> time solving SQL
> problems than Cobol problems. Now I find there are a large number of shops
> doing 100% of
> server side programming in PL/SQ. Apparently, there are more PL/SQL shops
> than Cobol
> shops. How lame, but that's reality.


Well, while is unarguable that COBOL jobs have declined in quantity
over the past decade, I
have noticed that people who can "get the job done" are in ever
greater demand these days.
Doesn't matter if the do it in COBOL or Sanskrit, if it gets done on
time, works, and is
fast enough, it's a success.

A lot of COBOL programmers (and RPG programmers, and Assembler
programmers, and PL/1,
and Pascal, and Fortran, and <pick a "legacy" language of your choice>
programmers
actually fall right into that job description.

Most "web programmers" don't. Amazing - COBOL programmers can learn to
wrangle the web, but
web jockies seem to be unable to handle COBOL.

[Pete]

Motivation has much to do with it. Why would an accomplished Web programmer
want to learn COBOL? You might as well ask a journalist to learn Sanskrit.

Your statement that COBOL people "CAN learn to wrangle the Web" is true, but
they have great difficulty in doing so. (I have had to teach some of them
and, just like learning OO concepts and usage in general, they struggle with
it.) There is a tendency amongst people who have used COBOL for decades to
believe it is the "right" way and any other way which is not congruent with
it must be wrong. New, unfamiliar concepts and the associated jargon are
considered "difficult and complex" and viewed with suspicion. Attempts to
hang new ideas on old pegs result in "ITSA" when it should be "ITSLIKE" and
fundamental misunderstandings ensue.

It comes down to mastering OO concepts. COBOL people are, generally, not
good at it and people with no previous programming experience walk all over
them, in my experience. I know which ones I'd rather teach.

While your opinions expressed above will be comforting to many who are
currently feeling a bit "unloved", the actuality is that there are good and
bad COBOL programmers, just like there are good and bad Web programmers, and
generalizing about either group is simply suspect.

I have seen nothing that makes me think Legacy programmers are better at
picking up new concepts or are generally more proficient at "getting the job
done", than anybody else. In fact, the evidence in my experience tends to
the contrary, at least when it comes to learning new skills.

I would agree that most Legacy programmers are more disciplined in their
approach, but that is often more to do with age and maturity than any
particular programming skill.

A person of normal ability, who is motivated and wants to learn something,
can apply themselves to it and the degee of their success is predictable,
depending on the levels of motivation, application, and ability.

It has little to do with whether they are a Legacy programmer or not.

[/Pete]

Now I wonder what that means...
[Pete]

It means your opinion is a generalization, is arguable, and is biased to the
result you would like to believe. :-)

Pete.
--
"I used to write COBOL...now I can do anything."

On Wed, 27 Aug 2008 13:56:51 -0700 (PDT), PR <paul.raulerson@gmail.com> wrote:

>On Aug 25, 11:04*pm, Robert <n...@e.mail> wrote:
>> In the 10 years I've been a Cobol/Unix contract programmer (13 gigs), demand for Cobol in
>> the US has slowly been declining. Demand is now so low that it's unreasonable to continue
>> pursuing Cobol jobs. With sadness, I'm switching my specialty to PL/SQL and affiliated
>> server side Unix tools. While working as a Cobol programmer, I spent more time solving SQL
>> problems than Cobol problems. Now I find there are a large number of shops doing 100% of
>> server side programming in PL/SQ. Apparently, there are more PL/SQL shops than Cobol
>> shops. How lame, but that's reality.
>
>
>Well, while is unarguable that COBOL jobs have declined in quantity
>over the past decade, I
>have noticed that people who can "get the job done" are in ever
>greater demand these days.

I've never seen a job ad asking for "get the job done." They say 4 years of X, 5 years of
heavy Y and Z would be helpful but is not required.

Last week a recruiter said a place might take six weeks to make a decision. I responded,
"they've created a filter that insures the person they hire will be one who cannot find a
job in six weeks."

Ads written by non-technical managers ask for every technology the shop ever used, a
collection of skills that no human possesses. The person they hire will be the most
proficient liar.

"Of all things, good sense is the most fairly distributed: everyone thinks he is so well
supplied with it that even those who are the hardest to satisfy in every other respect
never desire more of it than they already have." -- Descartes

On Wed, 27 Aug 2008 18:15:13 -0500, Pete Dashwood wrote
(in article <6hm5g2FmvtrfU1@mid.individual.net>):

>
>
> "PR" <paul.raulerson@gmail.com> wrote in message
> news:e41e894f-f8aa-4e3f-9b6b-932190cacd0d@8g2000hse.googlegroups.com...
> On Aug 25, 11:04 pm, Robert <n...@e.mail> wrote:
>> In the 10 years I've been a Cobol/Unix contract programmer (13 gigs),
>> demand for Cobol in
>> the US has slowly been declining. Demand is now so low that it's
>> unreasonable to continue
>> pursuing Cobol jobs. With sadness, I'm switching my specialty to PL/SQL
>> and affiliated
>> server side Unix tools. While working as a Cobol programmer, I spent more
>> time solving SQL
>> problems than Cobol problems. Now I find there are a large number of shops
>> doing 100% of
>> server side programming in PL/SQ. Apparently, there are more PL/SQL shops
>> than Cobol
>> shops. How lame, but that's reality.
>
>
> Well, while is unarguable that COBOL jobs have declined in quantity
> over the past decade, I
> have noticed that people who can "get the job done" are in ever
> greater demand these days.
> Doesn't matter if the do it in COBOL or Sanskrit, if it gets done on
> time, works, and is
> fast enough, it's a success.
>
> A lot of COBOL programmers (and RPG programmers, and Assembler
> programmers, and PL/1,
> and Pascal, and Fortran, and <pick a "legacy" language of your choice>
> programmers
> actually fall right into that job description.
>
> Most "web programmers" don't. Amazing - COBOL programmers can learn to
> wrangle the web, but
> web jockies seem to be unable to handle COBOL.
>
> [Pete]
>
> Motivation has much to do with it. Why would an accomplished Web programmer
> want to learn COBOL? You might as well ask a journalist to learn Sanskrit.
>
> Your statement that COBOL people "CAN learn to wrangle the Web" is true, but
> they have great difficulty in doing so. (I have had to teach some of them
> and, just like learning OO concepts and usage in general, they struggle with
> it.) There is a tendency amongst people who have used COBOL for decades to
> believe it is the "right" way and any other way which is not congruent with
> it must be wrong. New, unfamiliar concepts and the associated jargon are
> considered "difficult and complex" and viewed with suspicion. Attempts to
> hang new ideas on old pegs result in "ITSA" when it should be "ITSLIKE" and
> fundamental misunderstandings ensue.
>
> It comes down to mastering OO concepts. COBOL people are, generally, not
> good at it and people with no previous programming experience walk all over
> them, in my experience. I know which ones I'd rather teach.
>
> While your opinions expressed above will be comforting to many who are
> currently feeling a bit "unloved", the actuality is that there are good and
> bad COBOL programmers, just like there are good and bad Web programmers, and
> generalizing about either group is simply suspect.
>
> I have seen nothing that makes me think Legacy programmers are better at
> picking up new concepts or are generally more proficient at "getting the job
> done", than anybody else. In fact, the evidence in my experience tends to
> the contrary, at least when it comes to learning new skills.
>
> I would agree that most Legacy programmers are more disciplined in their
> approach, but that is often more to do with age and maturity than any
> particular programming skill.
>
> A person of normal ability, who is motivated and wants to learn something,
> can apply themselves to it and the degee of their success is predictable,
> depending on the levels of motivation, application, and ability.
>
> It has little to do with whether they are a Legacy programmer or not.
>
> [/Pete]
>
> Now I wonder what that means...
> [Pete]
>
> It means your opinion is a generalization, is arguable, and is biased to the
> result you would like to believe. :-)
>
> Pete.
>

I am not so sure of that at all Pete - I keep encountering expensive web
"programmers" who are helpless without DreamWeaver. They know all the
right buttons to push, but have no idea what the buttons actually do.

They get frustrated and whiney when you have to task them with say,
interfacing to a "legacy" system, and then come up with the dopiest ideas you
can imagine. I don't care what anyone says, replacing a 40+ year old
homegrown system on the mainframe is not going to happen by having a good
mastery of Dreamweaver. Not if even if they know how to interface to MS SQL
Server.

COBOL people, on the other hand, tend to come in, figure out *why* something
works, then *how* it works, and come up with elegant and cost effective ways
to make things happen. Even fancy things like very complex web based
interfaces.

Let me rephrase that just slightly - average joe COBOL programmers tend to do
absolutely brilliant jobs in that environment, at least they do if they are
nurtured a bit.

"Brilliant" web designers tend to be more artist than engineer or scientist.
They don't do so well in situations were ideas have to be turned into
engineering reality.

OO concepts are not really anything new if you present them right. In fact,
in plain simple truth, the best OO ideas are nothing more than the distilled
wisdom of practical software programmers, engineers, and managers. There
never has been anything revolutionary about it.

The times I have seen COBOL programmers get into trouble with understanding
OO have been when the "teacher" is a zealot for whatever methodolofy of the
day they are pushing. Smalltalk, for instance. Or Java, or Oberon, or
Microsoft .NET. (Boy, those .NET guys will tell you Microsoft invented the
whole idea!! Swear on a stack of bibles no less...

Anyway, you are right that there is resistance to change, but it is often -
though not always - a sensible and well reasoned resistance. "Oh, we can
replace that mainframe over there, with 3000 individual PC's all running
Visual Basic applications that talk clientserver to a MS SQL database."

I swear, I head that exact sentence from an arrogant idiot one time. When I
asked how he planned to deploy something like that - he actually simpered and
snickered and said -"well- that s *your* job isn't it?"

On Wed, 27 Aug 2008 20:58:10 -0500, Robert wrote
(in article <nvtbb4df0274jo54pbau02ri2r7a6dof5q@4ax.com>):

> On Wed, 27 Aug 2008 13:56:51 -0700 (PDT), PR <paul.raulerson@gmail.com>
wrote:
>
>> On Aug 25, 11:04*pm, Robert <n...@e.mail> wrote:
>>> In the 10 years I've been a Cobol/Unix contract programmer (13 gigs),
>>> demand for Cobol in
>>> the US has slowly been declining. Demand is now so low that it's
>>> unreasonable to continue
>>> pursuing Cobol jobs. With sadness, I'm switching my specialty to PL/SQL
>>> and affiliated
>>> server side Unix tools. While working as a Cobol programmer, I spent more
>>> time solving SQL
>>> problems than Cobol problems. Now I find there are a large number of shops
>>> doing 100% of
>>> server side programming in PL/SQ. Apparently, there are more PL/SQL shops
>>> than Cobol
>>> shops. How lame, but that's reality.
>>
>>
>> Well, while is unarguable that COBOL jobs have declined in quantity
>> over the past decade, I
>> have noticed that people who can "get the job done" are in ever
>> greater demand these days.
>
> I've never seen a job ad asking for "get the job done." They say 4 years of
> X, 5 years of
> heavy Y and Z would be helpful but is not required.
>
> Last week a recruiter said a place might take six weeks to make a decision. I

> responded,
> "they've created a filter that insures the person they hire will be one who
> cannot find a
> job in six weeks."
>
> Ads written by non-technical managers ask for every technology the shop ever
> used, a
> collection of skills that no human possesses. The person they hire will be
> the most
> proficient liar.
>
> "Of all things, good sense is the most fairly distributed: everyone thinks he

> is so well
> supplied with it that even those who are the hardest to satisfy in every
> other respect
> never desire more of it than they already have." -- Descartes
>
>

Heck - that is always requirement #1 when I interview potential candidates.

I have also found in my personal experience, that is what people I have
interviewed *with* are looking for.

I guess we have all been burned too many times by hiring an incompetent jerk
with great credentials.


-Paul

In article <nvtbb4df0274jo54pbau02ri2r7a6dof5q@4ax.com>,
Robert <no@e.mail> wrote:

[snip]

>Last week a recruiter said a place might take six weeks to make a
>decision. I responded,
>"they've created a filter that insures the person they hire will be one
>who cannot find a
>job in six weeks."

I've had those... 'they love you, they want you, they need you but... they
won't be ready for you for (n) weeks.'

'That's all right... as long as their checks clear the bank for the next
(n) weeks I'll be happy to accomodate their schedule.'

'Checks? They're not going to pay you, they just want you to wait.'

'They want me to dedicate my time to fulfilling their business requirement
of starting in (n) weeks... and not get paid for it? I can't do that...
but I'm willing to compromise, I'll take three-quarters of my rate for
theo waiting period.'

'No... they just want you to wait, do nothing... and not get paid.'

'Oh... well, they're offering an n-month contract, let's add in the lost
earnings into the projected total and raise the rate to make up for it.'

'You can't do that... I agreed to a rate!'

'You may have agreed to a rate... I can't agree to waiting six weeks
without pay. You want something with that kind of flexibility call a
car-rental office; Avis is listed on the stock-exchange... I'm not.'

DD

On Wed, 27 Aug 2008 22:37:31 -0500, PaulR <paul.raulerson@gmail.com>
wrote:

>I am not so sure of that at all Pete - I keep encountering expensive web
>"programmers" who are helpless without DreamWeaver. They know all the
>right buttons to push, but have no idea what the buttons actually do.
>
>They get frustrated and whiney when you have to task them with say,
>interfacing to a "legacy" system, and then come up with the dopiest ideas you
>can imagine. I don't care what anyone says, replacing a 40+ year old
>homegrown system on the mainframe is not going to happen by having a good
>mastery of Dreamweaver. Not if even if they know how to interface to MS SQL
>Server.
>
>COBOL people, on the other hand, tend to come in, figure out *why* something
>works, then *how* it works, and come up with elegant and cost effective ways
>to make things happen. Even fancy things like very complex web based
>interfaces.

While my experience doesn't match yours - I will note that the average
CoBOL programmers have lots more experience programming than the
average Web programmer.

I will also note that for our customers - great code in a web page is
often of less value than some of the other skills a web designer might
have. Measuring whose site is better by evaluating the code might not
be measuring the right thing.

"PaulR" <paul.raulerson@gmail.com> wrote in message
news:0001HW.C4DB87AB00094E66B01AD9AF@news.suddenli nk.net...
> On Wed, 27 Aug 2008 18:15:13 -0500, Pete Dashwood wrote
> (in article <6hm5g2FmvtrfU1@mid.individual.net>):
>
>>
>>
>> "PR" <paul.raulerson@gmail.com> wrote in message
>> news:e41e894f-f8aa-4e3f-9b6b-932190cacd0d@8g2000hse.googlegroups.com...
>> On Aug 25, 11:04 pm, Robert <n...@e.mail> wrote:
>>> In the 10 years I've been a Cobol/Unix contract programmer (13 gigs),
>>> demand for Cobol in
>>> the US has slowly been declining. Demand is now so low that it's
>>> unreasonable to continue
>>> pursuing Cobol jobs. With sadness, I'm switching my specialty to PL/SQL
>>> and affiliated
>>> server side Unix tools. While working as a Cobol programmer, I spent
>>> more
>>> time solving SQL
>>> problems than Cobol problems. Now I find there are a large number of
>>> shops
>>> doing 100% of
>>> server side programming in PL/SQ. Apparently, there are more PL/SQL
>>> shops
>>> than Cobol
>>> shops. How lame, but that's reality.
>>
>>
>> Well, while is unarguable that COBOL jobs have declined in quantity
>> over the past decade, I
>> have noticed that people who can "get the job done" are in ever
>> greater demand these days.
>> Doesn't matter if the do it in COBOL or Sanskrit, if it gets done on
>> time, works, and is
>> fast enough, it's a success.
>>
>> A lot of COBOL programmers (and RPG programmers, and Assembler
>> programmers, and PL/1,
>> and Pascal, and Fortran, and <pick a "legacy" language of your choice>
>> programmers
>> actually fall right into that job description.
>>
>> Most "web programmers" don't. Amazing - COBOL programmers can learn to
>> wrangle the web, but
>> web jockies seem to be unable to handle COBOL.
>>
>> [Pete]
>>
>> Motivation has much to do with it. Why would an accomplished Web
>> programmer
>> want to learn COBOL? You might as well ask a journalist to learn
>> Sanskrit.
>>
>> Your statement that COBOL people "CAN learn to wrangle the Web" is true,
>> but
>> they have great difficulty in doing so. (I have had to teach some of them
>> and, just like learning OO concepts and usage in general, they struggle
>> with
>> it.) There is a tendency amongst people who have used COBOL for decades
>> to
>> believe it is the "right" way and any other way which is not congruent
>> with
>> it must be wrong. New, unfamiliar concepts and the associated jargon are
>> considered "difficult and complex" and viewed with suspicion. Attempts to
>> hang new ideas on old pegs result in "ITSA" when it should be "ITSLIKE"
>> and
>> fundamental misunderstandings ensue.
>>
>> It comes down to mastering OO concepts. COBOL people are, generally, not
>> good at it and people with no previous programming experience walk all
>> over
>> them, in my experience. I know which ones I'd rather teach.
>>
>> While your opinions expressed above will be comforting to many who are
>> currently feeling a bit "unloved", the actuality is that there are good
>> and
>> bad COBOL programmers, just like there are good and bad Web programmers,
>> and
>> generalizing about either group is simply suspect.
>>
>> I have seen nothing that makes me think Legacy programmers are better at
>> picking up new concepts or are generally more proficient at "getting the
>> job
>> done", than anybody else. In fact, the evidence in my experience tends to
>> the contrary, at least when it comes to learning new skills.
>>
>> I would agree that most Legacy programmers are more disciplined in their
>> approach, but that is often more to do with age and maturity than any
>> particular programming skill.
>>
>> A person of normal ability, who is motivated and wants to learn
>> something,
>> can apply themselves to it and the degee of their success is predictable,
>> depending on the levels of motivation, application, and ability.
>>
>> It has little to do with whether they are a Legacy programmer or not.
>>
>> [/Pete]
>>
>> Now I wonder what that means...
>> [Pete]
>>
>> It means your opinion is a generalization, is arguable, and is biased to
>> the
>> result you would like to believe. :-)
>>
>> Pete.
>>
>
> I am not so sure of that at all Pete - I keep encountering expensive web
> "programmers" who are helpless without DreamWeaver. They know all the
> right buttons to push, but have no idea what the buttons actually do.

I used to use Dreamweaver and still do occasionally, although these days I
use mainly VS 2008 for Web development with ASP.NET and C# code behind on
the server. Thisis not necessarily the "best" way to develop web sites, but
it serves me well. (I keep an eye opn other emerging technology as well...)

DW is an excellent tool. You say they get whiney when they can't use
Dreamweaver; I say you wouldn't expect a carpenter to build you a house
without power tools. (Doesn't mean he CAN'T... it's just better for all
concerned if the tools are good.)

I think here are very few people who use DW professionally and don't
understand the underlying/generated HTML and XML... not that it really
matters anymore. I wrote my first web site in Notepad in 1995 using HTML and
very bare bones CSS. I wouldn't do that today and I wouldn't expect anyone
else to either.

As for web programmers being expensive, have you tried hiring COBOL people
recently?
>
> They get frustrated and whiney when you have to task them with say,
> interfacing to a "legacy" system, and then come up with the dopiest ideas
> you
> can imagine. I don't care what anyone says, replacing a 40+ year old
> homegrown system on the mainframe is not going to happen by having a good
> mastery of Dreamweaver.

Well, if you "don't care what anyone says" about it, there is little point
me debating it with you, is there..? :-)

I have seen (and been instrumental in) replacing a number of decades old
mainframe COBOL systems with web based applications and the exercises were
very successful. Dreamweaver may or may not be instrumental in this; the
fact is that web based systems provide distributed access 24/7 and do it in
a way which is familiar to the majority of the population, who have never
had to cope with 4 character data entry on a green screen in order to
instigate a transaction.


>Not if even if they know how to interface to MS SQL
> Server.
>
> COBOL people, on the other hand, tend to come in, figure out *why*
> something
> works, then *how* it works, and come up with elegant and cost effective
> ways
> to make things happen. Even fancy things like very complex web based
> interfaces.

Oh man, I really wish... :-)
>
> Let me rephrase that just slightly - average joe COBOL programmers tend to
> do
> absolutely brilliant jobs in that environment, at least they do if they
> are
> nurtured a bit.

ANY technical person will do a better job in any environment if they are
"nurtured" a bit... :-)
>
> "Brilliant" web designers tend to be more artist than engineer or
> scientist.
> They don't do so well in situations were ideas have to be turned into
> engineering reality.

I disagree. But it is a generalization anyway so very difficult to prove or
disprove.

>
> OO concepts are not really anything new if you present them right. In
> fact,
> in plain simple truth, the best OO ideas are nothing more than the
> distilled
> wisdom of practical software programmers, engineers, and managers. There
> never has been anything revolutionary about it.

Yes and no. I had great difficulty in picking up these concepts when I first
tried to do so via OO COBOL. I can relate to others having the same trouble.
However, when I put COBOL down and looked at a "new" language which was
based on OO concepts, as if I had never programmed a computer before, it all
clicked into place pretty quickly. I then went back to OO COBOL and had no
further problems with it.

There are a number of conceptual differences between the procedural and OO
paradigms. I already covered why this is difficult for many COBOL
programmers.

>
> The times I have seen COBOL programmers get into trouble with
> understanding
> OO have been when the "teacher" is a zealot for whatever methodolofy of
> the
> day they are pushing.

:-)

No comment... Feedback on my courses was very positive... :-)


>Smalltalk, for instance. Or Java, or Oberon, or
> Microsoft .NET. (Boy, those .NET guys will tell you Microsoft invented the
> whole idea!! Swear on a stack of bibles no less...

As I was programming computers before MicroSoft was incorporated, I tend to
keep an even keel on this one. Besides, I was brainwashed by IBM in my youth
so there isn't much chance of anyone else getting much of a look-in... My
personal preference is for the .NET environment but that is mainly because I
have found it to be productive. I long ago gave up getting emotional about
computer software, hardware, or environments. You might as well fall in love
with the toaster... :-)
>
> Anyway, you are right that there is resistance to change, but it is
> often -
> though not always - a sensible and well reasoned resistance. "Oh, we can
> replace that mainframe over there, with 3000 individual PC's all running
> Visual Basic applications that talk clientserver to a MS SQL database."
>
> I swear, I head that exact sentence from an arrogant idiot one time.

Does the phrase "wind up" (as in compressing clockwork) mean anything to
you, Paul... ? :-)


>When I
> asked how he planned to deploy something like that - he actually simpered
> and
> snickered and said -"well- that s *your* job isn't it?"
>

"Do not go gentle into that good night.
Rage, rage against the dying of the light."


Unfortunately, as Dylan Thomas found, you can scream and yell all you like
about the decline of the light, but entry into Darkness is inevitable.

So will it be with COBOL.

Best bet is to look for a decent flashlight... :-)

Pete.
--
"I used to write COBOL...now I can do anything."