Re: The LOOP macro

From: André Thieme (this.address.is.good.until.2004.apr.17_at_justmail.de)
Date: 03/24/04 

Date: Wed, 24 Mar 2004 23:59:39 +0100

Pascal Costanza wrote:

>
> André Thieme wrote:
>
>> Björn Lindberg wrote:
>>
>>> And a condition system. And a multiple-dispatch object system. And
>>> proper closures. And ...
>>
>>
>> I am not here to fight for Pyhton, however I would like to mention,
>> that in complex situations generic methods won't help you and you will
>> need real pattern matching, so ocaml for example offers here some nice
>> stuff.
>
>
> In Lisp, you can build your own pattern matching layer on top of what's
> available, and make it look and behave like it was always part of the
> language. You can do the same for list comprehensions.

Of course this is a great thing.
But to be fair, when a language X does not support a feature the users
of X can always say that you can simply implement this feature. In the
same time the users of language Y think: oh, we already have this and
this looks like an advantage.
So when we can say: "Ok, Lisp cannot do it but we can always program it
in a way so it gets this feature", then we can also use the same
argument for another language which does not directly support a feature
which Lisp supports.

One factor is very important and you also mention it a bit later in your
post, and that's the fact that it is important how easy it is to bring
some new features into a language. And here is a point where even some
complex behaviour can be implemented pretty easy into Lisp.

> I recommend this as an advanced exercise for learning Lisp:
> ke one of your favourite language features from other languages and
> reimplement them on top of, and integrate them with, Lisp.

I will do and I already have some few ideas. In a few months I should
be ready to do this.. my main problem is the coming semester which will
be very demanding on me, not to forget my work in the company.
All this costs also some time.

>> And to closures:
>> for example in Java you could simulate them with inner classes.
>> They are not "really" closures, but you don't need them.
>> It's the same when a Java-guy asks how he can make inner classes in
>> Lisp, everyone would ask him to use closures instead...
>
> Java's inner classes can only refer to final variables of the
> surrounding lexical environment. This means that you cannot change the
> contents of those variables from within an instance of an inner class.
> That's a serious restriction, and the workarounds are ugly.

Inner classes have some restrictions... however, they also offer some
advantages, for example they are extendable while closures are not.
In Lisp I might start with a closure for a problem while in Java I would
have to do some extra keystrokes for inner classes because I am limited
to solve my problem this way. But when I discover later that I need to
extend my code then I have to rewrite the Lisp solution while in Java I
could go directly to continue coding on the extension, because I was
limited to one solution.

Again, I am not trying to defend other languages like hell here. I have
already decided to become a Lisper. I am even getting problems reading
Java oder C code and it feels nicer to see Lisp code again.
Anyways, I also want to express that I am not a blind follower. Lisp is
not perfect and not the best solution in every case for every problem.
Some of the Lisp lovers are blind for anything else but Lisp.
Other languages also have now some great features, most "stolen" from
Lisp. However, even if they were stolen - they do exist now and make
even other languages effective.

> Lisp's closures only contain one "method" by default whereas Java's
> inner classes may define several methods. That's not a serious
> restriction of closures, and the workaround, if needed, can be hidden by
> way of abstracting away the details in proper macro definitions. (So,
> no, a Lisper wouldn't tell you to use closures, but first would try to
> make you think about what abstractions you _actually_ need. Closures are
> "only" building material for higher-level abstractions, and not means to
> their own end.)

Thanks for pointing that out.

> Always note the most important bit in such discussions: It's not _what_
> you can do, but _how_ you can do it.

Yes right, this is a very important point.
The tools should make the work easier (although it will cost some people
their jobs because more powerfull tools remove the need for some work to
be done, but this is another topic). Turing completness grants that no
programming language is more powerfull than another one if both are
turing complete.

> You can program everything in
> low-level assembler code, but this doesn't mean that this is an
> appropriate abstraction layer. The power of a language comes from being
> able to abstract away the unimportant details and focus on the things
> that are relevant for the domain at hand. Java only allows you to
> express your abstractions at the level of objects, classes, fields and
> methods. If you want to transcend that level, you need to go outside of
> the language and, for example, use code generators instead. But then you
> are in fact not programming in Java anymore.

This is a psychological argument.. some people will maybe not feel good
anymore if they are not programming in their language.
 From a companies POV it is not so important anymore. When there are code
generators who support the work of the masses of the Java coders they
can be used, not regarding the interests of some "fans" of "clean"
programming.

> In Lisp you can always build the abstraction that you need right into
> Lisp itself. This allows you, in principle, to always stay in the
> language. But I am going to stop here. Since you have started to read
> PAIP, I am pretty sure you will get it soon... ;)

I agree, the book really looks great and because of its general structure
it can be usefull for many coming years. Even when Grahams Arc is out I
think that some techniques which the books presents can still be used.

Going back to read in it...

André 

--

Relevant Pages

  • Re: Be afraid of XML
    ... | that Java is an engineering masterpiece: ... | Interestingly the same is historically true for Lisp: ... BLISS (Basic Language for the Implementation of Systems Software) ...
    (comp.lang.lisp)
  • Re: Reddit Guys on the Pros and Cons of Lisp
    ... >> I never have to do that with Java. ... > language features, etc. ... They either have the feature or they don't. ... > libraries doing almost the same - for those languages. ...
    (comp.lang.lisp)
  • Re: Oft-shared (perhaps?) Impressions of a Lisp Newbie
    ... Lisp community that lexical closures were the right thing. ... Did they agonize over the decision to start a new language ... prefer Java to C++. ...
    (comp.lang.lisp)
  • Re: Joel hammers the final nail into Lisps coffin
    ... Indeed, if you are an inexperienced Lisp programmer, you will probably ... Well yes if you a are super brilliant Java programmer you'll be ... Of course you can use some language compiling to Java which offers ...
    (comp.lang.lisp)
  • Re: Why default parameter values where not included in Java
    ... If you create a language with a bunch ... Sun wanted to encourage fast adoption of Java by a very large group ... The issue is not whether the feature could save a few lines of code. ... and the reasons of various team members ...
    (comp.lang.java.programmer)