"Judson McClendon" <judmc@[EMAIL PROTECTED]
> wrote in message
news:IPGxj.111608$K27.8711@[EMAIL PROTECTED]
> "Pete Dashwood" <dashwood@[EMAIL PROTECTED]
> wrote:
>> "Bill Gunshannon" <billg999@[EMAIL PROTECTED]
> wrote:
>>> "Judson McClendon" <judmc@[EMAIL PROTECTED]
> writes:
>>>> "Michael Mattias" <mmattias@[EMAIL PROTECTED]
> wrote:
>>>>> "Pete Dashwood" <dashwood@[EMAIL PROTECTED]
> 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."
|
