Re: Lisp's future
From: Rahul Jain (rjain_at_nyct.net)
Date: 01/27/04
- Next message: Rahul Jain: "Re: Static/Strong/Implicit Typing"
- Previous message: Rahul Jain: "Re: Static/Strong/Implicit Typing"
- In reply to: Marco Antoniotti: "Re: Lisp's future"
- Next in thread: Thomas F. Bur***: "Re: Lisp's future"
- Reply: Thomas F. Bur***: "Re: Lisp's future"
- Reply: Marco Antoniotti: "Re: Lisp's future"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 27 Jan 2004 00:24:06 -0500
Marco Antoniotti <marcoxa@cs.nyu.edu> writes:
> Ville Vainio wrote:
>
>> I guess answering to this one covers most of the points in other
>> posts, so here goes.
>>
>>>>>>>"Bulent" == Bulent Murtezaoglu <bm@acm.org> writes:
>> VV> Also, Lisp mostly impressed me initially because it was simple
>> VV> and orthogonal. Reading On Lisp kinda crushed that illusion
>> VV> for me - Common Lisp is not simple.
>> Bulent> What part did you find complicated? On Lisp is not
>> Well, all of the sharp-quoting for starters. Seperate namespace for
>> functions seems to cause nothing but harm. This is more of an issue
>> for CL, not On Lisp.
>
> Never hurt me.
But you don't run with quotes. (Sorry, bad pun.)
>> Pretty much. I would like to see an Open Source Lisp implementation
>> with a big standard library, providing sockets, normal posix stuff,
>> and generally most of the stuff in the Python standard library. And in
>> equally easy to use form.
>
> Could you name a Common Lisp implementation that does not provide you
> with all of that? (I'll challenge you even on the GUI side).
He explicitly said that he wanted all that to be _in_ the CL
implementation itself. The ability to choose third-party libraries for
unexplored or non-standardizable code has been revoked. :)
>> I know that the model has zillions of problems, and shredding it to
>> pieces is not really worth it. Just showing what kind of aesthetic I
>> like.
>
> It is not just a matter of aesthetic. Common Lisp correctly separates
> the notion of encapsulation (packages - with all, but not many,
> limitations) form that of OOP. Generic functions *are* a better way to
> do OOP.
Actually, the problem is even worse with these C++/Java/Python/Ruby
languages. They conflate 3 things: types, scopes, and
namespaces. (Granted, C++ has namespaces, so it is a bit better about
this than the others.)
>> But I guess this is just a matter of prejudice - I might change my
>> mind immediately when I actually try CLOS on real CL. I'm certainly
>> going to.
>
> That is good. Download CMUCL and have fun with it. You will see why we
> pine so much about it.
And CMUCL's compiler is named Python, to boot. I'm sure he'll have a
blast. :)
-- Rahul Jain rjain@nyct.net Professional Software Developer, Amateur Quantum Mechanicist
- Next message: Rahul Jain: "Re: Static/Strong/Implicit Typing"
- Previous message: Rahul Jain: "Re: Static/Strong/Implicit Typing"
- In reply to: Marco Antoniotti: "Re: Lisp's future"
- Next in thread: Thomas F. Bur***: "Re: Lisp's future"
- Reply: Thomas F. Bur***: "Re: Lisp's future"
- Reply: Marco Antoniotti: "Re: Lisp's future"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]