"Clark F Morris" <cfmpublic@[EMAIL PROTECTED]
> wrote in message
news:33tes35a3vdvbfbh8uol31kcbnn6r9f9nf@[EMAIL PROTECTED]
> On Fri, 29 Feb 2008 13:48:52 +1300, "Pete Dashwood"
> <dashwood@[EMAIL PROTECTED]
> wrote:
>
>>
>>
>>"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
>>cl*****".
>>
>>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 cl*****
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.
>
> I think Linus Torvalds would give you a big argument on that. He will
> NOT accept C++ code into the Linux kernel. It has to be C.
Yes, I know. Within the paradigm he is discussing, I have no problem with
that.
As I tried to outline above, I believe the whole paradigm will ****ft
within
15 years. Linux will be remembered fondly (or not) in the same way that we
remember DOS. That is not to minimize the value of it right now, it is
simply to put it into a longer term perspective.
Fundamental breakthroughs in architecture can be expected to afford
completely new Operating Systems.
Pete.
--
"I used to write COBOL...now I can do anything."
>>
>>Pete.
|
