Re: Is there a mainframe skills shortage?

On 31 Mar, 15:01, "Pete Dashwood" <dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
"Alistair" <alist...@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.


You've obviously never worked for managers who could not spell. There
is a difference between "You're fired" and "you're fried". To convey
accurately a message it is necessary to spell. I have encountered
poorly written/constructed texts before (the classic being the
advocate of word-processors who said that there was no need to plan a
document, just get on and write it. It made spaghetti code look
succinct and well laid out) and usually take it to be a sign of poor
thinking and weak arguments.


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.

But he did not post any comparative figures for other software/
hardware combinations so I am left none the wiser. I can, with
justification, point out that Adabas can handle a higher transaction
rate than DB2 but unless I post comparative figures DD and yourself
would joyfully rip my argument to pieces.



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

It isn't "non-standard" syntax, it is a new syntax for query expressions.

The author of the article said that it was a non-standard syntax (so
there! 8-P )

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

Welcome back to the 1970s.

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,

In pc circles, Ruby on Rails is one of the latest fave rave must haves
for any programming fashionista.

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.

No, it is a matter of earning money to pay for the mortgage. At least
with mainframe systems there were limited choices and it was pretty
obvious which languages were the ones to learn. Now there are so many
languages, databases, blah blah blah, and it is difficult to decide
which one to learn. I'm aiming for Java (someone is going to have to
maintain the code being written today when everyone else has decided
it isn't sexy and moved on to Ruby and Kdb, etc.).

But in one respect it is a competition - survival of the fittest
although the fittest don't always win.

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.

We are: INTEL chips, WINDOWS platform, JAVA runtimes, XHTML encoded
pages, IE7 browser, MS OFFICE ..... although some do persist in using
AMD (I have one!), Linux, C# (which probably doesn't work under
Linux)...


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 isn't about a sea-change in technology. It is about what the kids
at university were taught 10 years ago. You just have to look at how a
poor operating system (Unix) has taken over the world to see that.


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 have only ever met one CS graduate and he was the world's worst
programmer. He would have been dangerous writing compilers and system
software.


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.

No, they all come out perfectly formed for applications system
writing, right? I don't know what they teach in Uni today and I will
admit that I am prejudiced against CS graduates in the applications
arena based on a sample size of 1 (which may be statistically
significant, but I can't remember my degree foundation course on
statistics).

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.

I have no doubt that the future is not as the world is now, and that
programming will move on but I despair at languages that often seem to
be rephrasing of existing languages (C compared to Assembler) without
adding clarity and simplification of the code. I remember that when I
first encountered SQL I could not take it seriously, but in skilled
hands it is certainly better than coding direct calls for data access.
In unskilled hands it is still better than having to code a thousand
lines of data division.


.

Quantcast