From: Kent M Pitman
Subject: Re: what kind on programming is lisp?
Date:
Message-ID: <u1xav4auv.fsf@nhplace.com>
"AnonymosX" <··········@gmail.com> writes:
> c - process oriented programming
> java - object oriented programming
> lisp - ?
C - weakly-typed, portable, low-level assembly language,
good for implementing low-level substrates, libraries, drivers, etc.
Java - strongly-typed, portable, high-level assembly language
good for implementing and sharing non-cycle-bound implementations of
tools for well-understood domains (i.e., those domains for which
interfaces tend not to evolve on a daily basis--e.g., standard
protocols).
Lisp - optionally-typed, high-level programming language
good for real-life (non-idealized) domain tools, where such domains
might be arbitrary in character, complex in connectivity,
heterogeneous in data arrangement, ill-understood (not subject to
complete or rigorous specification), unsynchronized in definition or
deployment, yielding to mixed-mode solutions, evolving routinely
in interface, etc.
One of my favorite partitions of languages (a multi-dimensional space in
general, but I like sometimes to look at just one axis) is the axis
implementational(0) vs expressional(10), on which I'd put machine language
at 0, traditional assembly language at 1, C at about 2, C++ about 3.5,
Java at about 5, and Lisp in the neighborhood of 8.5 or so.
But if you were just looking for a one or two word answer, that is,
the name of an adjective, I'd put "object-oriented" on Lisp and I'd
question the latter-day use of "object-oriented" to label systems
supporting encapsulation. The very idea of identifying the nature of
an "object" (surely an description word intended to describe a view
from the "outside" and to be a metaphor for the protocol of how it is
interacted with by other objects, not from within) as identifying its
internals is offensive to me. To me, encapsulation is an
implementation technique that by its nature MUST not be visible from
the outside of an object--that is, it must not be detectable whether
you wrote an encapsulated object in assembly language or in Java or in C++.
And since I am loathe to think that this implies that assembly language is
more object-oriented than Lisp, just for example, I have to conclude
that defining anything object-oriented on the basis of its
definitional syntax is bogus. Object-orientedness arose originally as
a discussion of how you poke at things from the outside. Do they
respond to a SEND operation, for example, or to [as in CLOS] generic
functions [which live outside of, not inside of, objects]. Is there a
WHICH-OPERATIONS message or a TYPE-OF operation or some such protocol by
which you can meet a new object of a type you do not know and ask it how
it works. Java beans maybe. Java a lot less so. C++ certainly not.
Consequently, I think encapsulation is a red herring. And I think Lisp
is owed back the name "object-oriented".
Kent M Pitman wrote:
> One of my favorite partitions of languages (a multi-dimensional
> space in general, but I like sometimes to look at just one axis)
> is the axis implementational(0) vs expressional(10), on which I'd
> put machine language at 0, traditional assembly language at 1, C
> at about 2, C++ about 3.5, Java at about 5, and Lisp in the
> neighborhood of 8.5 or so.
Do you have any pointers on what we get if we start turning the dial
further towards 10?
Is Lisp perhaps built along an edge where further expressivity makes it
less optimizable? Or more complex?
Tayss
From: Pascal Costanza
Subject: Re: what kind on programming is lisp?
Date:
Message-ID: <d0a4or$ag$1@snic.vub.ac.be>
Tayssir John Gabbour wrote:
> Kent M Pitman wrote:
>
>>One of my favorite partitions of languages (a multi-dimensional
>>space in general, but I like sometimes to look at just one axis)
>>is the axis implementational(0) vs expressional(10), on which I'd
>>put machine language at 0, traditional assembly language at 1, C
>>at about 2, C++ about 3.5, Java at about 5, and Lisp in the
>>neighborhood of 8.5 or so.
>
> Do you have any pointers on what we get if we start turning the dial
> further towards 10?
>
> Is Lisp perhaps built along an edge where further expressivity makes it
> less optimizable? Or more complex?
Probably more in the direction of less optimizable. I am currently
exposed to Pico (not Pico Lisp) and it has a construct to capture the
current lexical environment. Later on, one can use that environment to
execute new code in it. This allows for a nice way to implement a
(simplistic) object system. Consider this:
(defun make-person (name address)
(let ((person-name name)
(person-address address))
(flet ((print-person ()
(print person-name)
(print person-address)))
(capture)))) ;; <- capture the lexical environment
(defvar *pascal* (make-person "Pascal" "Bonn"))
(eval '(print-person) *pascal*)
(eval '(setq person-address "Brussels") *pascal*)
(eval '(print-person) *pascal*)
This is untested code, but I hope it's clear what I am getting at.
Pic%, the OO-version of Pico, adds some syntax to make this look more
like OO. (I know, I know, I don't like syntax either... ;)
Some time ago, Steven Haflich explained here in c.l.l why this is nearly
impossible to compile.
BTW, apparently OpenLisp supports capturing lexical environments. Some
Scheme implementations probably also do this, but I haven't found them...
Pascal
From: Kent M Pitman
Subject: Re: what kind on programming is lisp?
Date:
Message-ID: <u7jkn3s9c.fsf@nhplace.com>
"Tayssir John Gabbour" <···········@yahoo.com> writes:
> Kent M Pitman wrote:
> > One of my favorite partitions of languages (a multi-dimensional
> > space in general, but I like sometimes to look at just one axis)
> > is the axis implementational(0) vs expressional(10), on which I'd
> > put machine language at 0, traditional assembly language at 1, C
> > at about 2, C++ about 3.5, Java at about 5, and Lisp in the
> > neighborhood of 8.5 or so.
>
> Do you have any pointers on what we get if we start turning the dial
> further towards 10?
Well, there are languages that are highly abstract that allow you to make
logical assertions about your code, to do meta-modeling, etc. Lisp can,
with some effort, be made to do this too, of course. But it doesn't out
of the box...
There's also 3LISP, which demonstrates the possibility of a Lisp with a
conceptually infinite tower of lisps that implement the running semantics.
In "lay" terms, if you do (SETQ X 3) you assume there must be some meta-machine
that's busy doing (SET-LOCATION-IN-ENV CURRENT-ENV 'X (EVAL 3 CURRENT-ENV)),
and, moreover, there must be a meta-meta machine busy doing
(FUNCALL (FEVAL 'SET-LOCATION-IN-ENV CURRENT-ENV)
(EVAL 'CURRENT-ENV CURRENT-ENV)
(EVAL ''X CURRENT-ENV)
(FUNCALL (FEVAL 'EVAL CURRENT-ENV) (EVAL '3 CURRENT-ENV) (EVAL 'CURRENT-ENV CURRENT-ENV)))
and a meta-meta-meta machine busy doing... well, you get the idea.
I'm told this example actually comes from Alice In Wonderland, or perhaps
Through the Looking Glass. One of those...
There's something expressive there, too, but it's perhaps along another axis,
since in fact I don't think it increases perspicuity.
The kind of thing I was mostly leaving room for was more like greater
degrees of syntax extension, including the ability to interact better
with declarations than CL presently can. The ability for a macro to
ask questions about how a form (particularly a variable) is
type-declared in order to decide its expansion would lead to some nice
abstraction capabilities that CL falls just short of (and most other
languages never dream of).
> Is Lisp perhaps built along an edge where further expressivity makes it
> less optimizable? Or more complex?
I don't think so. It's just built by pragmatists who found a natural level
to work at, and who have incrementally fixed things above that level on an
as-needed basis.
Kent M Pitman wrote:
> "Tayssir John Gabbour" <···········@yahoo.com> writes:
>
>
>>Kent M Pitman wrote:
>>
>>>One of my favorite partitions of languages (a multi-dimensional
>>>space in general, but I like sometimes to look at just one axis)
>>>is the axis implementational(0) vs expressional(10), on which I'd
>>>put machine language at 0, traditional assembly language at 1, C
>>>at about 2, C++ about 3.5, Java at about 5, and Lisp in the
>>>neighborhood of 8.5 or so.
>>
>>Do you have any pointers on what we get if we start turning the dial
>>further towards 10?
>
>
> Well, there are languages that are highly abstract that allow you to make
> logical assertions about your code, to do meta-modeling, etc. Lisp can,
> with some effort, be made to do this too, of course. But it doesn't out
> of the box...
>
> There's also 3LISP, which demonstrates the possibility of a Lisp with a
> conceptually infinite tower of lisps that implement the running semantics.
.... ahhh. The Knights of the Lambda Calculus are still alive (at least
in memory!) :)
The interesting thing about 3Lisp is that you do not necessarily have to
have a meta-machine that is Lisp at all. You could have a Prolog
meta-machine instead. :) Things do get interesting at that point :)
Cheers
--
Marco
Kent M Pitman wrote:
> C - weakly-typed, portable, low-level assembly language,
> good for implementing low-level substrates, libraries, drivers, etc.
>
> Java - strongly-typed, portable, high-level assembly language
> good for implementing and sharing non-cycle-bound implementations of
> tools for well-understood domains (i.e., those domains for which
> interfaces tend not to evolve on a daily basis--e.g., standard
> protocols).
No, both are low-level, but much worse than assembly language: no
multiple return values, no tail-call support (ok, I don't really know
how CL handles tail calls either...).
From: Kent M Pitman
Subject: Re: what kind on programming is lisp?
Date:
Message-ID: <u3bvb3rre.fsf@nhplace.com>
Ulrich Hobelmann <···········@web.de> writes:
> Kent M Pitman wrote:
> > C - weakly-typed, portable, low-level assembly language,
> > good for implementing low-level substrates, libraries, drivers, etc.
> > Java - strongly-typed, portable, high-level assembly language
> > good for implementing and sharing non-cycle-bound implementations of
> > tools for well-understood domains (i.e., those domains for
> > which interfaces tend not to evolve on a daily basis--e.g.,
> > standard
> > protocols).
>
> No, both are low-level, but much worse than assembly language: no
> multiple return values, no tail-call support (ok, I don't really know
> how CL handles tail calls either...).
The items you cite are programming techniques.
No, CL doesn't handle tail calls as anyone who knows that term in the
first place ever seems to want. It's left to implementations for now.
CL prefers to allow implementations that want to favor stack debugging
to do so.
IMO what makes a language an assembly language is its lack of
attention to the dynamically changing needs of the user. Baroque
syntax that is hard to adjust, such that a small change in a program
spec results in a large change in text. Such code is often better
mechanically generated than written by hand. Most statically typed
languages fall into this pit, though some are also not reliable enough
to serve as an underlying base because they are not regular enough to
have predictable behavior without human eyes all the time on the code.
And C++, for example, is not very suitable as an assembly language not
because you can't pick a subset of it that is predictable, but because
in doing so, you lose a lot of power of the language...
Java and TeX are two examples of languages that work well as backends
for other languages, better than they work being programmed directly.
As such, assembly languages. They effectively define virtual machines
with interesting operations and then use a language that's more baroque
than necessary. So I recommend using the power and hiding the syntax.
Kent M Pitman <······@nhplace.com> writes:
> One of my favorite partitions of languages (a multi-dimensional space in
> general, but I like sometimes to look at just one axis) is the axis
> implementational(0) vs expressional(10), on which I'd put machine language
> at 0, traditional assembly language at 1, C at about 2, C++ about 3.5,
> Java at about 5, and Lisp in the neighborhood of 8.5 or so.
Domain-specific language (implemented in Lisp, of course) = 10 ?
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/