Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?]

[kaz@vision.crest.nt.com (Kaz Kylheku)]

In article <51368e$6ir@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>rgilbert@unconfigured.xvnews.domain (Bob Gilbert) writes:
>
>>I suspect our definitions of procedural vs non-procedural (e.g. object
>>oriented) views are not the same.  Non-procedural views do not imply 
>>"instantaneous" algorithms, the non-existence of a time axis, or whatever.
>
>It strikes me as a very strange use of language to call object-oriented
>programming (of the kind exemplified by Simula 67, Smalltalk, C++, Ada 95,
>CLOS, Eiffel, Self, Cecil, NewtonScript, &c) "non-procedural".  They are
>about as thoroughly procedural as you can get.
>
>The opposite of "procedural" is not "OOP" but "declarative".
>Declarative languages include Haskell, Clean, Mercury, and perhaps Goedel,
>which I don't know all that well.  Maybe Sisal at all, but I don't know it.

Lex and awk would also be familiar examples of such languages, to an extent.
The pattern matching rules of lex are not though of as executing in any
particular order, unless there is a conflict between two equal-length matches
in which case the pattern appearing first in the lex source is preferred.  Awk
pattern matching rules are also not arranged in a procedural sequence. Of
course, when matching occurs, ``actions'' are invoked, and the program
temporarily becomes procedural.

State machines, like the pattern matcher of a Lex generated program, are one
good example of non-procedural programming. The actual procedure which drives
the state machine is typically trivial, and is simply not telling of the intent
of the machine. It is driven by the state configuration and by input. (Of
course, the state transitions of the machine can be arranged so that the
functioning can be understood procedurally, but that's a separate issue: after
all, a state machine can interpret instructions which form a procedure).

>In those languages the programmer has no idea and no reason to care in
>what order operations are performed; any order the compiler chooses will
>make sense.  (Yes, it is still possible to write programs that interact
>with the world, and at least in Clean, very simply and elegantly.)

But this is tue of OO programming as well. You have an object, and you can
interact with it in ways that don't necessarily obey a particular order; the
object acts like a state machine. This is why OO folks like to talk about
messages rather than function calls.

OO is used a lot in GUI developemnt, and modern GUIs typify a non-procedural
approach. Most of the time, the user can interact with the interface in an
ad-hoc fashion, changing the state of various internal objects. The structure
of such a program reflects that.

I suppose that object orientation is a completely orthogonal issue to
procedural versus non-procedural. I also suppose that there are many
ways to be non procedural, so that ``declarative'' is either a very broad
umbrella, or is just one example of the many ways.