Re: Reddit Guys on the Pros and Cons of Lisp
- From: "Pisin Bootvong" <joesb.coe9@xxxxxxxxx>
- Date: 1 Dec 2005 01:08:43 -0800
Pascal Costanza wrote:
> Pisin Bootvong wrote:
>
> > Please don't tell me to choose an implementation based on each project.
> > I never have to do that with Java.
>
> That's incorrect. With Java, you always have considerable periods of
> time in which you have to worry about the concrete version number of
> Java. It happened during the transition from 1.0 to 1.1, from 1.2 to
> 1.3, from 1.3 to 1.4, and now from 1.4 to Java 5. Only the transition
> from 1.1 to 1.2 was relatively smooth because they didn't add new
> language features, etc.
>
> Just recently I tried to compile some large Java application that was
> developed for 1.4 but didn't compile anymore because some of the new
> keywords in Java 5 were used as variable names. That project is unlikely
> to be updated by the original developers, so there are definitely
> similar situations in the Java world like in the Lisp world. The only
> real difference is that there are lots more Java hackers than Lisp
> hackers out there which helps in some cases, but not when you are
> concerned about a niche Java library or Java application.
>
> And I haven't yet talked about the differences between the various
> micro, standard and enterprise editions with their respective sub- and
> de-facto standards...
>
Response below.
> > The benefit of never need to change
> > the lisp implementation is that I can be proficient in it. No
> > implementation is going to be perfect. So instead of learning to work
> > around only one implementation's bug, with multiple implementation I
> > have to be aware of that implementation's different behavior and
> > workaround. That's not nice.
>
> ...but doable. Many people do it.
>
> > Most of the time, nobody has such problem when they are working with
> > Ruby or Java. They either have the feature or they don't. And if they
> > don't, the chances are that a feature added by 3 people working on one
> > implementation will be more robust/well-designed/well-maintained than a
> > feature added by 3 people, each works on separate lisp implementation.
>
> Again incorrect. The problem with those languages is that if they don't
> have a particular feature, they either announce it to have it in the
> future which stifles your progress and/or forces you to use ugly
> workarounds in the meantime, or they don't announce it which definitely
> forces you to use ugly workarounds. Those languages don't offer enough
> abstraction facilities to make your workarounds look like first-class
> citizens of the language, which is an important feature because it makes
> programming less error-prone. (However, Ruby is probably better in this
> regard than Java.)
>
Right, I should have never brought Java as example. But that is because
it is hard to change how Java works since Sun controls it. So this is
an issue of open/close source language implementation, not that of the
language itself. Ruby is probably better in that it is open source and
runs around more friendly community that useful features will more
likely gets add if there is good reason to it.
Anyway, I'm not talking about the features that require language
semantic changes.
I'm talking about system feature like Threading, Networking; features
that can not be added by simply writing inside the language's world
itself. For example, you cannot create an asdf package that will
provide native thread for CLISP. Such thing can't be written as the
library in the language itself. And it didn't change the syntax of the
language. It requires developer to works on the internal. And since
these are internal detail, it is hardly shared between implementation.
It is already hard for any language community to gain user base. It is
even harder to gain the developer who is also a good C/C++ programmer
who knows internal of the implementation. That's why I said it's pity
that these hard to get resource must be split out.
For example, if SBCL haven't been forked off CMUCL:
- CMUCL in a sense probably got Unicode support.
- The separated effort of porting CMUCL and SBCL to Win32 will be
unified and that will probably speeds up the development since people
who works in group probably can share knowledge.
:: On the other hand SBCL has reason to forked. So, may be, if SBCL
hadn't forked, we would still just get this current CMUCL anyway.
That's not technical issue but more of the political issue, me think.
> > And often, the effort is even more wasted. Some people saw a library
> > that do what they like but not on the supported implementation. But the
> > library may be to hard to port, too much must be done to make it work
> > on their platform. So instead of porting, they decide to write a new
> > library, only little variant from the original library, only with less
> > feature, rarely maintained, but it works for their cases.
> [...]
>
> > If someone writes a library that works on Java or Ruby, it works for
> > others that download them, that's because they all are on the same
> > implementation.
>
> In theory yes. In reality, there's also a lot of redundancy - many
> libraries doing almost the same - for those languages.
>
This is also true for Lisp.
There is many factor to redundant library such as, community size,
implmentation variant, different main goal (footprint size/
performance/feature full), etc.
Lisp doesn't yet suffer the first factor :)
And it's always good to reduce the one factor.
>
> Pascal
>
> --
> My website: http://p-cos.net
> Closer to MOP & ContextL:
> http://common-lisp.net/project/closer/
.
- Follow-Ups:
- Re: Reddit Guys on the Pros and Cons of Lisp
- From: Pascal Costanza
- Re: Reddit Guys on the Pros and Cons of Lisp
- Prev by Date: Re: FORMAT ~<...~:@> PUZZLE
- Next by Date: Re: OT to the extreme
- Previous by thread: Re: Reddit Guys on the Pros and Cons of Lisp
- Next by thread: Re: Reddit Guys on the Pros and Cons of Lisp
- Index(es):
Relevant Pages
|
|
