low-level approach

[mdanish@andrew.cmu.edu]

On Tue, Jan 15, 2002 at 12:06:25AM -0500, Kyle Lahnakoski wrote:
> 
> 
> mdanish@andrew.cmu.edu wrote:
> 
> > As for this entire sub-thread, if any modern Lisp were truely as you
> > describe it, it would be less than useless for most practical purposes.
> > I want arrays, structs, classes, hashtables, etc, and I want them
> > *efficiently* implemented in native-code compilers.  Of course Java/C++
> > and the rest of the crowd were to be compared against that extremely
> > backwards and limited form of Lisp then they would seem to be more
> > practical.  Fortunately the designers of Common Lisp didn't think that way.
> > If you want an example of a Lisp that is closer to what you present,
> > see the misnamed "newLISP", http://newlisp.sf.net/ I believe.
> 
> I did not mean to imply that Lisp is not superior to C or Java.  I
> wanted a discussion on WHY it is so.  What aspects of Lisp make it a
> good language?  Arrays, structs, classes, hashtables are all features
> that make a language better.  I would like to know more about the
> aspects of the core Lisp syntax that makes it preferred over other
> languages.

The distinction I find about the Lisp syntax is the fact that it is simply
a representation of a data structure, namely a tree with atoms at the leaves.
This enables features such as Common Lisp macros which can play with that
tree and transform code/data in all sorts of ways.

> 
> 
> > Finally: The fact that all Turing-complete languages can express each other
> > does not lead to the conclusion that all Turing-complete languages are
> > equally expressive, or have equal semantics. 
> 
> The point of that post was that expressiveness appears to have no formal
> definition.  I am having a conversation with Billy Tanksley where he
> suggests that expressiveness is related to minimum code length.  An
> excellent thought, but I have trouble digesting it because it appears to
> make code unreadable/complex; much like trying to read/write a zipped
> text file.

I believe a lot of people find expressiveness to be related to the amount
of effort one has to produce in order to achieve a goal.  An alternate
definition might be the ability to represent the meaning of a program
in a vivid and lucid manner, in the language of discourse.

The former requires some baseline to be measured against.  How much
effort does it take to write Program A in a language with special
features for Program A vs a language without those special features,
for example.  I suppose that this should really be called "productivity"
and given in terms of some goal and some baseline.

In the latter sense, an ideally expressive language would never need any 
comments; it would be the ultimate in self-documenting code.  It also
suggests the usage of mechanisms such as abstraction, encapsulation, and
macros.

> 
> 
> > I can write a Lisp program
> > with Turing-machine notation if I first design a Lisp interpreter/compiler
> > in Turing-machine notation.  But by the fact that I have to write an
> > interpreter/compiler first means that Turing-machine notation does not
> > have the same expressiveness as Lisp.  
> 
> Of course not.  Our intuition has something in mind.  I am unsure of
> what expressiveness is or even if it even exists.
> 
> Suppose I am given a commercial C development environment with a Lisp
> package.  Is the resulting system as expressive as Lisp?
> 
> This supposition lead me to my ranting at the end of my other post.  I
> saw that these extra code portions could be realized as IDE features
> (GUI builder, lexx, yacc, Lisp interpretor, etc).  Is this IDE not as
> expressive as Lisp?  This brings up the question of why do we even need
> a better language when we can (in theory) build whatever we want from
> any turing-complete language to begin with?  Of course, all these
> features take a lot of work to build.  But to go a step further, in
> trying to design an HLL for Tunes we are essentially trying to make IDE
> features appear as beneficial language aspects.  Does this mean that we
> are in for the same amount of work no matter if our advancements are in
> the form of IDE features or language aspects?.

I'm going to answer all this in one concise way: every program that you
write defines a new language.

Consider the C development environment by itself.  In it I can create
a function hello_world() that prints out the phrase "Hello, world".
I have in effect created a new language that includes all of C AND my
new function called hello_world().  This language has all that C has
to offer, and it's more productive at printing the phrase "Hello, world"
than C (it takes less effort to do).

Apply the same reasoning to a lisp() function which accepts a Lisp program
as argument.  

Of course C is not very productive when it comes to defining new languages
compared to Lisp, due to macros, CLOS, functions, dynamic-typing, etc.
In our C + lisp() language, however, we have the Lisp features at our
disposal.

Now lets say we are more interested in doing Lispy things than C things.
We can create a Lisp development environment in which we have a macro
named C available, as opposed to a C with a lisp().  This makes us
more productive at Lispy things.


So here are some premises:

Everything you use builds off of previous work and in doing so defines 
a new language for future work.

A language that is expressive is one that allows you to represent the
meaning of a program clearly.

A language which is productive at defining new languages is better for
defining more expressive languages.

Lisp is more productive at defining new languages than C.

Therefore:

Lisp is better for defining more expressive languages, than C is.


As for IDEs vs language aspects, they are one and the same thing.
C + IDE, or Lisp + IDE, either way it's a new language.
Since Lisp + IDE includes Lisp, it can be substituted for Lisp in
the premises above.

There is one more thing which I've somewhat neglected: the relationship
between expressiveness and productivity.  It seems to make sense to me
that a more expressive language is more productive, in the long run.
But this is all speculation really, I'm interested in hearing what others
think.

(Hmm, now that I think about it, expressiveness needs to be defined in
terms of a problem as well.  I think it still fits in with everything,
so long as you add "for a given task" every time you see "expressive".)

-- 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Matthew Danish                         email: mdanish@andrew.cmu.edu ;;
;; OpenPGP public key available from:        'finger mrd@db.debian.org' ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;