Re: Modernizing Common Lisp
From: Dave Roberts (ldave-re-move_at_re-move.droberts.com)
Date: 05/08/04
- Next message: Kenny Tilton: "PortaCello4: Faster, Lispier, and Noisier Than Ever"
- Previous message: Ari Johnson: "Re: Lisp in a Box"
- In reply to: Marc Spitzer: "Re: Modernizing Common Lisp"
- Next in thread: Erann Gat: "Re: Modernizing Common Lisp"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 08 May 2004 17:27:08 GMT
Marc Spitzer wrote:
> umm have you notices that *dam near every* java app that ships comes
> with its own java run time. It seem that no vendor will trust java to
> work with their app unless they ship the *exact* version of java they
> wrote it against. And all this mess only happened in the last 5-7 years.
Yes, but... you're identifying a versioning issue, not a portability issue.
That is, I want to ensure that the user is working with JDK 1.X. It isn't
so much a portability problem. I actually have pretty good confidence that
if you write to Sun's JDK 1.4 and you run on IBM's JDK 1.4, you won't have
too many problems. Now, is the system perfect, no. But it's far better than
saying, "Hey, all that portability stuff is just crap. Go wild, people..."
When something doesn't run on one implementation or another, it just means
you have a test escape in your compatibility test suite and you can
identify who is doing it right, who is doing it wrong, and make
corrections.
>
>>
>> CL certainly isn't the only language whose users have cried out for a
>> single API to address these (and other) things. Other languages have
>> delivered. So I'm not holding CL to a higher standard than others have
>> held other languages to.
>
> the other languages generally only have one authoritative
> implementation, perl, python, tcl, ruby ..., so they by definition are
> basically compatible *with them selves* and this is not true across
> time, just for a point in time represented by version x.y.z.
As you point out, there are compatibility problems across versions. That's
always going to be true. And you'll want a FORTRAN 90 compiler to compile
any code written with FORTRAN 90 syntax. So what? We're never going to fix
that problem, but that's a different problem.
> So C is not good enough to do "real work in", if you are curious take
> a look at qpopper's source code for the network bits. Each network
> access function was written 1 time for *EACH* unix it supported and
> was compiled in via #ifdef's. But above that level the api was the
> same so after your done with the socket code it ain't a problem any
> more. And if you want to add a new unix just add the compatibility
> layer and you are pretty much done.
Agreed, but the question is, why should everybody be writing that common
code over and over again? If we agree that it isn't hard to do, then why
don't we just agree on the interface, write it and debug it all once, and
then stick to that higher-level interface?
-- Dave Roberts, ldave-re-move@re-move.droberts.com Slowly but surely, the programming world is finding Lisp... http://www.findinglisp.com/blog
- Next message: Kenny Tilton: "PortaCello4: Faster, Lispier, and Noisier Than Ever"
- Previous message: Ari Johnson: "Re: Lisp in a Box"
- In reply to: Marc Spitzer: "Re: Modernizing Common Lisp"
- Next in thread: Erann Gat: "Re: Modernizing Common Lisp"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
