Re: What would you do with 10 Man Years?

nikodemus_at_random-state.net
Date: 03/27/04 

Date: 27 Mar 2004 11:34:04 GMT

From: nikodemus@random-state.net
Subject: Re: What would you do with 10 Man Years?
Newsgroups: comp.lang.lisp
References: <c3v7k0$2a6062$1@ID-197644.news.uni-berlin.de> <m2vfkrhlxq.fsf@david-steuber.com> <c41eu0$5qpln$1@midnight.cs.hut.fi> <m23c7vglfa.fsf@david-steuber.com>
Organization:

David Steuber <david.steuber@verizon.net> wrote:

> Another challenge for libraries is making them portable across CL
> implimentations. I've got CLISP, CMUCL, OpenMCL, and SBCL installed

I disagree strongly.

 [I'm reading your meaning here as "libraries should be portable
  or they're worthless" -- that may have not been what you ment,
  but I won't let that stand in between me and rant.]

"It's got to be portable" is just another paralyzing factor. Most
library authors are not writing their stuff from the goodness of
their heart, but because they want it for themselves. From their
POV clamoring for portability is a message that "nah, it's no
use publishing this as it works only on <implementation-x>".

Add to this that more often than not portability issues fall into
one of the following categories:

 * Implementation shortcomings. Eg. bugs in esoteric features,
   or incomplete MOP.

 * Implementation specific extensions. Most commonly sockets
   and FFI.

If library X doesn't work on your implementation because of
either of these, then in the first case I'd be moderately
surprised if the implementors of your lisp weren't happy to hear
about the first case -- and even fix it, given code in the wild
that actually uses it. In the second case given an implementation
with "normal" support for sockets and FFI it's not generally too
hard to either patch the library to support UFFI or write an
abstraction layer over the used functionality with a backend
per supported implementation.

It's somewhat silly to assume that the original author would do
all this, especially when he is primarily writing code for his/her
own use. Sometimes, some people, the extra mile is taken, but even
suggesting that there is some sort of moral imperative for library
authors to do that is questionable at best.

A rarer case is having an implementation specific extension (like
foreign callbacks or good xref) that isn't yet widely supported --
in which case a portable implementation would originally have
required ugly workarounds or have been impossible. But if you want
to port it, and your implementation doesn't support this
newfangled feature you can/should:

 * Given a commercial implementation talk to your vendor about
   the extension.

 * Given an open source implementation either add the extension
   yourself and submit the patch, hire a developer to do it
   for you, or raise the subject on the right mailing list
   and hope that someone does it for you.

The one single this that has a really bad track record of
achieving anything is whining on cll. ;-)

Cheers,

 -- Nikodemus

Relevant Pages

  • Re: learning asm.
    ... No need to apologise...I'm so all over the place myself with posts ... problem...such libraries are monsterous and lead to _more complex_ ... "portability" actually isn't needed or a desirable attribute then this ... loader-time to make, I suppose, a "custom jump table" for that program ...
    (alt.lang.asm)
  • Re: <ctype.h> toLower()
    ... I think you are confusing portability with binary compatibility. ... to be CPU specific. ... compiler and thencan specify the machine type. ... >> Object libraries are definately platform specific. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Need help on modifying and assembly of a small program!
    ... care for "international support" at the moment...BUT will you care _LATER_? ... make your keyboard driver use "keymaps" or something (which simply ... that there's a kind of "standard" for typing English with their Cyrillic ... This is the "portability" of the OS source ...
    (alt.lang.asm)
  • Re: "The Good Enough Revolution" - As it applies to js
    ... VB programs must be re-written because the current libraries don't ... I don't think MS needs to be singled out for poor support of web ... unknown browsers and until its adoption of feature testing, jQuery was ... All that needs to be anticipated is that a browser may not support any ...
    (comp.lang.javascript)
  • Re: Embedding assembler in a language
    ... operating system features without being tied too close to a certain ... standard without completely sacrificing portability. ... Currently there is no support for such things. ...
    (comp.lang.misc)