Re: OT: The Geek defense



"Judson McClendon" <judmc@xxxxxxxxxxxxx> wrote in message
news:IPGxj.111608$K27.8711@xxxxxxxxxxxxxxxxxxxxxxxxx
"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"Bill Gunshannon" <billg999@xxxxxxxxxxx> wrote:
"Judson McClendon" <judmc@xxxxxxxxxxxxx> writes:
"Michael Mattias" <mmattias@xxxxxxxxxxxxxx> wrote:
"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

It has always puzzled me why so many (particularly COBOL) people
hesitate to make the leap to a different language, when
"programming ability" is an underlying skill, that really shouldn't
be language dependent...

You are assuming the presence of fundamental programming skills.

However, many of the modern development tools/environments allow
"developers" to create applications without ever learning those
fundamentals. A few clicks, a few drags, a few drops and presto! you
can call yourself a programmer.

With no such tools available, people of our generation HAD to learn
the fundamentals, so for us changing languages or development
environments is pretty straightforward... except when we find
ourselves in one of these newfangled IDEs where fundamentals don't
matter.

You're right. And when these new "programmers" face a situation that
requires actual programming skills, they're lost. I think a demarcation
between the two different skills would be useful. Perhaps something
like "application assembler" rather than "programmer" would be a
better description for such people. It always gets me when people
who can only write HTML (for example) claim to be "programmers."
It's like a typist claiming to be an "author."

I've mentioned this here before, but a cousin of mine who is the same
age as me, and has a MS in CS, and has taught CS at university level,
has a daughter who just finished her BS in CS. He made sure she did
learn good programming skills, but said he was dismayed that the
university CS department put so little emphasis on it.

If you are disappointed now, take a look at "Angel" the "new" way
to teach programming at the University level. Things do not bode
well for our industry in the not too distant future.

On the contrary, I think the future is bright. (Mind you, I'm an optimist
and I ALWAYS think the future is bright :-))

The "programming" you are bewailing is no longer relevant. As I may have
mentioned here before, it was a phenomenon of the latter half of the 20th
century.

Judson's cousin is simply dismayed by change. The University have it
right.

If you did a Masters in English, would you expect to learn Sanskrit?

Do you need more than a passing knowledge of Greek, German, and Latin to
study English Literature?

Pete, I think you're missing the point. I agree that what they're teaching
now is sufficient for most applications programming. But for the
foreseeable
future, we will still need skilled programmers to build the tools.

Nope. You are woefully out of touch. The tools we have now can be used to
build better tools. The days of telling computers what to do, line by line,
are definitely numbered. We don't need to and it is far too expensive to do
so. Who codes in assembler any more? No need to. Why don't we? It's the same
argument.

The kids today ARE skilled programmers. It's just that their skill sets are
not the same as yours. (Neither do they need to be...)

Furthermore, your "foreseeable future" is very different from mine...


You aren't
going to build .NET, for example, using .NET or other drag and drop tools.

Don't need to; it has been built. It can be easily extended without having
to resort to low level tools. The magic phrase is "encapsulation of
classes".

I delivered a desktop application recently that did a fair bit of stuff. It
was written in C# and used Legacy COBOL components also. I expected it would
be a very large installable. It wasn't. Around 5 MBs and 4 MB of that was
COBOL run time... Then I realised... it was using all kinds of classes in
the FCL which don't have to be delivered... years and years of effort by
programmers unknown, to provide encapsulated functionality that simply
works. Why re-invent the wheel?

If we aren't teaching those skills in our Computer Science curriculums,
where are future programmers going to learn them?

They won't need them, any more than my English Lit. Major needs Sanskrit.

Your argument is postulated on current understanding of how computers work.
(The Von Neumann model).

That model is already being challenged in a number of laboratories, on a
number of fronts. Given that it gets replaced (and I believe that will
happen within 15 years) there will be no point in people learning
"programming" as you and I understand the term.

What has most opened my eyes to this has been my relatively recent dipping
into Query (LINQ) and Lambda expressions and functional programming. For
decades we have believed that data can only be manipulated in the ways we do
it; SQL is King. Now it turns out it isn't, there are much more powerful
ways to manipulate data, and storage technologies and devices will only be
limited by the software we use to drive them. Running SQL on a
multiprocessor, content addressable, nanobased storage device is like
printing invoices in Roman numbers.

We need approaches that are completely hardware independent so that multiple
concurrent processes can be initiated and assigned automatically by the
system where possible, and our interface to it facilitates that. (LINQ query
expressions are a perfect example of this...)

Our current approaches derived from sequential hardware, which was all we
had; we are due for an upgrade.

It is going to be hard for many here to accept that what they spent decades
on learning and applying is being overtaken by events.

Whether they accept it or not, that is the reality.

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



.

Relevant Pages

  • Re: Wang COBOL alive and well as Wang VS makes a comeback
    ... I fought to the last to keep COBOL at least peripherally in the ... will be the next language du jour... ... This contributes to the stability of programming efforts ... level of COBOL to another can be as big a deal as migrating across platforms ...
    (comp.lang.cobol)
  • Re: 7E7 Flight Controls Electronics
    ... was just good thing that that localization was not too easy - it would ... Please don't confuse abstraction skills of typical COBOL programmer (that ... I pointed at the current programming "biblioware" for commercial data ... > language was because I learned all the workarounds. ...
    (comp.lang.ada)
  • Re: Structured Coding
    ... more visual, some are more conceptual, some are more language oriented. ... I had major problems struggling with OO COBOL when it was first released. ... programming language ever written; light hearted, witty, amusing, ... Later I had to run some courses in Java Web programming and ...
    (comp.lang.cobol)
  • Re: New Cobol compiler written in Cobol
    ... It didn't have a visible operating system. ... > If I were writing a Cobol compiler, I wouldn't look at today's market. ... > What will a programming language need to be successful in that world? ... They'll use a language they can understand at a glance. ...
    (comp.lang.cobol)
  • Re: Gartner on Assessing the Age of Software Languages and Tools
    ... It's doing some Romero-level twitching, ... We have a lot of customers with no mainframe COBOL at all, ... COBOL.NET does everything that any other .NET language does. ... And of course the whole *point* of the CLI/CLR is that it simplifies mixed-language programming, so it's trivial to use one .NET language for the bulk of an application, and drop into another if it is better suited for some particular aspect. ...
    (comp.lang.cobol)