RE: How about in INC opcode(how important is syntax in the learni ng curve?)

[boldt@xxxxxxxxxx]

Joel wrote:
>I think it's a semantic issue and that I wasn't completly clear on what I
>meant.
>
>First, I should have said grammar and syntax.
>
>Second, my Whorf-Sapir analogy was that the grammar and syntax of a
computer
>language are products of the underlying concepts and provide a way to make
>inferences about the underlying concepts of the language.  I don't think
you
>can really use the syntax correctly unless you understand the underlying
>concepts, and I think that understanding the syntax well should lead to a
>better understanding of the underlying concepts.
>
>In a procedural language when you want to print something you invoke the
>print verb in some way or other.  In an object oriented language you
invoke
>the print method of the object you want to print, or you get some sort of
>information(message) from an object and pass the results of that to the
>printing object.  To me this is a matter of grammar and syntax, but I can
>easily see how someone else wouldn't see it that way.  I think it's
possible
>to talk about inheritance and polymorphism from this point of view too,
but
>it's getting a little late in the day for me for abstraction.

Well, maybe it's too early in the day for me to put together a
cogent response, but...

Yes, basically it is a semantic issue.  But I think we're
looking at this from different angles.  Yes, at one level, you
could argue that at an operation level, most languages basically
implement the same concepts.  For example, you could take a
program written in a procedural language, like C, and translate
it more or less word for word into a more sophisticated language
like Java or Perl.  But, at a higher level, it wouldn't
necessarily be a good Java or Perl program.  Java and Perl allow
for different levels of abstraction.  A good program in Java
involves breaking down the problem into its constituent objects.
Perl is good if you can reduce the problem into a string
manipulation exercise.  These higher levels of abstraction
encourage the programmer to think about the problem differently.
Not just in terms of stringing together a set of basic
operations (which generally exist in most languages), but rather
to transform the problem description at a higher level.  Look at
the language Prolog for something that really gets away from the
procedural model!

Look at this (simplistic) history of programming:  In the 40's,
programming was done by hardwiring circuit boards.  In the 50's,
it was assembly language.  The 60's brought structured
statements. The 70's gave us data structures.  The 80's, modules.
And the 90's made us learn objects.  Each decade made us think
about our programming problems at a higher level of abstraction.
The underlying hardware really hasn't changed much - it still
does MOV and ADD and JMP instructions - but the way we think
about programming has.

Perhaps that's what's wrong with the Whorf-Sapir hypothesis:
There are simply too many levels of abstractions between human
language and the underlying hardware.  But then, that discussion
really belongs to philosophers and cognitive psychologists.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---