Re: Reddit Guys on the Pros and Cons of Lisp

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...

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.)

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.


Pascal

--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
.

Relevant Pages

  • 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: 7.0 wishlist?
    ... The primary purpose of unchecked conversions is to facilitate migration to generics at disparate times. ... Operator overloading is principally used for mathematical constructs. ... It is not the job of the language designer to enforce against every conceivable misuse of a language feature, least of all to do so by simply refusing to add any features at all for fear that they might otherwise be abused. ... it is difficult for Java to not have chosen C++ syntax for various reasons. ...
    (comp.lang.java.programmer)
  • Re: the Java Lang will support Properties in Futuere?
    ... the fact that some other language has a feature isn't a reason to include it in Java per se. ... setPropertyA ... A second cost is that property support makes name resolution--a difficult step already--somewhat more difficult. ...
    (comp.lang.java.programmer)
  • Re: Java type-casting -- Q3
    ... Java doesn't have any grammar or syntax for that scenario now. ... You also have to make sure those modifications don't interfere with existing language features, nor would interfere with other more important language features that may come about in the future. ... And then you have to implement all that in a completely bug-free way in the compiler, and possible the run-time itself depending on how deeply ingrained the feature is. ... If you want variable-length type parameter lists in generics, you are easily talking up to a year, or more, of design and development work. ...
    (comp.lang.java.programmer)
  • [ANNOUNCE] Jun for Java (Jun695)
    ... We have released a new version, 695, of "Jun for Java". ... (new feature) ... enables reading and writing a GIF animation. ... JunOpenGL3dModel and JunOpenGLDisplayModel ...
    (comp.lang.java.announce)