On 12/14/2010 12:45 PM, les wrote:
On Fri, 2010-12-17 at 09:50 -0700, Patrick Kobly wrote:
> A first programming language should avoid concepts like:
> * Pointers (at least in the C conception of them, breaking the
> typing system)
> <SNIP>
I see a lot of complaints about pointers in all these messages, telling
this novice to avoid them. But the fact is that all languages rely on
pointers. Even the beloved scripting languages so many tout, cannot
exist without pointers.
Of course this is true.
<snip>
The beloved object oriented folks have pointers built in, that are
used
to access the procedures that affect the objects. The objects are in
fact structures, which are created in blocks and again pointers are used
to reference that information. When you use an array, that is an
indexed offset from a pointer.
As is this.
Someone said pointers break the typing. That is not true, if you do
not
break pointer typing to begin with. That is a pointer can be typed, and
moreover someone who uses an integer for a pointer is voiding type
control in his program.
And moreover, somebody who uses the standard libraries in C
needs to
void type control in his program in this manner. A learning programmer
with entry level skills does not have the knowledge to understand when
this is appropriate and when it is not (and is potentially dangerous).
No knowing pointers means not having any clue to how the underlying
structure works and leads to weak programming.
And trying to understand the
concepts of indirection at a point when one
does not have a grip on concepts such as boolean logic, flow control and
variable assignment / use causes a muddied understanding of pointers,
what they are and how they work. This muddied thinking at this critical
conceptual jump is extremely difficult to remedy with students.
I strongly encourage every beginning programmer to learn pointers,
pointer usage and pointer math to understand some of the mechanisms that
make programs break.
I strongly encourage beginning programmers to learn boolean
logic, flow
control, procedure and function calls, variable assignment / reference,
and the distinction between formal and actual parameters. And then I
strongly encourage them to extend this knowledge by understanding
pointer indirection and recursion.
A programmer who doesn't understand the strengths
and weaknesses of pointers is like a plumber who doesn't know how pipes
work and what makes a manifold.
And the plumber presumably learns how to work with
individual pipes
before he learns how to work with a manifold. Surely a learning plumber
does not get thrown into new construction work on a sky-rise without
supervision to start.
He can hack around, but he cannot
diagnose when plumbing makes noises, doesn't flow correctly or even
backflows.
That is my opinion. Maybe I am out to lunch, but has anyone seen any
language that didn't access memory?
Most assuredly not. But learning with
languages that assist in
developing a conceptual model for programming and then extend to a
fuller model appeals to brand new programmers.
PK