RE: s-exprs + prototypes

["Anton van Straaten" <address@hidden>]

Steve Dekorte wrote:
> On Saturday, June 21, 2003, at 02:22 PM, Anton van Straaten wrote:
> > Of course, for any given program design, it's quite feasible and
> > usually easy to come up with an equivalent design that suits the
> > paradigm of the language being used - but then the language is
> > dictating aspects of the design of the program.
>
> They always do. Despite the fact that one can implement anything in a
> complete system,in practice, a system's fundamental constructs will
> cause people think about problems in those terms.

I completely agree with this, which was why my next statement was "All
languages do this to some extent".  The question is to what extent.  One
issue is the simplicity/complexity or atomicity of the fundamental
constructs.

To repeat myself, "if a language requires you to express everything in terms
of class-based objects, or prototype-based objects, that's less general than
a language which makes fewer assumptions about what types of objects (or
other construct) you want to use, and how they should work."

> Do you want people to think about problems in terms of lists or objects?
> Your answer to this question will determine the appropriate answer to
> the question of which constructs are most appropriate.

My answer to that question is "neither".  I want to think about problems in
terms of abstractions.  Lists provide one very basic and primitive kind of
abstraction.  "Objects" provide another kind of abstraction.  A very general
definition of an object might be roughly equivalent to what I'm calling an
abstraction.  However, as soon as you start talking about how all objects in
a particular language must work internally - e.g. class-based or
prototype-based single-dispatch - and if those implementation details have
an impact on the way in which all code in the language must be written or
structured, as they tend to do - then you've lost some of the generality I
was talking about.

To illustrate this issue, what happens if I want to use prototype-based
objects and class-based objects in the same program?

On the subject of proper abstraction in programming languages, I liked a
message of Francois-Rene Rideau's from April:
http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg02760.html

See the message for more context, but here's the most relevant bit:

  "Why should there be a one 'canonical' way to construct and match
integers?  No sane mathematician does that.  Why should computer scientists
do [that]?  Mathematicians always consider types up to isomorphism.  Why
don't Computer Scientists do [that]?

  "My bet is that the real progress in the next 50 years will be that
programming languages will allow to reason up to isomorphism.  And not just
a static set of isomorphisms, cast in stone by the language specification.
No, a dynamic set of isomorphism, that grows with the code base,
that grows with the 'artificial intelligence' in the programming
environment."

I would characterize current object systems as one early, and mostly
informal, attempt in this general direction.  But I think they fix too many
aspects of the design too globally, which impedes further progress - there's
danger of an evolutionary dead end.  In which direction, for example, is
Smalltalk going to grow?  There's more to programming than a single object
model.

Anton