Re: naturally imperative? [was: Curly braces]

[Guy Steele - Sun Microsystems Labs <address@hidden>]

   From: Bruce Lewis <brlewis@alum.mit.edu>
   To: Vladimir G Ivanovic <vladimir@acm.org>
   Cc: ll1-discuss@ai.mit.edu
   Subject: naturally imperative? [was: Curly braces]
   Date: 30 Nov 2001 16:34:27 -0500
   
   Vladimir G Ivanovic <vladimir@acm.org> writes:
   
   > I also believe that one of the reasons for Java's popularity is
   > that it more closely matches the imperative way we actually behave: we
   > perform actions on objects for their side effects, e.g. toasting a
   > bagel.
   
   But programming isn't about doing things.  Object code is about doing
   things.  Program code is about describing how to do things.

   Describing how to do something step-by-step from the beginning is a very
   unnatural process, even for things you do yourself.  It takes much
   practice and training to describe things this way.
   
   More naturally, we tend to describe things at a high level first,

Unless we're using a postfix calculator, of course.  :-)

   								     then,
   when pressed, we fill in the details as to how we got there.  If the
   person we're explaining it to still doesn't get it, only then do we
   exert the mental effort to try to recall every step in sequence.
   
   For a popular example of non-imperative programming, look at the
   Standard Query Language for databases (SQL).  An SQL query is a
   description of a data set you want to retrieve, but it bears no
   resemblance to a step-by-step description of how to get that data.  It's
   up to the database server to choose an efficient plan from multiple
   possible plans.

The distinction you are grasping for here is a useful one,
but it's not cut-and-dried.  Most imperative programming languages
actually leave a fair amount of latitude for an optimizing
compiler to make non-trivial decisions about which of many
possible execution plans to choose for a given target machine.
A simple example: deciding whether a common subexpression should
be evaluated once or repeatedly.

Referring to your first paragraph, object code is not necessarily
that much more specific than source code.  Object code is "merely
another description".  Sure, object code may say specific things like
"load this register, then add, then add, then multiply, then divide"
but modern processors may well perform on-the-fly register renaming
as well as out-of-order execution of instructions based on dynamic
availability of execution units such as adders and multipliers;
in the sequence I just cited, the multiply may well complete before
the second add does.

--Guy