Re: Challenge for lisp lovers....

From: Marcin 'Qrczak' Kowalczyk (qrczak_at_knm.org.pl)
Date: 11/04/04 

Date: Thu, 04 Nov 2004 01:47:05 +0100

Gareth McCaughan <gareth.mccaughan@pobox.com> writes:

> If using bignums for file sizes were a win (which it's not clear
> that it would be)

It's clearly a win to be able to represent offsets larger than 2GB
on 32-bit machines. I assumed that a Lisp on a 32-bit machine would
represent all integers which don't fit in 32 bits (minus tag) as
bignums, instead of as unboxed 64-bit values like C, because it's
easier to pass to code which doesn't know types statically. OTOH in C
it's clearly better to use a fixed-size arithmetic type, as long as
its size suffices. So we have different representations to match.

I claim that the "low level, C specific" representation makes more
sense in an OS interface, because it is easier to adapt to whatever
representation of numbers a particular language implementation uses.
A representation better suited for Lisp would be better only if most
languages in the system used the same representation of numbers.
A more constraining implementation would have to be extremely well
engineered to pay off.

> It might, indeed, make life harder for users of other languages.
> That would, indeed, be a reason not to do it. But suppose you didn't
> care about any language other than Lisp;

Sorry, I do care about other languages. I don't believe that a desktop
computer system (i.e. with a wide spectrum of applications) which
promotes a single language at the cost of putting all other languages
at a disadvantage would survive (except perhaps if made by a firm as
strong as Microsoft). Lisp Machines were almost tied to a single
language and did not survive.

You could argue that Unix is tied to C. Well, many languages have
their runtimes implemented in C because C is so low level, because
it puts few constraints on data representation, memory management,
dynamic type system, implementation of threads, implementation of
exceptions - precisely because it does not provide its own. Thus these
runtimes are free to experiment with e.g. novel GC algorithms, and
they have a common language to talk to the OS.

If the OS or some common runtime provides something, it is an
advantage only as long as it's very flexible, adaptable to needs of
the whole spectrum of languages. IMHO .NET tries to provide a bit too
much. Microsoft doesn't care that languages have to be changed in
order to be ported to .NET, and that they will have trouble deciding
whether immutable UTF-16 strings with a particular choice of methods
is exactly what they want their string type to be mapped to, or a
custom class must be used which will make interoperability harder.
In C at least all languages have equal disadvantage :-)

Microsoft doesn't care about other languages. For standalone, compiled
applications, it really cares only about C# and Visual Basic, where C#
was designed to fit .NET, and VB has been changed to fit .NET. It can
afford to not care because it's big and rich, and can force enough
people to use languages it chooses for them.

Now you would want to do the same, but with Lisp in the place of C#.
Implementors of all other languages would have to stand on their heads
in order to fit them to the world tuned for Lisp. Sorry, it will not
work if you are not Microsoft :-)

> that's what the Lisp machines had, and there's every indication that
> it worked very nicely for them.

And they did not survive!

> It's not *that* bad for dynamic languages. There's an implementation
> of Python on top of the .NET virtual machine that runs appreciably
> faster than the implementation in C.

Because the C implementation of Python is *very* slow, even compared
implementations of Perl and Ruby. It could be faster. Guido must have
other priorities.

GC could be faster (it uses reference counting). Exceptions could be
faster (it uses explicit NULL check after each function). Ints could
be faster (hey, I just noticed that in December 2002 they finally
started allocating their 105 preallocated ints eagerly, rather than
lazily, thus saving a conditional on *every* return of a computed int).
Method invocation could be tried to be made faster (I don't know
where it spends most of the time, but I recall it has been reported
to be surprisingly slow). Common operations like arithmetic could be
specialized for types like ints, leaving the generic dispatch for
other cases.

Indeed, .NET is good if you don't try hard enough to beat it,
especially if you don't have resources to tune everything and at
the same time care for functionality. With .NET you don't have
much choice.

Maybe I'm wrong and since demands from the runtime are so big these
days (a good GC, threads, shared libraries, dynamic compilation etc.),
only big companies are able to implement them well, and thus advantages
of using a generic runtime are larger than disadvantages of being
forced to fit our language into a world designed for statically typed
OO languages with a particular standard library. Time will tell. 

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Relevant Pages

  • Re: Searching OO Associations with RDBMS Persistence Models
    ... need to care what the content is. ... Only the type-anal languages like Java need them, ... OO subtyping decomposition: ... But you claimed that nevertheless you have enough knowledge about shapes, ...
    (comp.object)
  • Re: Chinese Dialects
    ... Why do you need to care about these ... All languages have a tendency to leave out ... Obvious examples, but not colorful. ... "You are here to learn the mysteries of Kung Fu, not linguistics. ...
    (sci.lang)
  • Re: What gives you power in CL, that you dont have in other languages
    ... take care of not caring about values you do not care - this simply beats ... Even if tuples in and of themselves are nice in these languages, ... Look at Haskell. ... to collapse the million precedence levels. ...
    (comp.lang.lisp)
  • Re: python3: where keyword
    ... >> macros could take care of it. ... > languages, and mental gymnastics would probably do me good, but I ...
    (comp.lang.python)
  • Re: How come Ada isnt more popular?
    ... then But non contigous representation of arrays will really stress ... It's easy with value-oriented languages (i.e. languages ... use references because of that. ... The example you mentioned was a tree. ...
    (comp.lang.ada)
Loading