begin oe_protect.scr
Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> espoused:
> __/ [ Hadron Quark ] on Monday 14 August 2006 15:54 \__
>
>> Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> writes:
>>
>>> __/ [ John A. Bailo ] on Monday 14 August 2006 15:32 \__
>>>
>>>> [H]omer wrote:
>>>>
>>>>
>>>>> My first few weeks at Uni, we didn't even go anywhere *near* the
>>>>> computer lab. We were taught to understand the *principles* of
>>>>> "problem solving" - i.e. breaking down tasks into abstractions, using
>>>>> syntax diagrams and plain English.
>>>>
>>>> My first "computer" course was in numerical analysis and data processing.
>>>>
>>>> The professor never taught a line of code.
>>>>
>>>> He examined algorithms and taught us the limits of math in a digital
>>>> environment. He used pseudocode to illustrate the principles, of say,
>>>> sorting.
>>>>
>>>> We had to do programming tasks every week, but it was up to us to choose
>>>> the language, and the hardware for implementation.
>>>>
>>>>> <snip rest />
>>>
>>> Your professor was a smart pedagogue. Programming is syntax-depedent.
>>> Concepts and skills cling to one's mind for understanding of a paradigm,
>>> as well as improving problem-solving skills. See the foundation of one of
>>> the fathers of Computer Science.
>>
>> Actually, the choice of the language can and does totally change the
>> structure of the program. Moving between languages also includes a
>> paradigm shift.
>>
>>>
>>> http://www-cs-faculty.stanford.edu/~uno/books.html
>>>
>>> From practical exercise to 'art'. One-to-one sessions that we had as
>>> undergraduates involve nothing but classic lateral thinking riddles. It
>>> was strange. But, in the long term, these seem more valuable than
>>> memorisation of keywords and API's.
>>
>> I woudl agree that any good programmer can generally move between
>> languages : albeit resulting in inefficient and non "standard" code
>> which often falls down due to his inability to spot potential weaknesses
>> in his chosen data representations for that language. I good LISP
>> programmer is not going to walk into assembler or C for example.
>
>
> True to a degree. Returning to this case of lateral thinking and solving of
> puzzles, this is probably intended to, among other things, to improve the
> ability to spot awkward bugs and reason about code. These skills are
> generic. Language-specific skills can be harnessed quickly by reading some
> books, as well as through experience. But the former skills remain tricky to
> gain.
>
>
If you understand how the machine actually works, then understanding
programming is not so difficult. Certain types of algorithm can be a
little confusing to a beginner, and more complex state-machines can be
tricky to understand (most people don't know how to draw them, as it
tends to be taught in engineering rather than comp sci or physics
anyway). I suspect that Mr Quark would prefer that it appears complex
and difficult so that he can maintain a position that he's some kind of
high-priest. It's not, of course, although misunderstandings of how
things work are rife.
--
| Mark Kent -- mark at ellandroad dot demon dot co dot uk |
The way to a man's heart is through the left ventricle.
|
|
