Re: Is there a mainframe skills shortage?


"Alistair" <alistair@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1175337742.503099.254140@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 31 Mar, 03:22, "Pete Dashwood" <dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
could try these links:

http://blogs.msdn.com/charlie/archive/2007/01/26/anders-hejlsberg-on-
http://wm.microsoft.com/ms/msdn/visualcsharp/LinqFarm01/LinqToSql01.wmv
http://themechanicalbride.blogspot.com/2007/03/dreaming-of-plinq.html

Three spelling mistakes in the word parallelize. Not an auspicious
start
and it makes it harder to take the rest seriously.

Does it? I guess I'm getting used to reading papers by people whose first
language isn't English.

While I love the English language, I keep its purpose in mind; it conveys
messages, thoughts and ideas.

To allow the wrapper to influence one's perspective on the content, can mean
missing some very valuable content.

Nevertheless, it is something we all do, as marketing men know well to our
cost...:-)

http://www.intelligententerprise.com/010327/celko_online.jhtml;jsessi...

Nice try. I've never heard of Kdb (functional database?) but I have
heard of
Cache (OO database works well with Java). I do wonder what the point
is in
putting up proud boasts of the Kdb performance when there are no
comparative
figures for SQL Server, etc.


They are not proud boasts and that wasn't the point. It isn't a contest; he
is simply saying that these techniques can handle high volume traffic. Note
it was a Pentium 2... If he wanted to boast he would have posted multi core
blade server figures.

The non-standard syntax should put people
off,
though.

It isn't "non-standard" syntax, it is a new syntax for query expressions.
They are deliberately formulated differently from current SQL (although they
look similar) for reasons that become apparent in some of the other links
and material around Lamdas and functional programming. Formulating the
expressions in the way shown, allows decision trees to be implenented
without actually doing any I/O at all (it is a form of deferred execution),
and allows the data requirement to be manipulated by other processes (and
possibly on different processor cores), before it is actually executed.
These are quite different concepts than the ones we are used to with
embedded SQL.

Although these ideas have been around for quite some time, it is only now
that they have reached the mainstream and that was partly because C# is an
ideal vehicle for them, and implements them easily. Other OO type languages
will also do so.



Where will these technologies be in 10 years? Where will Ruby
on
Rails be? Nowhere.

I don't know anything much about Ruby, so I would refrain from predicting
its future or lack thereof. I do know something about COBOL and my
predictions on that are a matter of record.

There is a problem: so many technologies, so little
time
to pick the winner.

Only if you see it as a contest. It isn't. It is simply new technology that
will be implemented by a number of languages.

Why does everything have to be a hammer? Why aren't we all driving one make
of car, buying one brand of toothpaste, wearing one type of watch... and so
on...? There are different interpretations of an agreed underlying
technology.

It is exactly the same with software. When there is a sea change in the
technology (and I am suggesting that Functional Programming and Lamda
expressions will do that for data binding and access), there will be
different implementations of it in different languages.

This whole discussion started when it was suggested that CS grads should
stick to writing system software and leave applications to the COBOL people.

I don't see that as being right or useful. And it cetainly isn't fair to the
CS grads coming out of Acadaemia currently. They are much better informed
than most of us ever were and they are flexible enough to implement business
reqirements using the techniques and approaches they have been taught. Just
because they don't write COBOL doesn't mean they are useless.

The techniques in the links I posted are not just new fangled fashions that
simply re-invent what "everybody knows". This is the way of the future and
one of the reasons that COBOL will not be part of it is because it cannot
implement these approaches easily and simply.

(That is no fault of COBOL... it uses a different, and now superseded,
paradigm.)

Pete.



.