the future of LispWorks

[Francois-Rene Rideau]

> That's clever of you: enlisting a list full of people who
> have discussed this before and agree with you :-).
Well, that too, but my original idea was to have a place
where my diatribes would be publicly archived :)

> I'm leaving Martin out of that, since he hasn't expressed an
> interest.
Sure. Too bad. I removed him from this Cc:

> Yes, Dylan macros, while an improvement on most languages, just
> aren't as good.  However, I think it's Dylan whose future is
> more in danger now: there's already a free implementation and
> it's not exactly conquering the world.
I see being free as a necessary, but not sufficient, condition
to conquer the world, in the long run.

It took a lot of hype to make Java the thing it is today,
and it also took making it freer than the competition, and freer everyday,
as well as true portability, and prolonging the myth of binary compatibility.
Dylan lost its hype value together with Apple's support,
and didn't play the game of free cooperation
(poor Gwydion people have a hard time working with no support,
no standard, no code base, no clear goal; they are isolated).

I also perceive Dylan sealed class as technological contorsion
to suit inadequate political goals of promoting black-box software
whereas success comes from bending politics by making technically inadequate
(just like Xanadu lost and the Web won,
because Xanadu relied on contorted technology to preserve copyrights,
whereas the Web used simple technology and questions copyrights).

Ok, technically, the role of sealed modules is to allow separate compilation;
but then, it seems to me that they are somewhat semantically klugy,
and that the whole concept of a global dynamic class hierarchy
is irreconciliable with separate compilation,
and also with seamless distribution of code in a wide network of nodes
(which is a problem of CLOS, too).

All that to say that the existence of a one weakly supported
(financially speaking) free software effort for Dylan
is not quite enough to have positive free software effects
play for the Dylan language in general.
And that Dylan also has technical problems that play against it.
So that indeed, I trust LISP (Common or not) to dominate over Dylan:
LISP benefits from a more deeply rooted community,
and its design has evolved by experience some technical adequacy
that Dylan's design can only try to achieve by guesswork;
plus Dylan dropped essential features of LISP.

> No, just somebody's remark this week that there's already a PD
> implementation, quite a good one, CMUCL, and there aren't enough
> people to maintain and port that one.
>
> Also, LW is not the most well-documented program.
>
Are you suggesting that people should forget about LW?
Well, certainly, if LW was such an inferior product,
that had absolutely original about it,
maybe it would be better that it be dropped dead,
and that everyone go CMUCL or such;
but frankly, I doubt it; LW has a good reputation, it does work on Windows,
it will have a hard time being more difficult to install than CMUCL,
and if it were inferior, no doubt you would have switched already.

> I think it might well be that what the community needs is not
> more code but more people.
>
I agree. Now, the way to build a community is to share code.
So the question is still to know what to do about the future:
would it be better for the community
to open the code and allow more sharing,
or to continue with a clustered community,
where groups of people reimplement things each in incompatible environments,
using incompatible extensions to the standard so as to access the system, etc?
I say it is always better to open code.
For _even_ if the Right Thing for the community was
that people converge on a one free implementation,
opening sources would help make the transition smoother
and the choosen free implementation better.

As I see things, standards for proprietary software are such
that every proprietary enhancement is an argument _against_ the standard,
whereas every lack of proprietary enhancement
is an argument against the considered vendor.
Hence, vendors compete in a negative-sum game, _against_ their common good,
to the detriment of their common standard,
whose market they fragment.

Standards for free software are such
that every free enhancement is an argument _for_ the standard,
whereas every lack of free enhancement
is still an argument against the considered vendor.
Hence, vendors compete in a positive-sum game, _for_ their common good,
to the advantage of their common standard,
whose market they strengthen.

Regards,

[ "Faré" | VN: Уng-Vû Bân | Join the TUNES project!   http://www.tunes.org/  ]
[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics  | Project for  a Free Reflective  Computing System ]
Plus on est savant, plus on est méta-ignorant. La Science étend plus encore
le champ de notre ignorance que celui de notre connaissance.