Path: utzoo!attcan!uunet!snorkelwacker!tut.cis.ohio-state.edu!pt.cs.cmu.edu!rochester!udel!carroll
From: carroll@udel.edu (Mark Carroll <MC>)
Newsgroups: comp.lang.misc
Subject: Re: Algol, and language design
Message-ID: <26058@nigel.udel.EDU>
Date: 30 Jul 90 12:49:35 GMT
References: <25630@cs.yale.edu> <58091@lanl.gov> <25767@nigel.udel.EDU> <2417@l.cc.purdue.edu>
Sender: usenet@ee.udel.EDU
Reply-To: carroll@udel.edu (Mark Carroll <MC>)
Organization: University of Delaware
Lines: 83

In article <2417@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
]In article <25767@nigel.udel.EDU>, carroll@udel.edu (Mark Carroll <MC>) writes:

]
]As for language design, I am certainly not an expert.  But I do not object
]when those consulting me ask for something the standard statistical procedures
]cannot deliver.  The statistical packages are as limited as the HLLs.
]

But you would object if people asked you for something which didn't
really make sense in the context of statistics. "Hey, Herman, your stats
package doesn't provide a recurrence relation solver - could you hack one
up for me?" - what would you think of a person who asked you that?

]
]Recursion still is hard to implement.  There are situations where plopping
]everything on the stack is a good way, and situations in which this is
]horrible, and managing memory blocks is a better idea.  Without guidance
]from the programmer, the compiler will not know which.
]

Can't it? I believe that I know some folks who would strongly disagree with
you. Static compile-time analysis is improving every day, and there is nothing
about recursion that is so horribly difficult. An intelligent compiler that
tracks dataflow can certainly decide which way to implement a recursion.

]You say you sometimes want this, and sometimes that, and sometimes the other.
]I want all of this, and more, at the same time.  If, for example, C does a
]good job of expressing the structural considerations in an algorithm, an
]optimizing C compiler may do well.  But if it does not consider relevant 
]aspects, it will not do well.  And I do use programming constructs which
]are very clumsy in the HLLs I have seen, but simple from a mathematical
]point of view.
]
]You like an object-oriented language, and you like a functional language.
]Why not combine everything?  It is not so much a problem for the language
]designer as for the compiler writer.
]

What you're asking for doesn't even make good sense. Yes, I like oo
languages. And I like functional languages. But combine them? It doesn't
make good sense. 

A program in any language is a description of a machine. The language
that you use determines what kind of machine your program is
describing. In an Algol like language, you're basically modelling a
vonNeumann machine. In Smalltalk or Self, you're modeling a
message-passing machine. In Haskell, you're modeling a machine that
does lambda calculus expansion. The models don't necessarily mix. If I
mix the message-pass model of Smalltalk, and the functional model of
Haskell, I end up with a monstrosity that destroys that attractive
features of both! In a big way, the thing that makes Smalltalk so good
at solving certain problems is its idea of object identity, where the
object contains its own state. The primary advantage of a language
like Haskell is the total lack of mutable state. How can I combine
those two? It makes no sense, because the underlying machine models of
the two languages are so radically different.

]In addition, I find the architectures simpler than the HLLs.  It is not
]true that Algol has all the primitive operators for numerical calculation
]in its list of operators.  It is true that it has enough that one can 
]define any other, but this is like saying that the way that multiplication
]should be perforemed is by squaring the sum and the difference, subtracting,
]and shifting right two bits.  The compiler may very well miss what I see, and
]vice versa.
]

The underlying architecture of the real machine may be vastly simpler than the
model underlying the language that is chosen to solve a problem. But that
doesn't really matter. (A RISC machine has the simplest architecture of any
of todays computers, but that doesn't mean that I want to write all my
programs in RISC assembly!) The important thing is how clearly the language 
models the solution. The code written by a hotshot hack in assembly may be
"better" in an efficiency sense than the code output by an SML compiler -
but if the machine language does not clearly model the solution, and the
SML program does, the SML is the better choice.

	<MC>
--
|Mark Craig Carroll: <MC>  |"We the people want it straight for a change;
|Soon-to-be Grad Student at| cos we the people are getting tired of your games;
|University of Delaware    | If you insult us with cheap propaganda; 
|carroll@dewey.udel.edu    | We'll elect a precedent to a state of mind" -Fish