From: André Thieme
Subject: Popularity of programming languages
Date:
Message-ID: <c1jb3g$f8v$1@ulric.tng.de>
How does the popularity of a programming language affect this language?
Wouldn't Lisp become even more usefull (more libs) if it had more users?
This website tries to measure the popularity of some programming languages:
http://www.tiobe.com/tpci.htm
Andr�
"Andr� Thieme" <······································@justmail.de> wrote in
message ·················@ulric.tng.de...
> How does the popularity of a programming language affect this language?
> Wouldn't Lisp become even more usefull (more libs) if it had more users?
No. It would simply be more popular.
Case in point. We have an internal language for our application. It has 3
users. We find it eminently useful. It's more useful than Java in its
domain.
So, you can plug that into your spreadsheet and churn on it for a bit.
"Logic is a wreath of pretty flowers that smell bad..."
But thanx for playing!
Regards,
Will Hartung
(·····@msoft.com)
From: André Thieme
Subject: Re: Popularity of programming languages
Date:
Message-ID: <c1je9n$hck$1@ulric.tng.de>
Will Hartung wrote:
> Case in point. We have an internal language for our application. It has 3
> users. We find it eminently useful. It's more useful than Java in its
> domain.
My point is not if a language has to be popular to be usefull. I would
like to know if a language would become more usefull if it had more
users who possible could write libs for it and buy Lisp based products,
like IDEs etc.
Andr�
On Thu, 26 Feb 2004 01:24:30 +0100, Andr� Thieme wrote:
> I would
> like to know if a language would become more usefull if it had more
> users who possible could write libs for it and buy Lisp based products,
> like IDEs etc.
Is this a useful question? Usefulness is in the eye of the beholder.
Yes, there might be more quantity of random stuff associated with the
language if it would become more popular, but most of it would not be
useful to me. Would the quality of the stuff be very high, if J. Random
Luser were out there writing libraries? Or would I just have twenty
different XML parsers, fifteen of which sucked, that I'd have to wade
through instead of the three or four relatively good choices I have
now? No, I don't think that usefulness would be be incredibly enhanced if
the language was more popular. Popularity is usually detrimental to both
quality and usefulness, simply because of the noise generated and the
requirement to write to the lowest common denominator needed to become
popular.
faa
In article <············@ulric.tng.de>,
Andr� Thieme <······································@justmail.de> wrote:
>Will Hartung wrote:
>
>> Case in point. We have an internal language for our application. It has 3
>> users. We find it eminently useful. It's more useful than Java in its
>> domain.
>
>My point is not if a language has to be popular to be usefull. I would
>like to know if a language would become more usefull if it had more
>users who possible could write libs for it and buy Lisp based products,
>like IDEs etc.
I don't believe the number of users has anything to do with how many
libraries there are for a language. This is a "big lie" which is peddled
to newbies like me around here to excuse the tragic lack of useful
libraries for Common Lisp. I am becoming more and more certain that the
lack of libraries for Common Lisp is a sort of inherent character flaw in
the way the language handles libraries. Libraries in Common Lisp are an
awful mess. Building them, loading them; it all sucks giant swinging
donkey balls.
There is also the matter that a lot of the things that are trivial and
necessary to do (and in a standard way) in every other language are
nonstandard in ANSI Common Lisp (FFI, IPC, GUI, networking, blah blah
blah), and so the wheel needs to be reinvented many, many times. For an
example, look at the source code for SLIME for different Lisp
implementations. This forces the libraries and code which *are* built to
be, well, different and possibly broken across Lisps.
As a counter-case in point, I direct everyone's attention to Lush. Lush is
a fairly limited, fairly antiquated pre-Common-Lisp form of interpreted
Lisp. For the last 20 years, it has basically had two users; the guys who
wrote it. It has more useful libraries already linked to it than exists
online for all of Common Lisp, as far as I can tell. Mostly because it has
an excellent and useful FFI for calling C code, and two users who use it
a lot for serious problems. It's also quite cute from a "hackability"
standpoint, and implements many of Paul Graham's ideas for a popular Lisp.
If it had a garbage collector for the compiler, I'd never even think of
using ACL. There would be no point, other than a few useful special forms
I would have to reimplement. It's not like ACL has a lot of useful
libraries I'd be jealous of.
-Lupo
"You are not a beautiful and unique snowflake. You are the same decaying
organic matter as everything else. We are all part of the same compost heap."
<··@io.com>
··@io.com (Lupo LeBoucher) writes:
> In article <············@ulric.tng.de>,
> André Thieme <······································@justmail.de> wrote:
>>Will Hartung wrote:
>>My point is not if a language has to be popular to be usefull. I would
>>like to know if a language would become more usefull if it had more
>>users who possible could write libs for it and buy Lisp based products,
>>like IDEs etc.
>
> I don't believe the number of users has anything to do with how many
> libraries there are for a language.
This is trivially false in the limits of zero and infinity, but as a
premise for the intermediate values we can go with it, for the sake of
argument.
> This is a "big lie" which is peddled to newbies like me around here
> to excuse the tragic lack of useful libraries for Common Lisp.
Who peddles this lie? And, while we're at it, please don't peddle the
lie that there are no useful libraries for Common Lisp.
> I am becoming more and more certain that the lack of libraries for
> Common Lisp is a sort of inherent character flaw in the way the
> language handles libraries. Libraries in Common Lisp are an awful
> mess. Building them, loading them; it all sucks giant swinging
> donkey balls.
You know, this wasn't true in December, when this came up last, and
it's not true now either.
> There is also the matter that a lot of the things that are trivial and
> necessary to do (and in a standard way) in every other language are
> nonstandard in ANSI Common Lisp (FFI, IPC, GUI, networking, blah blah
> blah),
You are joking, right? I can't begin to express just how utterly
wrong this is. Indulging in selective myopia isn't really a great
rhetorical technique.
> and so the wheel needs to be reinvented many, many times. For an
> example, look at the source code for SLIME for different Lisp
> implementations. This forces the libraries and code which *are* built to
> be, well, different and possibly broken across Lisps.
It is true that programs, libraries and whatnot written in Common Lisp
are not necessarily portable programs. I fail to see that there is
any significant difference here between Common Lisp per se and any
other programming language. There are two separate plausible
counterarguments to this: (a) C; (b) everything else.
Let's take C first. From your extolling of Lush, I'm going to guess
that when you talk about standards, you really mean portability
between various Unixes. Fine, there's nothing wrong with that; it's
just worth bearing in mind that that's not what everyone calls
"standard". The thing that disguises the non-portability of C
programs on Unix is the effective gcc monoculture. To a zeroth-order
approximation, all the world (on Unix) is gcc. The first-order
approximation is that all the world (on Unix) is compatible with gcc,
because vendors are conscious of the zeroth-order. However, there are
sufficiently different implementations of C, even on Unix today, which
expose so-called portability of typical C programs as a myth. Try
it. You may be surprised.
As for "everything else", which in practice means the scripting
language of today, and yesterday's, and last year... well. "Standard"
is one thing these guys aren't; their expected functionality is
defined by their implementation (and their desired functionality by
their documentation ;-). Consequently, programs written for a given
version of one of these have no guarantee of any kind that they will
continue to run when the language is "upgraded" to a later version.
The canonical example of this is the transition from Perl 5.004 to
Perl 5.005, but there are plenty of other pitfalls. As for the notion
that there is "standard" IPC, GUI, TLA in any of these, well, the
further away the flag flies from Linux, the more it seems to droop.
> As a counter-case in point, I direct everyone's attention to Lush. Lush is
> a fairly limited, fairly antiquated pre-Common-Lisp form of interpreted
> Lisp. For the last 20 years, it has basically had two users; the guys who
> wrote it. It has more useful libraries already linked to it than exists
> online for all of Common Lisp, as far as I can tell.
You are aware of CLiki, right? One useful place to look at before
making such comments is <http://www.cliki.net/asdf-install>. That
list does not by any means contain all available libraries that are
easy to install; other lists can be generated by running "apt-cache
search ^cl-" on a Debian system, or searching the Gentoo distribution
for lisp packages.
> Mostly because it has an excellent and useful FFI for calling C
> code, and two users who use it a lot for serious problems.
Right. I suspect the second factor as being rather more important
than the first, mostly because all Lisp implementations have useful
FFIs for calling C code.
> It's also quite cute from a "hackability" standpoint, and implements
> many of Paul Graham's ideas for a popular Lisp. If it had a garbage
> collector for the compiler, I'd never even think of using ACL. There
> would be no point, other than a few useful special forms I would
> have to reimplement. It's not like ACL has a lot of useful libraries
> I'd be jealous of.
How about the ability to run on MacOS X? Is that a library? What
about Windows native bindings? Is that important? 20 years and no
garbage collector? That doesn't sound like an active project. I
could go on, but I don't need to; I don't think that the lack of
MacOS or Windows functionality is a great disaster, but I do think
that you have made choices that bias your views on various matters,
and I think that you should be called on it.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> ··@io.com (Lupo LeBoucher) writes:
>
>> In article <············@ulric.tng.de>,
>> Andr� Thieme <······································@justmail.de> wrote:
>>>Will Hartung wrote:
>>>My point is not if a language has to be popular to be usefull. I would
>>>like to know if a language would become more usefull if it had more
>>>users who possible could write libs for it and buy Lisp based products,
>>>like IDEs etc.
>>
>> I don't believe the number of users has anything to do with how many
>> libraries there are for a language.
>
> This is trivially false in the limits of zero and infinity, but as a
> premise for the intermediate values we can go with it, for the sake of
> argument.
>
No, it is not. If the language can use libraries written in another language
it might have lots of support libs without any users. One of the reasons for the
"success" of C++ is the ease with which it interoperates with existing c libraries.
C++ programmes don't use a ffi to call a c function. They link in a library.
The infinite case does strange things to my brain.
Immanuel
From: Christopher C. Stacy
Subject: Re: Popularity of programming languages
Date:
Message-ID: <uu11ck0qu.fsf@news.dtpq.com>
>>>>> On Fri, 27 Feb 2004 13:46:28 +0100, Immanuel Litzroth ("Immanuel") writes:
Immanuel> Christophe Rhodes <·····@cam.ac.uk> writes:
>> ··@io.com (Lupo LeBoucher) writes:
>>
>>> In article <············@ulric.tng.de>,
>>> Andr� Thieme <······································@justmail.de> wrote:
>>>> Will Hartung wrote:
>>>> My point is not if a language has to be popular to be usefull. I would
>>>> like to know if a language would become more usefull if it had more
>>>> users who possible could write libs for it and buy Lisp based products,
>>>> like IDEs etc.
>>>
>>> I don't believe the number of users has anything to do with how many
>>> libraries there are for a language.
>>
>> This is trivially false in the limits of zero and infinity, but as a
>> premise for the intermediate values we can go with it, for the sake of
>> argument.
>>
Immanuel> No, it is not. If the language can use libraries written in
Immanuel> another language it might have lots of support libs without
Immanuel> any users. One of the reasons for the "success" of C++ is
Immanuel> the ease with which it interoperates with existing c
Immanuel> libraries. C++ programmes don't use a ffi to call a c
Immanuel> function. They link in a library.
I think perhaps you misunderstand what this "FFI" stuff is about.
Lisp links with and calls C/C++ libraries in a manner very similar
to what is done for Perl or JAVA (or PASCAL or any other language
that is "foreign" to C) when they want to "bind" to a C library.
A Lisp "FFI call" is just written as a normal Lisp function call.
The "FFI" business corresponds to translating the header file or
writing the library bindings (or whatever) in those other languages.
Just as in those other languages, the Lisp binding ("FFI") may also
have to do some data type translation or memory management.
In the Lisp Machine system from 15 years ago, all the FFI binding
code could be generated automatically from the C header (".h") files.
I think the current state of the art is again close to that, but I
don't use foreign code that much and haven't been following it
If you're complaint is just that all other programming languages
are not source and bit-compatible with C, well, sorry!
Have fun over there in C!
On Fri, 27 Feb 2004 15:20:26 +0000, Christopher C. Stacy wrote:
> In the Lisp Machine system from 15 years ago, all the FFI binding
> code could be generated automatically from the C header (".h") files.
C header files don't contain enough information to generate good bindings
to other languages from them, without additional interface description.
For example an argument of type pointer to foo can mean an input or output
parameter or an array. When a pointer is returned it's not specified who
is responsible for freeing that object and how to do it (or maybe it's
statically allocated, or it points to a subobject of arguments, etc.).
The generated bindings would be quite low-level, manipulating pointers to
explicitly allocated objects rather than objects.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote in message news:<······························@knm.org.pl>...
> On Fri, 27 Feb 2004 15:20:26 +0000, Christopher C. Stacy wrote:
>
> > In the Lisp Machine system from 15 years ago, all the FFI binding
> > code could be generated automatically from the C header (".h") files.
>
> C header files don't contain enough information to generate good bindings
> to other languages from them, without additional interface description.
>
> For example an argument of type pointer to foo can mean an input or output
> parameter or an array. When a pointer is returned it's not specified who
> is responsible for freeing that object and how to do it (or maybe it's
> statically allocated, or it points to a subobject of arguments, etc.).
>
> The generated bindings would be quite low-level, manipulating pointers to
> explicitly allocated objects rather than objects.
That would still be extraordinary more convenient to have
- Automatic low-level interfacing through parsing of C header files,
that would treat almost anything as foreign, and not try to do any
type of conversion whatsoever.
- A declarative syntax to enrich that low-level interface into
something more high level .. if desired ..
Than having to cope with the manual generation of *highly redundant*
information in the form of an implementation dependent ffi
description.
Anybody got cparse around for download? ;)
From: Christopher C. Stacy
Subject: Re: Popularity of programming languages
Date:
Message-ID: <uznb3ovl2.fsf@news.dtpq.com>
>>>>> On Sat, 28 Feb 2004 12:40:21 +0100, Marcin 'Qrczak' Kowalczyk ("Marcin") writes:
Marcin> C header files don't contain enough information to generate
Marcin> good bindings to other languages from them, without
Marcin> additional interface description.
The LispM, of course, didn't have any "foreign" functions, since
all the compilers (Lisp, Fortran, C, ADA, Pascal, Prolog, etc.) all
generated native machine code with compatible (and latent) data types.
But what I was thinking of were the function calls back and forth over
the network to C programs on non-LispM machines. I had forgotten that
these "foreign" calls were not arbitrary C programs, but were rather
RPC/XDR programs. This facility was mostly used in the embedded Lisp
Machine (a full Lisp Machine system on a plug-in board inside a
Macintosh or Sun workstation), for communicating with the host.
The additional necessary annotations were given in a syntax
very similar to how FFI code is written today.
For example, there was the RPC:DEFINE-REMOTE-ENTRY macro,
similar to today's the FLI:DEFINE-FOREIGN-FUNCTION in Xanalys.
What it generated was your RPC stub on the Lisp side.
This was a DEFUN-like form where you would specify the Lisp
function name, the remote function module and entry name,
and the arguments (including polarity and data type).
Since storage was not being shared across the function calls
there were no GC issues. You could also include in the
definition any Lisp code to perform additional processing
that you might want. There were also macros for defining
foreign (RPC) types beyond all the basic ones supplied.
The part about C source code that I was mis-remembering was that
the system could also write the foreign RPC stub for you, in C.
So this code:
----------
(RPC:DEFINE-REMOTE-MODULE PLIST-SERVER (:NUMBER #x7F008002) (:VERSION 1)
(:CLIENT :C) (:SERVER :LISP))
(RPC:DEFINE-REMOTE-ENTRY RETRIEVE-PROPERTY-LIST PLIST-SERVER (:NUMBER 1)
(:ARGUMENTS (SYMBOL RPC:PASCAL-STRING))
(:VALUES (PLIST (VECTOR (STRUCTURE
(INDICATOR RPC:C-STRING)
(PROPERTY RPC:C-STRING)))))
(:LISP
(:SERVER
(WITH-STANDARD-IO-ENVIRONMENT
(LET* ((*PACKAGE* (FIND-PACKAGE "COMMON-LISP-USER"))
(*PRINT-ARRAY* NIL)
(*PRINT-STRUCTURE-CONTENTS* NIL)
(*PRINT-READABLY* NIL)
(PLIST (SYMBOL-PLIST (READ-FROM-STRING SYMBOL)))
(RESULT (MAKE-ARRAY (/ (LENGTH PLIST) 2))))
(LOOP FOR (INDICATOR PROPERTY) ON PLIST BY 'CDDR
FOR INDEX FROM 0 DO
(SETF (AREF RESULT INDEX) (VECTOR (PRIN1-TO-STRING INDICATOR)
(PRIN1-TO-STRING PROPERTY))))
(RPC:RPC-VALUES RESULT))))))
(RPC:DEFINE-REMOTE-C-PROGRAM PLIST-SERVER
(:CLIENT (:FILE "plist-server")
(:INCLUDE "RPC.h")))
----------
Would create the Lisp end of things, and it would also output
the file "plist-server.c", which looked like this:
----------
/* Client stubs portion of PLIST-SERVER remote module version 1
Generated from SAP:>sys>embedding>rpc>examples>plist-server.lisp.5
by CStacy on Thursday the twenty-ninth of November, 1990; 11:58:38 pm */
#include "RPC.h"
typedef struct
{ long length;
struct
{ unsigned char * indicator;
unsigned char * property;
}
element[STRUCT_POINTER_SIZE];
}
* structure_vector;
{ long length_tem_1, length_tem_2, length_tem_3, idx_tem_1;
XDRAgent XDR_Agent;
XDRBlock XDR_Block;
long * TheXDRPointer;
register long * XDRPointer;
long * XDRLimit;
OSErr system_error_code;
system_error_code = RPCInitiateCall((long)0x7F008002,
(long)1, (long)1,
(long)((long)(symbol[0] + 7) >> 2),
&XDR_Agent, &XDR_Block,
&TheXDRPointer,
&XDRLimit);
if(system_error_code)return(system_error_code);
XDRPointer = TheXDRPointer;
*(XDRPointer++) = symbol[0];
CopyMemory((void *)&symbol[1], (void *)XDRPointer,
(long)symbol[0]);
XDRPointer += (symbol[0] + 3) >> 2;
XDRVerifyPointer(XDRPointer, XDRLimit);
system_error_code = RPCSendCallAndWait(XDR_Agent,
&XDR_Block);
if(system_error_code)return(system_error_code);
system_error_code = XDRInitiateReceive(XDR_Agent,
XDR_Block,
&TheXDRPointer,
&XDRLimit);
if(system_error_code)return(system_error_code);
XDRPointer = TheXDRPointer;
length_tem_1 = *(XDRPointer++);
system_error_code = AllocateMemory((long)(length_tem_1 * sizeof((*ret_plist)->element[idx_tem_1])*4),
(void * *)&(*ret_plist));
if(system_error_code)return(system_error_code);
(*ret_plist)->length = length_tem_1;
for(idx_tem_1 = 0;
idx_tem_1 < length_tem_1;
idx_tem_1++)
{ length_tem_2 = *(XDRPointer++);
system_error_code = AllocateMemory(length_tem_2 + 1,
(void * *)&(*ret_plist)->element[idx_tem_1].indicator);
if(system_error_code)return(system_error_code);
CopyMemory((void *)XDRPointer, (void *)(*ret_plist)->element[idx_tem_1].indicator,
(long)length_tem_2);
XDRPointer += (length_tem_2 + 3) >> 2;
((*ret_plist)->element[idx_tem_1].indicator)[length_tem_2] = 0;
length_tem_3 = *(XDRPointer++);
system_error_code = AllocateMemory(length_tem_3 + 1,
(void * *)&(*ret_plist)->element[idx_tem_1].property);
if(system_error_code)return(system_error_code);
CopyMemory((void *)XDRPointer, (void *)(*ret_plist)->element[idx_tem_1].property,
(long)length_tem_3);
XDRPointer += (length_tem_3 + 3) >> 2;
((*ret_plist)->element[idx_tem_1].property)[length_tem_3] = 0;
};
XDRVerifyPointer(XDRPointer, XDRLimit);
XDRReleaseBlock(XDR_Agent, XDR_Block);
return(noErr);
}
----------
If you needed to, RPC:DEFINE-REMOTE-ENTRY would also let you
include any additional C processing/glue code that you wanted,
using the C reader syntax:
----------
(RPC:DEFINE-REMOTE-ENTRY READ-FILE-NAME EXAMPLE (:NUMBER 1)
(:ARGUMENTS (WHERE POINT)
(FILE-TYPES FILE-TYPES))
(:VALUES (CONFIRMED RPC:BOOLEAN)
(VOLUME RPC:INTEGER-16)
(FILE-NAME RPC:PASCAL-STRING)
(FILE-TYPE FILE-TYPE))
;; Put the list of file types into the form required by SFGetFile
;; and extract the values from the SFReply structure
(:C
(:SERVER
#{ SFReply reply;
int numTypes;
if ( file_types.type == all_type )
numTypes = -1;
else numTypes = file_types.value.vector->length;
SFGetFile(where, "\p", NULL, numTypes, &file_types.value.vector->element[0],
NULL, &reply);
RPCValues(reply.good, reply.vRefNum, reply.fName, reply.fType);
})))
(RPC:DEFINE-REMOTE-C-PROGRAM EXAMPLE
(:SERVER
(:FILE "example.c")
(:TYPE :AUTO-LOAD)
(:INCLUDE "<MacTypes.h>" "<FileMgr.h>" "<StdFilePkg.h>")))
----------
So it was not very different from FFI,
and not as automatic as I had thought.
There were some higher level tools with the RPC feature
but I didn't use them and don't remember exactly what they did.
(Or even if they were released as products.)
Glancing around at some old files, I can see one such feature.
First some background. On an embedded system, the Lisp Machine was
essentially a stand-alone system that just happened to be in the same
chasis as the host machine (eg. a Macintosh). The LispM would talk to
the host to coordinate getting some low-level IO services off the host's
bus and devices, but they didn't share memory or anything. To use the
LispM, you fired up a Mac application (or on Unix, an X program) that
would bring up a window wherein you could access the LispM. (In other
words, a remote session, just like using one of your Unix machines as
an X server to access the other Unix system where you are doing your work.
Symbolics Open Genera, by the way, is such an embedded system, except
that there's no board - it's all software!) By contrast, all this RPC
foreign function calling stuff I've been talking about was for programs
on the two systems to call each other.
So here's one example. You could write Lisp code that would implement
a GUI on the Macintosh that would transparently use RPC calls over to
the Lisp Machine. You did this using a fancy macro that's a variation
on the DEFINE-PROGRAM-FRAMEWORK (for those of you familiar with CLIM).
It was called DEFINE-REMOTE-PROGRAM-FRAMEWORK.
There were some other utilities for automatically generating things
based on C source files, but I don't remember them. I am sure that
the other stuff was aided by the fact that the Lisp Machine included
an ANSI C compiler. But the stuff show above did not need or use that.
I wonder how all this old technology compares to the facilities
available in Java's RMI and to CORBA, and Lisp's support for those.
>>>>> "cs" == Christopher C Stacy <······@news.dtpq.com> writes:
cs> What it generated was your RPC stub on the Lisp side.
cs> This was a DEFUN-like form where you would specify the Lisp
cs> function name, the remote function module and entry name,
cs> and the arguments (including polarity and data type).
cs> Since storage was not being shared across the function calls
cs> there were no GC issues. You could also include in the
cs> definition any Lisp code to perform additional processing
cs> that you might want. There were also macros for defining
cs> foreign (RPC) types beyond all the basic ones supplied.
interesting, thanks for posting about this.
cs> I wonder how all this old technology compares to the facilities
cs> available in Java's RMI and to CORBA, and Lisp's support for those.
I see a number of similarities:
- generation of stub code from an interface description: in CORBA
interfaces are described in the OMG Interface Description
Language, and the way that the different IDL data types map to
various programming languages is specified by the standard.
- automatic marshalling of data types: I see from your example that
there are data types named RPC:C-STRING and RPC:PASCAL-STRING; I
guess that the LispM converted lisp strings to these formats
automatically.
There are also a few differences, where RPC mechanisms are less
powerful than more modern middleware mechanisms:
- the programming model in CORBA (and Java RMI) is based on method
invocations on objects rather than procedure calls between
processes; there is a late binding mechanism.
- CORBA provides strong location transparency: invocations on a
remote object are syntactically identical to those on a local
object, and there are well defined mechanisms for obtaining object
references without referring to network addresss in the
application code. I guess the syntax aspects were easy to deal
with in the Lisp Machine environment, but I believe that service
lookup mechanisms in SunRPC are relatively weak.
The CORBA specifications also address many (too many!) aspects as well
as remote method invocations, but I won't go into that.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
······@news.dtpq.com (Christopher C. Stacy) writes:
>>>>>> On Fri, 27 Feb 2004 13:46:28 +0100, Immanuel Litzroth ("Immanuel") writes:
>
> Immanuel> Christophe Rhodes <·····@cam.ac.uk> writes:
> >> ··@io.com (Lupo LeBoucher) writes:
> >>
> >>> In article <············@ulric.tng.de>,
> >>> Andr� Thieme <······································@justmail.de> wrote:
> >>>> Will Hartung wrote:
> >>>> My point is not if a language has to be popular to be usefull. I would
> >>>> like to know if a language would become more usefull if it had more
> >>>> users who possible could write libs for it and buy Lisp based products,
> >>>> like IDEs etc.
> >>>
> >>> I don't believe the number of users has anything to do with how many
> >>> libraries there are for a language.
> >>
> >> This is trivially false in the limits of zero and infinity, but as a
> >> premise for the intermediate values we can go with it, for the sake of
> >> argument.
> >>
>
> Immanuel> No, it is not. If the language can use libraries written in
> Immanuel> another language it might have lots of support libs without
> Immanuel> any users. One of the reasons for the "success" of C++ is
> Immanuel> the ease with which it interoperates with existing c
> Immanuel> libraries. C++ programmes don't use a ffi to call a c
> Immanuel> function. They link in a library.
>
> I think perhaps you misunderstand what this "FFI" stuff is about.
> Lisp links with and calls C/C++ libraries in a manner very similar
> to what is done for Perl or JAVA (or PASCAL or any other language
> that is "foreign" to C) when they want to "bind" to a C library.
> A Lisp "FFI call" is just written as a normal Lisp function call.
> The "FFI" business corresponds to translating the header file or
> writing the library bindings (or whatever) in those other languages.
> Just as in those other languages, the Lisp binding ("FFI") may also
> have to do some data type translation or memory management.
>
I did not misunderstand and have written ffi for haskell, cmucl, mzscheme.
My point is that c++ does not have anything like a ffi, because the underlying
programming model is close enough to c to use c libraries transparently (give or
take an extern "C" line).
The post I was answering to was the trivially false for zero and infinity... which
I thought was wrong.
Immanuel
Immanuel Litzroth <·········@enfocus.be> writes:
> I did not misunderstand and have written ffi for haskell, cmucl,
> mzscheme. My point is that c++ does not have anything like a ffi,
> because the underlying programming model is close enough to c to use
> c libraries transparently (give or take an extern "C" line).
This is just a difference in degree from what you would have
to do in Lisp.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Immanuel Litzroth <·········@enfocus.be> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> ··@io.com (Lupo LeBoucher) writes:
>>
>>> I don't believe the number of users has anything to do with how many
>>> libraries there are for a language.
>>
>> This is trivially false in the limits of zero and infinity, but as a
>> premise for the intermediate values we can go with it, for the sake of
>> argument.
>>
> No, it is not. If the language can use libraries written in another language
> it might have lots of support libs without any users. One of the reasons for the
> "success" of C++ is the ease with which it interoperates with existing c libraries.
> C++ programmes don't use a ffi to call a c function. They link in a
> library.
And that counts, does it? They just "link in a library"; there's no
thought involved in writing a good language binding, which is
idiomatic to users of the higher-level language, and interoperates
well with other features of that language (C++ classes, to take your
example). They don't deal with API mismatches (say references vs
pointers, again for C++). It's just as simple as calling a C
function.
Well, if that's what you think is involved in having support
libraries, then, well, assuming it takes zero users to write the
trivial bindings, then, well, yes, you can have "lots of support libs
without any users".
> The infinite case does strange things to my brain.
Well, I'm halfway there, then.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
You are making a mistake that seems to be very common. You compare a
language implementation (Lush) with a language standard (Common Lisp).
That's like comparing an apple with an orange tree.
If Slime were implemented for a single Common Lisp implementation,
things would be much easier. It's your choice to either try to achieve
portability across many CL implementations in your own code, or else
treat one specific CL implementation effectively as a single-vendor
language, including all the additional stuff that comes with it.
The Common Lisp standard addresses issues that vendors of other
languages don't even think of.
Pascal
Lupo LeBoucher wrote:
> In article <············@ulric.tng.de>,
> Andr� Thieme <······································@justmail.de> wrote:
>
>>Will Hartung wrote:
>>
>>
>>>Case in point. We have an internal language for our application. It has 3
>>>users. We find it eminently useful. It's more useful than Java in its
>>>domain.
>>
>>My point is not if a language has to be popular to be usefull. I would
>>like to know if a language would become more usefull if it had more
>>users who possible could write libs for it and buy Lisp based products,
>>like IDEs etc.
>
>
> I don't believe the number of users has anything to do with how many
> libraries there are for a language. This is a "big lie" which is peddled
> to newbies like me around here to excuse the tragic lack of useful
> libraries for Common Lisp. I am becoming more and more certain that the
> lack of libraries for Common Lisp is a sort of inherent character flaw in
> the way the language handles libraries. Libraries in Common Lisp are an
> awful mess. Building them, loading them; it all sucks giant swinging
> donkey balls.
>
> There is also the matter that a lot of the things that are trivial and
> necessary to do (and in a standard way) in every other language are
> nonstandard in ANSI Common Lisp (FFI, IPC, GUI, networking, blah blah
> blah), and so the wheel needs to be reinvented many, many times. For an
> example, look at the source code for SLIME for different Lisp
> implementations. This forces the libraries and code which *are* built to
> be, well, different and possibly broken across Lisps.
>
> As a counter-case in point, I direct everyone's attention to Lush. Lush is
> a fairly limited, fairly antiquated pre-Common-Lisp form of interpreted
> Lisp. For the last 20 years, it has basically had two users; the guys who
> wrote it. It has more useful libraries already linked to it than exists
> online for all of Common Lisp, as far as I can tell. Mostly because it has
> an excellent and useful FFI for calling C code, and two users who use it
> a lot for serious problems. It's also quite cute from a "hackability"
> standpoint, and implements many of Paul Graham's ideas for a popular Lisp.
> If it had a garbage collector for the compiler, I'd never even think of
> using ACL. There would be no point, other than a few useful special forms
> I would have to reimplement. It's not like ACL has a lot of useful
> libraries I'd be jealous of.
>
> -Lupo
> "You are not a beautiful and unique snowflake. You are the same decaying
> organic matter as everything else. We are all part of the same compost heap."
> <··@io.com>
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza wrote:
> You are making a mistake that seems to be very common. You compare a
> language implementation (Lush) with a language standard (Common
> Lisp). That's like comparing an apple with an orange tree.
I don't see the mistake. If CL is a useful standard, there should be
lots of useful libraries written in pure CL by now. Lupo points out that
one non CL implementation with a user community in the single digits
seems to have more libraries than the entire CL community.
> If Slime were implemented for a single Common Lisp implementation,
> things would be much easier. It's your choice to either try to
> achieve portability across many CL implementations in your own code,
> or else treat one specific CL implementation effectively as a
> single-vendor language, including all the additional stuff that comes
> with it.
It is difficult to interpret the above in any other way than that the CL
standard simply doesn't provide what writers of portable code need.
It's great to try to sweep the problem under the rug by labelling such
fundamentals as TCP/IP as "additional stuff".
I do think there's a bit of a "big lie" peddled to newcomers, to wit:
- Lisp is a rich language with a standard
- There are a number of conforming implementations
- Scheme, being minimalist, lacks a lot
The clear implication, sometimes voiced, other times not, is that you
can write useful, portable CL code, whereas with Scheme, you'll have to
write lots of your own scaffolding, or go outside the standard and use
implementation specific additional stuff.
> The Common Lisp standard addresses issues that vendors of other
> languages don't even think of.
The Scheme community seems to have developed an ongoing, informal
standards process (SRFIs) to cover issues not addressed in their formal
standards (RnRS). The only similar thing I've seen in Lisp is ACL-COMPAT.
> Lupo LeBoucher wrote:
...
>> I don't believe the number of users has anything to do with how
>> many libraries there are for a language. This is a "big lie" which
>> is peddled to newbies like me around here to excuse the tragic lack
>> of useful libraries for Common Lisp. I am becoming more and more
>> certain that the lack of libraries for Common Lisp is a sort of
>> inherent character flaw in the way the language handles libraries.
>> Libraries in Common Lisp are an awful mess. Building them, loading
>> them; it all sucks giant swinging donkey balls. There is also the
>> matter that a lot of the things that are trivial and necessary to
>> do (and in a standard way) in every other language are nonstandard
>> in ANSI Common Lisp (FFI, IPC, GUI, networking, blah blah blah),
>> and so the wheel needs to be reinvented many, many times. For an
>> example, look at the source code for SLIME for different Lisp
>> implementations. This forces the libraries and code which *are*
>> built to be, well, different and possibly broken across Lisps.
>>
>> As a counter-case in point, I direct everyone's attention to Lush.
>> Lush is a fairly limited, fairly antiquated pre-Common-Lisp form
>> of interpreted Lisp. For the last 20 years, it has basically had
>> two users; the guys who wrote it. It has more useful libraries
>> already linked to it than exists online for all of Common Lisp, as
>> far as I can tell. Mostly because it has an excellent and useful
>> FFI for calling C code, and two users who use it a lot for serious
>> problems. It's also quite cute from a "hackability" standpoint, and
>> implements many of Paul Graham's ideas for a popular Lisp. If it
>> had a garbage collector for the compiler, I'd never even think of
>> using ACL. There would be no point, other than a few useful special
>> forms I would have to reimplement. It's not like ACL has a lot of
>> useful libraries I'd be jealous of.
--
Cameron MacKinnon
Toronto, Canada
"Cameron MacKinnon" <··········@clearspot.net> wrote in message
···························@golden.net...
> > If Slime were implemented for a single Common Lisp implementation,
> > things would be much easier. It's your choice to either try to
> > achieve portability across many CL implementations in your own code,
> > or else treat one specific CL implementation effectively as a
> > single-vendor language, including all the additional stuff that comes
> > with it.
>
> It is difficult to interpret the above in any other way than that the CL
> standard simply doesn't provide what writers of portable code need.
Seems to me that Slime IS portable and written in a portable fashion.
> It's great to try to sweep the problem under the rug by labelling such
> fundamentals as TCP/IP as "additional stuff".
Yeah, we should just write code to WinSOCK like everyone else. Oh. Wait.
> I do think there's a bit of a "big lie" peddled to newcomers, to wit:
> - Lisp is a rich language with a standard
> - There are a number of conforming implementations
> - Scheme, being minimalist, lacks a lot
>
> The clear implication, sometimes voiced, other times not, is that you
> can write useful, portable CL code, whereas with Scheme, you'll have to
> write lots of your own scaffolding, or go outside the standard and use
> implementation specific additional stuff.
How is this a "big lie"? It's more a "big truth", or simply a "honkin'
enormous FACT". Perhaps we have different definitions of "useful portable
code".
> > The Common Lisp standard addresses issues that vendors of other
> > languages don't even think of.
>
> The Scheme community seems to have developed an ongoing, informal
> standards process (SRFIs) to cover issues not addressed in their formal
> standards (RnRS). The only similar thing I've seen in Lisp is ACL-COMPAT.
Have you even LOOKED at the SRFI list? They're trying to hammer out "minor"
things like structures, strings, multi-dimension arrays, streams and
exceptions. Things CL had TWENTY YEARS AGO. And note that there is not one
mention in the SRFI of anything to do with something like sockets or GUIs,
and still no object system.
On the other side of the coin, my favorite Scheme implementation, moreso as
a baby duck syndrome it-was-the-first-I-used-so-I-stuck-with-it, is Jaffers
SCM. It's updated regularly, and I can't find anything anywhere that tells
me what if any of the SRFI's it implements, supports, or sorta supports with
limitations (like, say, the CLISP implementation notes document which is
nice and detailed about its standard compliance).
How does something like ACL-COMPAT tarnish CL when the community has at
least TWO packages like the Apache Portable Runtime or Netscape Portable
Runtime? Is there no "useful portable code" in C/C++ either?
There are, that I know of, two really portable systems that has everything I
guess you feel is important for "useful portable code", and that's Java and
REBOL (Rebol? ReBoL? reboL? whatever).
With all of its portability, Java is the COBOL of the new millenia. Designed
at the outset for massive portability, people have to break that idiom to
get what they want out of it (ye old Swing vs SWT debate, among others).
Things like Java2D and Java3D aren't portable either. Java didn't even have
non-blocking I/O until that last year or two.
We won't mention the burgeoning, enormous REBOL community.
Python is portable "mostly", Perl is portable "mostly", and those are Single
Implementation languages (it can almost be argued that Java is a single
implementation language with different JVMs but a standard library -- I
dunno if IBM and others license Suns library code or not and only write
their own JVMs), where the developers choose what is and is not portable (vs
CL which may have incompatabilities between differing implementations). None
of these languages have actual Standards. Just De Facto implementations.
All of the "hard" problems of interfacing CL to systems (i/o, sockets, guis,
native threads, etc) are where portability breaks down. Amazingly, this is
where things break down in other languages as well. This is why in other
languages, those capabilities tend to be avoided in the standards. You'll
note that all of the blather from MS about how C# is a "standard" etc. that
there is NO mention of even the most base library. Only the syntax and the
runtime. No sockets, no gui, hell not even simple data structures. The
Standard C library has little more than Strings and I/O. No network, no
threads, no GUI, graphics, sounds...zip. zilch. goose egg. The Big Bagel.
There's POSIX of course, and many work towards that, but so does CL. While
the names may be different, most of this base technology operates the same,
because most of it is leveraged on top of POSIX. With similar behaviors, you
end up with simple translation layers to handle discrepancies between
implementations. ACL-COMPAT is pretty darn thin.
The point of having a Standard is that its a benchmark against which one can
bounce your code off. Having a Standard makes it easy to look up how
something is supposed to behave, and, ideally, how it REALLY behaves in your
implementation. Most of the other "popular" languages today don't have the
benefit of multiple implementations that CL has, so there is little
necessity to document a behavior. The behavior is simply whatever the
implementation does.
Once you know how something is supposed to work, and then how it actually
does work, you can use that information in porting it to other
implementations. For example, different implementations may do integers
differently, or the line between fixnums and bignums may easily vary. If a
specific behavior is important to you, you can note it and check how a new
implementation implements that detail. The CL Standard supports portability
for "the hard stuff" specifically because it actually allows very little to
be implementation dependent, much more so than something like C, where you
can have a program that's ANSI C compliant on one system be an utter
disaster on another because the standard allows so much leeway. There is a
lot more you can "assume" in CL than in something like C.
CL is an ancient language by todays benchmark. It has the battle scars of a
grizzled war veteran. It is still here, still going strong, and, if
anything, speeding up. What's the quote? "Old age & treachery will triumph
over youth & enthusiasm"?
The other line is "Those that do not learn history are doomed to repeat it".
CL comes with history for free. A lot of mistakes have been made long before
the Standard came together and the fixes got forged into it through the pain
and blood of old coders. That's the beauty of system based on an image...it
never forgets, and that's what helps make it portable.
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> CL is an ancient language by todays benchmark. It has the battle scars of a
> grizzled war veteran. It is still here, still going strong, and, if
> anything, speeding up. What's the quote? "Old age & treachery will triumph
> over youth & enthusiasm"?
>
> The other line is "Those that do not learn history are doomed to repeat it".
> CL comes with history for free. A lot of mistakes have been made long before
> the Standard came together and the fixes got forged into it through the pain
> and blood of old coders. That's the beauty of system based on an image...it
> never forgets, and that's what helps make it portable.
That was a very eloquent rant. Thanks.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
"Will Hartung" <·····@msoft.com> writes:
> You'll note that all of the blather from MS about how C# is a
> "standard" etc. that there is NO mention of even the most base
> library. Only the syntax and the runtime. No sockets, no gui,
> hell not even simple data structures.
System.Net.Sockets.Socket and System.Collections.Hashtable are
specified in an XML file that purports to be "a normative part
of the following standards: ISO/IEC 23271 and ECMA 335".
There's also System.Console, but apparently no GUI.
Cameron MacKinnon <··········@clearspot.net> writes:
> Pascal Costanza wrote:
>> You are making a mistake that seems to be very common. You compare a
>> language implementation (Lush) with a language standard (Common
>> Lisp). That's like comparing an apple with an orange tree.
>
> I don't see the mistake. If CL is a useful standard, there should be
> lots of useful libraries written in pure CL by now.
Why? What makes you say that? (I think there /are/ useful libraries
written in CL, some in "pure" CL, some not. You clearly don't. Why?)
> Lupo points out that one non CL implementation with a user community
> in the single digits seems to have more libraries than the entire CL
> community.
Yes, but pointing out a subjective feeling isn't terribly useful when
trying to make objective comparisons. Just because Lupo is unable to
drive a search engine doesn't mean that Common Lisp is doomed.
> It's great to try to sweep the problem under the rug by labelling such
> fundamentals as TCP/IP as "additional stuff".
So, C doesn't have a standard for these "fundamentals". Fortran
doesn't have a standard for these "fundamentals".
> I do think there's a bit of a "big lie" peddled to newcomers, to
> wit:
Is this a conspiracy? Who is the Goebbels, orchestrating this
vile propaganda?
> - Lisp is a rich language with a standard
> - There are a number of conforming implementations
> - Scheme, being minimalist, lacks a lot
>
> The clear implication, sometimes voiced, other times not, is that you
> can write useful, portable CL code
Let me voice this: "I can write useful, portable CL code". How's
that? I don't know if you can; that's rather more up to you than it
is to me. It think it would probably have something to do with
spending more time learning about things and, well, attempting to
write code, and rather less time making empty speculation on USENET.
> whereas with Scheme, you'll have to write lots of your own
> scaffolding, or go outside the standard and use implementation
> specific additional stuff.
I make no claim about Scheme whatsoever. Why do you bring this up?
Look. If you, or anyone else, finds that your particular needs aren't
met by an off-the-shelf library for Common Lisp (language, or a
particular implementation), there are various things you can do.
You could write one. You could find a different implementation or
language, and solve your problem there. You could hire someone to
solve your problem for you. You could spend some time reformulating
your problem, maybe attacking it in a different way. Or you could
come to comp.lang.lisp and just randomly make stuff up without any
facts to back it up, and cause yet another tedious debate about how
Common Lisp doesn't support the latest stupid messaging protocol out
of the box, and how unfair it is that no-one has created a portable
library for you to write your client in three lines of code. (Or
whatever your particular problem is, I don't know. *Do* you have a
use case, or was this all completely empty?)
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Cameron MacKinnon <··········@clearspot.net> writes:
> Christophe Rhodes wrote:
>> Is this a conspiracy? Who is the Goebbels, orchestrating this
>> vile propaganda?
>
> Wow, that was quick!
Wow, that was stupid!
Among people with a knowledge of history beyond their own personal
experience, the phrase "big lie" (which you helpfully emphasized as a
phrase, rather than two words, just in case we missed it) is closely
associated with the propaganda machine of Nazi Germany. So firstly,
if anyone is going to be accused of Godwination, it'll be those people
who accuse persons unspecified, or indeed an sinister organization of
brainwashed Common Lispers, of orchestrating a devilish
(mis)information campaign, to decrease the productivity of otherwise
hardworking and intelligent apple-pie-eating folks.
However, regrattably, neither attempted Godwination has prevented this
discussion from continuing, so I'll thank you to try again, this time
reading my whole post, attempting to think about it in its entirety,
rather than just my calling you on your rather pathetic attempt to tar
a whole bunch of people with an invidious comparison.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>>Pascal Costanza wrote:
>>
>>>You are making a mistake that seems to be very common. You compare a
>>> language implementation (Lush) with a language standard (Common
>>>Lisp). That's like comparing an apple with an orange tree.
>>
>>I don't see the mistake. If CL is a useful standard, there should be
>>lots of useful libraries written in pure CL by now.
>
> Why? What makes you say that? (I think there /are/ useful libraries
> written in CL, some in "pure" CL, some not. You clearly don't. Why?)
Lupo claimed that Lush, an implementation I'd not heard of before his
post, has more libraries than CL does. Pascal said that it was an unfair
comparison, but I disagreed.
You can prove Lupo wrong and make my point moot by showing that there
are more libraries for CL. Or you can support Pascal. But you won't get
me to defend the straw man you've built.
>>Lupo points out that one non CL implementation with a user community
>>in the single digits seems to have more libraries than the entire CL
>>community.
>
> Yes, but pointing out a subjective feeling isn't terribly useful when
> trying to make objective comparisons. Just because Lupo is unable to
> drive a search engine doesn't mean that Common Lisp is doomed.
Google for: And get:
"lisp faq" The 1997 edition
"common lisp library" A Java library
Assuming that it's common knowledge to search on Cliki instead of
Google, about 60 libraries can be found on the 'libraries'. But of
course there are more, such as Binary-Types, buried in the Cliki but not
listed on the Libraries page. So would it be reasonable to say that
there are about 100 libraries for CL?
There's also cCLan and vn-cCLan. What could Lupo have typed into a
search engine to discover these? Are there other collections?
And why did you feel the need to insult his intelligence?
> Let me voice this: "I can write useful, portable CL code". How's
> that? I don't know if you can; that's rather more up to you than it
> is to me. It think it would probably have something to do with
> spending more time learning about things and, well, attempting to
> write code, and rather less time making empty speculation on USENET.
Is the majority of your code portable CL? Or do you constantly find
yourself using vendor extensions?
If you do use vendor extensions, are they unique extensions that give
that particular implementation an advantage, or are they just
nonstandard variations of the same set of extensions that nearly every
implementation has?
> Look. If you, or anyone else, finds that your particular needs aren't
> met by an off-the-shelf library for Common Lisp (language, or a
> particular implementation), there are various things you can do.
> You could write one. You could find a different implementation or
> language, and solve your problem there. You could hire someone to
> solve your problem for you. You could spend some time reformulating
> your problem, maybe attacking it in a different way. Or you could
> come to comp.lang.lisp and just randomly make stuff up without any
> facts to back it up, and cause yet another tedious debate about how
> Common Lisp doesn't support the latest stupid messaging protocol out
> of the box, and how unfair it is that no-one has created a portable
> library for you to write your client in three lines of code. (Or
> whatever your particular problem is, I don't know. *Do* you have a
> use case, or was this all completely empty?)
I wasn't aware that I had to bring code to the debate. Or that a
reasoned post would earn such wild mischaracterization. Or that TCP/IP
is considered among the cognoscenti as merely the "latest stupid
messaging protocol".
But hey, since you asked, I'm currently working on code to read and
write ELF files. No big deal - three structs, some file offsets but no
pointers, and a block of null terminated strings.
I couldn't find a library that already does this, but that's OK. I
didn't expect to only have to write "three lines of code", and it's a
learning experience anyway.
It seems that I have to read and write the files one byte at a time. Or
I can use Binary-Types, a portable library which provides useful
abstractions on top of the underlying one-byte-at-a-time model. Or I can
use implementation specific extensions.
Block I/O seems not to be addressed in the CL standard. I'm sure that it
isn't because nobody saw the advantages of block I/O back in the 80s and
90s. Lisp machines must have done I/O in blocks. So why is it missing
from the standard?
I candidly admit to being new at Lisp. The following is only a
"subjective feeling". Coding up my own binary 16 and 32 bit integer
reads, C string reads and such feels a bit retrograde. Granted, each
function is only two or three lines of code. But I'm surprised that I
should have to do this in a full featured language. It feels like the
early chapters of K&R's "The C Programming Language" -- the minimal
tools are given, from which one can code up anything, but one starts at
a fairly low level. Am I missing something?
The code I have been using, which relies on CMUCL's Alien, seems to be
consing several megabytes when processing a few kilobytes of file data.
It's not that I've started profiling it, but the garbage collector does
announce its progress several times during the run, and my computer's
mildly annoying variable speed fan runs on high for several seconds. So
I'm rewriting in the aforementioned pure CL, byte at a time, without
Alien, from first principles. As I said, this is just a learning
experience for me.
How would you approach this? Implementation specific extensions? Byte at
a time? Binary-Types, or another library?
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> Google for: And get:
> "lisp faq" The 1997 edition
followed by some autocad stuff, followed by Paul Graham's FAQ (which
has a ton of lisp-related links accessible from it)
> "common lisp library" A Java library
The same result page contains links to the CMUCL site and the CLiki
index page.
> Assuming that it's common knowledge to search on Cliki instead of
> Google, about 60 libraries can be found on the 'libraries'. But of
> course there are more, such as Binary-Types, buried in the Cliki but
> not listed on the Libraries page. So would it be reasonable to say
> that there are about 100 libraries for CL?
Sounds low if anything: there's 50 hosted on common-lisp.net alone,
and that site has only been going for a few months.
> There's also cCLan and vn-cCLan. What could Lupo have typed into a
> search engine to discover these? Are there other collections?
Having found cliki from one of the previous searches, he could have
read its index page, which includes :
* cclan and vn-cclan- the Comprehensive Common Lisp Archive Network
Although the wording of this could be made clearer, I guess. To
anyone who's never used TeX or Perl it's probably not obvious that an
"Archive Network" might be a place to find libraries. Thanks for
(indirectly) drawing this to my attention
> And why did you feel the need to insult his intelligence?
He clearly _hasn't_ used a search engine. Whether this is because
he's unable or unwilling I couldn't say, but let me note that the leap
from "unable to drive a search engine" (Christophe's assertion) to
"unintelligent" is yours, not anybody else's. I think that, like
reading, it's probably more of a learned skill than an indication of
anything innate.
> It seems that I have to read and write the files one byte at a
> time. Or I can use Binary-Types, a portable library which provides
> useful abstractions on top of the underlying one-byte-at-a-time
> model. Or I can use implementation specific extensions.
I can't work out from your description whether you've never heard of
READ-SEQUENCE, or whether you've looked at it already and dismissed it
for reasons you're not sharing.
To save you the time you might otherwise spend thrashing about on the
web, if your search engine skills are as good as you describe them to
be above, I'll add that this is an ANSI standard CL function which you
can read about in the Hyperspec at this URL
http://www.lispworks.com/reference/HyperSpec/Body/f_rd_seq.htm
-dan
--
"please make sure that the person is your friend before you confirm"
Cameron MacKinnon <··········@clearspot.net> writes:
> Christophe Rhodes wrote:
>> Cameron MacKinnon <··········@clearspot.net> writes:
>>
>>>Pascal Costanza wrote:
>>>
>>>>You are making a mistake that seems to be very common. You compare a
>>>> language implementation (Lush) with a language standard (Common
>>>>Lisp). That's like comparing an apple with an orange tree.
>>>
>>>I don't see the mistake. If CL is a useful standard, there should be
>>>lots of useful libraries written in pure CL by now.
>> Why? What makes you say that? (I think there /are/ useful libraries
>> written in CL, some in "pure" CL, some not. You clearly don't. Why?)
>
> Lupo claimed that Lush, an implementation I'd not heard of before his
> post, has more libraries than CL does. Pascal said that it was an
> unfair comparison, but I disagreed.
>
> You can prove Lupo wrong and make my point moot by showing that there
> are more libraries for CL. Or you can support Pascal. But you won't
> get me to defend the straw man you've built.
*I've* built?
OK, well, there are two things wrong here. The first is that it is an
unfair comparison: it is comparing, as Pascal quite rightly points
out, a single implementation against the intersection of libraries
written for implementations of Common Lisp. Do you see the point now?
A fair comparison would be to compare the /functionality/ offered by
/one/ Common Lisp implementation (and an equally biassed comparison
the other way would be to compare the union of available functionality
over all Common Lisp implementations). The other wrong thing is the
assertion that "useful standard" => "libraries written in pure
<standard>"; I hope the reasoning is obvious.
> Assuming that it's common knowledge to search on Cliki instead of
> Google, about 60 libraries can be found on the 'libraries'. But of
> course there are more, such as Binary-Types, buried in the Cliki but
> not listed on the Libraries page. So would it be reasonable to say
> that there are about 100 libraries for CL?
That rather depends on your definition of a library. For instance, is
an implementation of a MetaObject protocol a vendor extension, an
implementation of a standard, or a library? I'd rather compare
functionality than numbers of libraries.
> There's also cCLan and vn-cCLan. What could Lupo have typed into a
> search engine to discover these? Are there other collections?
There are, as it happens. For instance, the code collection at the
CMU Artificial Intelligence repository. the Common Lisp Open Code
Collection at SourceForge. Bits and pieces here and there and
everywhere (genetic programming libraries, intelligent agent
libraries... loads of stuff that I don't know anything about).
>> Let me voice this: "I can write useful, portable CL code". How's
>> that? I don't know if you can; that's rather more up to you than it
>> is to me. It think it would probably have something to do with
>> spending more time learning about things and, well, attempting to
>> write code, and rather less time making empty speculation on USENET.
>
> Is the majority of your code portable CL? Or do you constantly find
> yourself using vendor extensions?
The majority of my code is portable CL. It does depend implicitly on
the implementation having different, mostly-IEEE single-float and
double-floats, and also having distinguished specializations of arrays
and streams for (unsigned-byte 8) and (unsigned-byte 32) [ and one or
two other similar, not entirely standardized, corner cases ].
> If you do use vendor extensions, are they unique extensions that give
> that particular implementation an advantage, or are they just
> nonstandard variations of the same set of extensions that nearly every
> implementation has?
Generally, the extensions that I use (in the minority of code that I
write that is not "portable") lie either in community-agreed but not
formal standards (such as the MOP, as described in "The Art of the
Metaobject Protocol") or are capable of being wrapped for the subset
of possible worlds that I need to support (sockets, for instance --
while the BSDish socket interface is a reasonable match for most
Unixes, I gather it's not so well-matched with what Microsoft Windows
provides. That doesn't bother me too much, because I'm not aiming to
solve the general problem in those cases).
>> Or you could
>> come to comp.lang.lisp and just randomly make stuff up without any
>> facts to back it up, and cause yet another tedious debate about how
>> Common Lisp doesn't support the latest stupid messaging protocol out
>> of the box, and how unfair it is that no-one has created a portable
>> library for you to write your client in three lines of code. (Or
>> whatever your particular problem is, I don't know. *Do* you have a
>> use case, or was this all completely empty?)
>
> I wasn't aware that I had to bring code to the debate. Or that a
> reasoned post would earn such wild mischaracterization. Or that TCP/IP
> is considered among the cognoscenti as merely the "latest stupid
> messaging protocol".
... speaking of mischaracterization ...
In any case, you don't /have/ to bring code to the debate. But it is
so much easier firstly to discuss possibilities and practicalities
when there is a specific example in mind, because otherwise the
potential for miscommunication is high (and secondly, to eliminate
certain discussions as unprofitable because the other party is making
no effort).
> I couldn't find a library that already does this, but that's OK. I
> didn't expect to only have to write "three lines of code", and it's a
> learning experience anyway.
Fine.
> It seems that I have to read and write the files one byte at a
> time. Or I can use Binary-Types, a portable library which provides
> useful abstractions on top of the underlying one-byte-at-a-time
> model. Or I can use implementation specific extensions.
>
> Block I/O seems not to be addressed in the CL standard. I'm sure that
> it isn't because nobody saw the advantages of block I/O back in the
> 80s and 90s. Lisp machines must have done I/O in blocks. So why is it
> missing from the standard?
I suspect you're reading from "Common Lisp the Language, second
edition". Between the publication of that book and the finalization
of the ANSI specification, READ-SEQUENCE and WRITE-SEQUENCE were added
to the language, giving you the ability to do block I/O.
> The code I have been using, which relies on CMUCL's Alien, seems to be
> consing several megabytes when processing a few kilobytes of file
> data. It's not that I've started profiling it, but the garbage
> collector does announce its progress several times during the run, and
> my computer's mildly annoying variable speed fan runs on high for
> several seconds. So I'm rewriting in the aforementioned pure CL, byte
> at a time, without Alien, from first principles. As I said, this is
> just a learning experience for me.
>
> How would you approach this? Implementation specific extensions? Byte
> at a time? Binary-Types, or another library?
OK, so I think we've solved the block I/O problem in this discussion,
which is a good start. CMUCL's alien facility does have the habit of
being a little consy either if all the alien types are not fully
declared, or if it has to box and unbox aliens between calls. Does
CMUCL give you any compiler notes when you compile your code?
In order of decreasing laziness, if this is a problem, I would suggest
* turning the verbosity of the garbage collector down (hey, it
worked for emacs :-);
* making sure that all the alien types are declared properly;
* rewriting or block-compiling your code so that boxing need not
happen;
* writing your own handling from scratch.
That said, there is nothing wrong with being non-lazy as part of the
learning experience.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> OK, well, there are two things wrong here. The first is that it is an
> unfair comparison: it is comparing, as Pascal quite rightly points
> out, a single implementation against the intersection of libraries
> written for implementations of Common Lisp. Do you see the point now?
> A fair comparison would be to compare the /functionality/ offered by
> /one/ Common Lisp implementation (and an equally biassed comparison
> the other way would be to compare the union of available functionality
> over all Common Lisp implementations). The other wrong thing is the
> assertion that "useful standard" => "libraries written in pure
> <standard>"; I hope the reasoning is obvious.
I think that the difference between the intersection and the union that
you mention above is a rough metric of the utility of the CL standard to
the community. If most libraries can accomplish all of their
functionality without using extra-standard features, that's great.
"Write once, run anywhere." If not, that suggests that the standard
isn't comprehensive enough. Of course, we can exclude libraries that are
inherently non portable, such as those tied to a particular windowing
system.
How about:
"useful standard" * "caring, sharing community" * "a decade elapsed"
=> "lots of libraries written in pure <standard>"
I'm not questioning the second term, I'm asserting it.
Lupo gave us his impression of the number of libraries available for CL
versus Lush. The obvious rebuttal would've been proof to the contrary,
but instead he was told that it was an unfair comparison and/or he
couldn't use a search engine. I didn't believe those two arguments to be
either enlightening or fair.
I've already shown that some of the standard newbie type searches return
unhelpful results, and I gave pointers to library collections, which
elicited some other pointers to other collections (and some gratuitous
comments on *my* ability to use a search engine).
> I suspect you're reading from "Common Lisp the Language, second
> edition". Between the publication of that book and the finalization
> of the ANSI specification, READ-SEQUENCE and WRITE-SEQUENCE were added
> to the language, giving you the ability to do block I/O.
Thanks for the pointer to READ-SEQUENCE -- I wasn't aware of it. I'm not
using CLTL2, just SICP and a mishmash of online resources, including the
CLHS. And thanks for your other tips regarding my binary file work. They
have opened up useful avenues of further exploration.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> Lupo gave us his impression of the number of libraries available for
> CL versus Lush. The obvious rebuttal would've been proof to the
> contrary, but instead he was told that it was an unfair comparison
> and/or he couldn't use a search engine. I didn't believe those two
> arguments to be either enlightening or fair.
I'm not sure the time for an enlightening rebuttal would be well
spent. As Lupo and you describe yourselves, you are newbies who give
"impressions" based, in your case, on sources like:
> Thanks for the pointer to READ-SEQUENCE -- I wasn't aware of it. I'm
> not using CLTL2, just SICP and a mishmash of online resources,
> including the CLHS. And thanks for your other tips regarding my binary
If you really want to investigate the adequacy of existing libraries,
and whether the language encourages or not the creation of new ones,
at least do some homework.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Cameron MacKinnon <··········@clearspot.net> writes:
> It seems that I have to read and write the files one byte at a
> time. Or I can use Binary-Types, a portable library which provides
> useful abstractions on top of the underlying one-byte-at-a-time
> model. Or I can use implementation specific extensions.
>
> Block I/O seems not to be addressed in the CL standard. I'm sure that
> it isn't because nobody saw the advantages of block I/O back in the
> 80s and 90s. Lisp machines must have done I/O in blocks. So why is it
> missing from the standard?
Does read-sequence work for you?
-russ
Cameron MacKinnon <··········@clearspot.net> writes:
> I don't see the mistake. If CL is a useful standard, there should be
> lots of useful libraries written in pure CL by now. Lupo points out that
Right, just like there are lots of useful libraries written in pure
ANSI C. Or is that not a useful standard either?
-dan
--
"please make sure that the person is your friend before you confirm"
From: Tim Bradshaw
Subject: Re: Popularity of programming languages
Date:
Message-ID: <ey3fzcvyot3.fsf@cley.com>
* Daniel Barlow wrote:
> Right, just like there are lots of useful libraries written in pure
> ANSI C. Or is that not a useful standard either?
Actually, no. It should have been useful, but Linux has arrived and
now essentially all C code is actually gcc code.
Daniel Barlow <···@telent.net> writes:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
> > I don't see the mistake. If CL is a useful standard, there should be
> > lots of useful libraries written in pure CL by now. Lupo points out that
>
> Right, just like there are lots of useful libraries written in pure
> ANSI C. Or is that not a useful standard either?
One can actually write interesting stuff in "Pure ANSI C", but things
like "get a directory listing" or "terminal-based real-time user
interface" lands one outside the standard pretty damned quick.
If one extends to "portable to POSIX" (an admittedly much larger
"language base" to stand on), one can even write things like
client/server architectures!
//Ingvar (though my last c/s contains a library for "lisp lists")
--
When C++ is your hammer, everything looks like a thumb
Latest seen from Steven M. Haflich, in c.l.l
Cameron MacKinnon wrote:
> Pascal Costanza wrote:
>
>> You are making a mistake that seems to be very common. You compare a
>> language implementation (Lush) with a language standard (Common
>> Lisp). That's like comparing an apple with an orange tree.
>
> I don't see the mistake. If CL is a useful standard, there should be
> lots of useful libraries written in pure CL by now.
How many useful libraries are written in "pure Lush"? Are they portable
across several Lush implementations?
> Lupo points out that
> one non CL implementation with a user community in the single digits
> seems to have more libraries than the entire CL community.
I have checked out Lush and it doesn't provide the things I need. Can
you point to another Lush implementation that does?
>> If Slime were implemented for a single Common Lisp implementation,
>> things would be much easier. It's your choice to either try to
>> achieve portability across many CL implementations in your own code,
>> or else treat one specific CL implementation effectively as a
>> single-vendor language, including all the additional stuff that comes
>> with it.
>
> It is difficult to interpret the above in any other way than that the CL
> standard simply doesn't provide what writers of portable code need.
So what does the Lush standard provide to achieve portability across all
Lush implementations? Can you name any language standard that provides
what portable code needs?
> It's great to try to sweep the problem under the rug by labelling such
> fundamentals as TCP/IP as "additional stuff".
http://www.cliki.net/Networking
> I do think there's a bit of a "big lie" peddled to newcomers, to wit:
> - Lisp is a rich language with a standard
> - There are a number of conforming implementations
> - Scheme, being minimalist, lacks a lot
>
> The clear implication, sometimes voiced, other times not, is that you
> can write useful, portable CL code, whereas with Scheme, you'll have to
> write lots of your own scaffolding, or go outside the standard and use
> implementation specific additional stuff.
The Common Lisp standard provides a lot more stuff than the Scheme
standard. Anything that uses Common Lisp features extensively therefore
has a higher degree of portability across CL implementations than the
same thing that uses similar features would have across Scheme
implementations. That's trivially true.
I don't think that Schemers deny this. To the contrary, many of them
point out that their language has different goals.
>> The Common Lisp standard addresses issues that vendors of other
>> languages don't even think of.
>
> The Scheme community seems to have developed an ongoing, informal
> standards process (SRFIs) to cover issues not addressed in their formal
> standards (RnRS). The only similar thing I've seen in Lisp is ACL-COMPAT.
ACL-COMPAT is not a standardization effort, but a library. SRFI is
indeed a good thing AFAICS. Something similar would probably add value
to Common Lisp. The closest in spirit seem to be http://www.cliki.net
and http://common-lisp.net
Note that I am not criticizing Lush here in this or other posts. If you
like it, if it provides just the things you need, and if you can live
with the fact that it isn't based on a standard, then just go ahead and
use it. But don't compare it with the Common Lisp standard and with the
amount of libraries that are implemented in pure Common Lisp. "Pure"
Common Lisp is a book, not a piece of software!
Portability across Common Lisp implementations is trivial for things
that lie in one or more of the domains that are covered by the standard.
This is clearly not the case for things that are outside of that domain.
This fact is true for any language standard.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
In article <············@newsreader2.netcologne.de>,
Pascal Costanza <········@web.de> wrote:
>
>Cameron MacKinnon wrote:
>
>> Pascal Costanza wrote:
>>
>>> You are making a mistake that seems to be very common. You compare a
>>> language implementation (Lush) with a language standard (Common
>>> Lisp). That's like comparing an apple with an orange tree.
>>
>> I don't see the mistake. If CL is a useful standard, there should be
>> lots of useful libraries written in pure CL by now.
>
>How many useful libraries are written in "pure Lush"? Are they portable
>across several Lush implementations?
Personally, I don't care. All I care about is the fact that I don't have
to write the FFI crap necessary to use another library, or reinvent the
wheel for the 10,000th time in my particular implementation of Lisp.
Sure, it is an "unfair" comparison in various unimportant ways. The fact
remains, a dumb little language like Lush is a lot more handy for a lot
more things than any of the mighty Common Lisps.
>> Lupo points out that
>> one non CL implementation with a user community in the single digits
>> seems to have more libraries than the entire CL community.
>
>I have checked out Lush and it doesn't provide the things I need. Can
>you point to another Lush implementation that does?
As you know, there is only one implementation.
As a counter question: show me a version of Common Lisp that does what
Lush does. Honest: if there were one, I'd like to see it. I fully
recognize ACL does things better in many ways. But it misses out on very
very very important things that any programmer who expects to get paid
uses on a daily basis (to reiterate: GUI, FFI, IPC, networking, talking to
the OS, string handling, blah blah blah).
>>> If Slime were implemented for a single Common Lisp implementation,
>>> things would be much easier. It's your choice to either try to
>>> achieve portability across many CL implementations in your own code,
>>> or else treat one specific CL implementation effectively as a
>>> single-vendor language, including all the additional stuff that comes
>>> with it.
>>
>> It is difficult to interpret the above in any other way than that the CL
>> standard simply doesn't provide what writers of portable code need.
>
>So what does the Lush standard provide to achieve portability across all
>Lush implementations? Can you name any language standard that provides
>what portable code needs?
Apparently, Common Lisp doesn't provide enough portability to allow a dumb
socket between emacs and any old C/L compiler to share the same piece of
software.
That's a fairly preposterous situation, if you ask me. Especially since
virtually everyone who writes code in Common Lisp uses emacs.
>Portability across Common Lisp implementations is trivial for things
>that lie in one or more of the domains that are covered by the standard.
>This is clearly not the case for things that are outside of that domain.
>This fact is true for any language standard.
Yeah, but the point is, the standard is missing most of the stuff that is
important in modern software development.
If Fortran had a different way of handling floating point code in every
compiler, most sane people would not bother writing fast floating
point code in Fortran, removing its logic for existing, other than the
sadistic imposition of the surrealistic syntax of Hollerith on grad
students. Similarly, it is quite plain that Common Lisp is lacking in
something, or it really would rule the world. It ain't the parenthesis.
It's the lack of functionality or libraries which add the functionality.
-Lupo
"Battle is the most magnificent competition in which a human being can
indulge. It brings out all that is best and it removes all that is base."
-Gen. George S. Patton Jr. <··@io.com>
··@io.com (Lupo LeBoucher) writes:
> As a counter question: show me a version of Common Lisp that does
> what Lush does. Honest: if there were one, I'd like to see it. I
> fully recognize ACL does things better in many ways. But it misses
> out on very very very important things that any programmer who
> expects to get paid uses on a daily basis (to reiterate: GUI, FFI,
> IPC, networking, talking to the OS, string handling, blah blah
> blah).
Hmmm. It seems to me that ACL (assuming you mean Allegro Common Lisp)
has GUI libs (X and GTK bindings, I believe. plus Common Graphics; a
quite good FFI, TCP and UDP sockets, an OSI module (Operating System
Interface), and ANSI Common Lisp has plenty of string handling built
in. (If mean regexps, I strongly recommend Edi Weitz's CL-PPCRE, a
very efficient perl-compatible regexp engine that runs on every Common
Lisp implementation I know of.) I'm not sure what sort of IPC you want
beyond sockets but you ought to be able to get to it either through
the FFI (if you have a C lib that speaks whatever IPC protocol you
care about) or sockets (if it's straightforward to implement
yourself.)
And Lispworks may have an even better GUI solution based on some
comments I've seen from happy CAPI users. And it has an FFI, sockets,
etc.
Knock any one of those items off the list and you can probably find a
free Lisp that has them all. In fact if the McCLIM guys are making as
good progress as it seems they are, many free lisps may meet all your
criteria. Or if Cello takes over the world the way Kenny keeps
promising.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> Hmmm. It seems to me that ACL (assuming you mean Allegro Common Lisp)
> has GUI libs (X and GTK bindings, I believe. plus Common Graphics; a
Plus CLIM.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Lupo LeBoucher wrote:
> In article <············@newsreader2.netcologne.de>,
> Pascal Costanza <········@web.de> wrote:
>>How many useful libraries are written in "pure Lush"? Are they portable
>>across several Lush implementations?
>
> Personally, I don't care. All I care about is the fact that I don't have
> to write the FFI crap necessary to use another library, or reinvent the
> wheel for the 10,000th time in my particular implementation of Lisp.
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
>>I have checked out Lush and it doesn't provide the things I need. Can
>>you point to another Lush implementation that does?
>
> As you know, there is only one implementation.
I see.
>>So what does the Lush standard provide to achieve portability across all
>>Lush implementations? Can you name any language standard that provides
>>what portable code needs?
>
> Apparently, Common Lisp doesn't provide enough portability to allow a dumb
> socket between emacs and any old C/L compiler to share the same piece of
> software.
...just when I thougt that Lush had only one implementation...
>>Portability across Common Lisp implementations is trivial for things
>>that lie in one or more of the domains that are covered by the standard.
>>This is clearly not the case for things that are outside of that domain.
>>This fact is true for any language standard.
>
> Yeah, but the point is, the standard is missing most of the stuff that is
> important in modern software development.
Common Lisp's feature set was fixed in 1988. The standard was released
in 1995. Of course it is lacking things that are fashionable nowadays.
The remedy is: just choose _one_ Lisp that does what you need. By going
with Lush you are already doing that. Why attack all the others?
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Tim Bradshaw
Subject: Re: Popularity of programming languages
Date:
Message-ID: <ey3k727yoxv.fsf@cley.com>
* Lupo LeBoucher wrote:
> As a counter question: show me a version of Common Lisp that does
> what Lush does. Honest: if there were one, I'd like to see it. I
> fully recognize ACL does things better in many ways. But it misses
> out on very very very important things that any programmer who
> expects to get paid uses on a daily basis (to reiterate: GUI, FFI,
> IPC, networking, talking to the OS, string handling, blah blah
> blah).
Um, it's a while since I used ACL in anger, but it has a very
competent FFI, lots of networking/IPC stuff up to and including CORBA,
and pretty industrial OS support. People have written NFS servers in
ACL (or maybe clients, I forget). Not sure what you mean about string
handling - do you mean regexps? - it has those, I'm sure. The GUI
situation was a mess last time I looked, I agree, although it was fine
on Windows, and that is/was all anyone actually cared about to a good
first approximation.
I mean, bitch about ACL on grounds of price if you like, but it's a
really competent implementation with a lot of systems libraries. LW is
also very competent - while having maybe somewhat fewer libraries
bundled (it does have CORBA though), it has a very decent
cross-platform GUI which now runs on Windows, Unix/Linux and Mac
extremely compatibly (I haven' tested the Mac one as I'm a release
behind the current one, but I hear it's fine).
--tim
Tim Bradshaw <···@cley.com> writes:
> extremely compatibly (I haven' tested the Mac one as I'm a release
> behind the current one, but I hear it's fine).
It's great. Porting from linux/windows is very easy (with one exception
which has bitten me a few times: On the Mac LW all interfaces share a
single thread, this is how Cocoa likes it (I was suprised that Cocoa
is _that_ old-fashioned!)).
--
(espen)
··@io.com (Lupo LeBoucher) wrote in message news:<······················@io.com>...
> If Fortran had a different way of handling floating point code in every
> compiler, most sane people would not bother writing fast floating
> point code in Fortran, removing its logic for existing, other than the
> sadistic imposition of the surrealistic syntax of Hollerith on grad
> students.
Assuming sane people are at all interested in writing fast floating
point code, they'd probably just be spending more of their free time
arguing about *which* compiler to use, and whether it was worth
switching.
From: Tim Bradshaw
Subject: Re: Popularity of programming languages
Date:
Message-ID: <ey3eksg6cbb.fsf@cley.com>
* Lupo LeBoucher wrote:
> I don't believe the number of users has anything to do with how many
> libraries there are for a language. This is a "big lie" which is peddled
> to newbies like me around here to excuse the tragic lack of useful
> libraries for Common Lisp. I am becoming more and more certain that the
> lack of libraries for Common Lisp is a sort of inherent character flaw in
> the way the language handles libraries. Libraries in Common Lisp are an
> awful mess. Building them, loading them; it all sucks giant swinging
> donkey balls.
So, it's basically free to design and write libraries, right? Tell
me, what is this huge disadvantage that Lisp has for writing
libraries? Perhaps it's that enough effort hasn't been put into
designing standard FFIs, defsystems, and so on. Now, why not? These
must all be free to implement too, it can't cost any money, can it?
> As a counter-case in point, I direct everyone's attention to Lush. Lush is
> a fairly limited, fairly antiquated pre-Common-Lisp form of interpreted
> Lisp.
How many implementations are there? One. Ah.
··@io.com (Lupo LeBoucher) writes:
> As a counter-case in point, I direct everyone's attention to Lush. Lush is
> a fairly limited, fairly antiquated pre-Common-Lisp form of interpreted
> Lisp. For the last 20 years, it has basically had two users; the guys who
> wrote it. It has more useful libraries already linked to it than exists
> online for all of Common Lisp, as far as I can tell. Mostly because it has
> an excellent and useful FFI for calling C code, and two users who use it
> a lot for serious problems. It's also quite cute from a "hackability"
> standpoint, and implements many of Paul Graham's ideas for a popular Lisp.
> If it had a garbage collector for the compiler, I'd never even think of
> using ACL. There would be no point, other than a few useful special forms
> I would have to reimplement. It's not like ACL has a lot of useful
> libraries I'd be jealous of.
Searching for an alternative to matlab, I looked at lush for a short
while, too. I didn't end up using it for various reasons related to
the language. Last week, I discovered a scheme dialect with similar
ideas (extremely easy interfacing to C/C++, compilation to efficient
C, portability, etc) called chicken. Apparently, it can parse C++
classes and represent them as CLOS-like classes without manual
intervention! I haven't yet checked it out rigorously, but my first
impression is that it could become a more modern lush if it is able to
attract a small user community. So if you are not scheme-phobic you
might want to take a look at it.
··@io.com (Lupo LeBoucher) writes:
> I don't believe the number of users has anything to do with how many
> libraries there are for a language. This is a "big lie" which is peddled
> to newbies like me around here to excuse the tragic lack of useful
> libraries for Common Lisp. I am becoming more and more certain that the
> lack of libraries for Common Lisp is a sort of inherent character flaw in
> the way the language handles libraries. Libraries in Common Lisp are an
You describe yourself as a newbie, yet you are "becoming more and more
certain" of that? You sure seem to learn fast.
> As a counter-case in point, I direct everyone's attention to Lush. Lush is
[...]
> If it had a garbage collector for the compiler, I'd never even think of
> using ACL. There would be no point, other than a few useful special forms
> I would have to reimplement. It's not like ACL has a lot of useful
> libraries I'd be jealous of.
Have you considered paying someone, possibly the Lush maintainers, for
adding the missing features you need? Or maybe share the cost with
others interested in the project?
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso <·······@mclink.it> writes:
> ··@io.com (Lupo LeBoucher) writes:
>
> > I don't believe the number of users has anything to do with how many
> > libraries there are for a language. This is a "big lie" which is peddled
> > to newbies like me around here to excuse the tragic lack of useful
> > libraries for Common Lisp. I am becoming more and more certain that the
> > lack of libraries for Common Lisp is a sort of inherent character flaw in
> > the way the language handles libraries. Libraries in Common Lisp are an
>
> You describe yourself as a newbie, yet you are "becoming more and more
> certain" of that? You sure seem to learn fast.
To state it otherwise, perhaps the lack of apparent libraries in
Common-Lisp is due to the fact that Common-Lisp is so powerful that it
does not need so many libraries to start programming applications.
I've already written how converting a library of 31 Modula-2 modules
left me with only 2 lisp packages. Well, it's not finished: when I
try to re-implement in a lispy way the remaining packages, it occurs
that most of the functions become lisp one-liners. Hardly worth the
burden to package them in a "reusable" library, to document them, to
have the other programmers locate them, learn them to use them. I
would better spend my time programming something else, and they would
better spend their time rewritting their own one-liners _and_
programming something else than spend it on library searching and
learning.
That said, more _substancial_ Common-Lisp libraries can't hurt.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Andr� Thieme wrote:
> How does the popularity of a programming language affect this language?
> Wouldn't Lisp become even more usefull (more libs) if it had more users?
>
Why are you asking?
Wade
From: André Thieme
Subject: Re: Popularity of programming languages
Date:
Message-ID: <c1jd1j$gip$1@ulric.tng.de>
Wade Humeniuk wrote:
> Andr� Thieme wrote:
>
>> How does the popularity of a programming language affect this
>> language? Wouldn't Lisp become even more usefull (more libs) if it had
>> more users?
>>
>
>
> Why are you asking?
I would like to hear some opinions about it.
I would like to see if some people are maybe a bit disappointed that
Lisp is so unpopular. Maybe some even want to change it. Or I might be
surprised that noone really cares about the popularity and is not
interested in helping to make Lisp more popular.
And what is your opinion about it?
Andr�
Andr� Thieme wrote:
> Wade Humeniuk wrote:
>
>> Andr� Thieme wrote:
>>
>>> How does the popularity of a programming language affect this
>>> language? Wouldn't Lisp become even more usefull (more libs) if it
>>> had more users?
>>>
>>
>>
>> Why are you asking?
>
>
> I would like to hear some opinions about it.
> I would like to see if some people are maybe a bit disappointed that
> Lisp is so unpopular. Maybe some even want to change it. Or I might be
> surprised that noone really cares about the popularity and is not
> interested in helping to make Lisp more popular.
>
> And what is your opinion about it?
I am not disappointed with anyone's opinion as to whether Lisp is
popular or unpopular. I am not interested in making Lisp popular,
I am interested in doing a great job and being skilled at what I
do. I no longer have the luxury of letting my judgements
get in the way of the way things are.
Wade
Andr� Thieme wrote:
> Wade Humeniuk wrote:
>
>> Andr� Thieme wrote:
>>
>>> How does the popularity of a programming language affect this
>>> language? Wouldn't Lisp become even more usefull (more libs) if it
>>> had more users?
>>>
>>
>>
>> Why are you asking?
>
>
> I would like to hear some opinions about it.
> I would like to see if some people are maybe a bit disappointed that
> Lisp is so unpopular.
Every Lisp conference I have been to since 1999, and a recurring theme
on cll, is that many wish Lisp were more popular because then we could
use it at work. As it is, many have to do Java and other horrible things.
I do not think we care so much about having more libraries and/or better
IDEs. The environments we have are awesome, largely because Lisp is our
IDE. As for the libraries, that is not a problem, just wait till the
Open Source Fairy leaves the bindings you need under your pillow. Or use
UFFI and do it yourself. Takes a few days to get the hang of FFI, but
then yer done.
Maybe some even want to change it. Or I might be
> surprised that noone really cares about the popularity and is not
> interested in helping to make Lisp more popular.
It is a two-edged sword. Entrepreneurs will lose a huge competitive
advantage if Lisp catches on, non-entrepreneurs get to use Lisp at work.
Vendors will make more money and do more stuff like provide bindings
to libraries, persistence CLOS ODBs, FFIs for other languages (such as
Franz's Java).
And, yes, open source libs will get more help. Hey, a newbie ported
Cello to Linux.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Every Lisp conference I have been to since 1999, and a recurring theme
> on cll, is that many wish Lisp were more popular because then we could
> use it at work. As it is, many have to do Java and other horrible
> things.
>
> I do not think we care so much about having more libraries and/or
> better IDEs. The environments we have are awesome, largely because
> Lisp is our IDE. As for the libraries, that is not a problem, just
> wait till the Open Source Fairy leaves the bindings you need under
> your pillow. Or use UFFI and do it yourself. Takes a few days to get
> the hang of FFI, but then yer done.
If it was just a tad more popular, perhaps we would have a Common-Lisp
operating system, and then we would not have to deal with FFI? That
would be bliss.
> Maybe some even want to change it. Or I might be
> > surprised that noone really cares about the popularity and is not
> > interested in helping to make Lisp more popular.
>
> It is a two-edged sword. Entrepreneurs will lose a huge competitive
> advantage if Lisp catches on, non-entrepreneurs get to use Lisp at
> work. Vendors will make more money and do more stuff like provide
> bindings to libraries, persistence CLOS ODBs, FFIs for other languages
> (such as Franz's Java).
>
> And, yes, open source libs will get more help. Hey, a newbie ported
> Cello to Linux.
Yes, let's keep it our secret weapon.
You want it popular? Build a startup, then being the boss, you'll
have lisp popular among your employees! (And no need to mention it to
your customers who don't care or to your competition who does not
understand).
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> If it was just a tad more popular, perhaps we would have a Common-Lisp
> operating system, and then we would not have to deal with FFI? That
> would be bliss.
Is anyone working on such a beast? As in a free (in the sense of
Linux) project? That would be cool. I would be interested in such a
system.
There are of course certain gotchas. It will need a useful amount of
software to catch on (however much that is). Then there is device
driver hell. Device drivers are a problem under Linux.
A Linux emulation environment (or perhaps an even more general
machine emulation environment) might go a long way to dealing with
the applications issue.
[attribes lost (use google)]
> > It is a two-edged sword. Entrepreneurs will lose a huge competitive
> > advantage if Lisp catches on, non-entrepreneurs get to use Lisp at
> > work. Vendors will make more money and do more stuff like provide
> > bindings to libraries, persistence CLOS ODBs, FFIs for other languages
> > (such as Franz's Java).
> >
> > And, yes, open source libs will get more help. Hey, a newbie ported
> > Cello to Linux.
>
> Yes, let's keep it our secret weapon.
>
> You want it popular? Build a startup, then being the boss, you'll
> have lisp popular among your employees! (And no need to mention it to
> your customers who don't care or to your competition who does not
> understand).
I have a rather selfish motive for wanting to learn Lisp. That would
be the competitive advantage of Lisp as an applications development
language and environment over other alternatives. The bottom line is
that I want a tool that helps me get more done over a given unit of
time. If Paul Graham and others are not delusional, Lisp sure sounds
like that tool.
If I reach a point where I can feed back to the Lisp community, that
also would be great.
Lisp doesn't need x% of the market. It just needs enough users in
absolute numbers to keep moving forward. I wouldn't be surprised if
the Mythical Man Month effect keeps Java (just as an example) from
rapidly out-pacing Lisp in technical development.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber wrote:
> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>
>
>>If it was just a tad more popular, perhaps we would have a Common-Lisp
>>operating system, and then we would not have to deal with FFI? That
>>would be bliss.
>
>
> Is anyone working on such a beast? As in a free (in the sense of
> Linux) project? That would be cool. I would be interested in such a
> system.
Sort of. See
http://www.common-lisp.net/project/movitz/
Mostly right now this is Frode V. Fjeld's very cool implementation of
common lisp bootable on a bare PC, plus a little example code and some
discussion. There's a mix of spectators and a few hackers following it.
If I ever clear a space in amongst all the other stuff I'm working on,
there are several pieces of an OS I'd like to build on Frode's work.
>
> There are of course certain gotchas. It will need a useful amount of
> software to catch on (however much that is). Then there is device
> driver hell. Device drivers are a problem under Linux.
I honestly don't care that much whether it catches on. I'm on the
mailing lists because I've worked on and with Lisp OSes in the past and
I miss it. I want to do it again.
>
> A Linux emulation environment (or perhaps an even more general
> machine emulation environment) might go a long way to dealing with
> the applications issue.
Bleh. I don't care if there is ever such a beast.
Andr� Thieme <······································@justmail.de> writes:
> I would like to hear some opinions about it.
> I would like to see if some people are maybe a bit disappointed that
> Lisp is so unpopular. Maybe some even want to change it. Or I might be
> surprised that noone really cares about the popularity and is not
> interested in helping to make Lisp more popular.
>
> And what is your opinion about it?
A language really only needs to have enough users to keep the
development tools going. Lisp certainly has that. Lisp support on
Debian is very good from what I can see.
Java may be ultra-popular, but it just doesn't impress me like it
used to. And what is the value of a typical Java coder in the market
place? Aren't those jobs going to India?
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
On 2004-02-26 01:03:07, Andr� Thieme wrote:
> I would like to see if some people are maybe a bit disappointed that
> Lisp is so unpopular.
It's a business advantage when other people don't use "better"
programming languages.
As long as the critical mass (enough library fairies) is constant
...
Stefan Scholl <······@no-spoon.de> writes:
> It's a business advantage when other people don't use "better"
> programming languages.
Meanwhile it's a quality-of-life disadvantage for every software
system you use but are not in competition with the suppliers of. I
regularly use or am affected by the workings of many many more
computer systems than I have any hope of personally reimplementing in
Lisp, and every time one of them fucks up it affects me.
When I can find Lisp-using alternatives for my desktop software, all
the web sites I visit regularly, my bank, my government, the utilities
that provide my gas, electricity, and telephone service, the shops I
buy groceries from, the airlines and travel agents who organise my
vacations and business travel, and all the thousands of other computer
users who impact on my daily life, then I'll buy this "popularity
doesn't matter" argument. Until then, I have to (and for that matter,
choose to) exist in a social environment, and I suspect that the same
is true even for entrepreneurs.
-dan
--
"please make sure that the person is your friend before you confirm"
From: Christopher C. Stacy
Subject: Re: Popularity of programming languages
Date:
Message-ID: <u7jy91lmd.fsf@news.dtpq.com>
>>>>> On Thu, 26 Feb 2004 23:03:10 +0000, Daniel Barlow ("Daniel") writes:
Daniel> When I can find Lisp-using alternatives for [...]
Just because a program is written in Lisp, doesn't mean that it's
going to be better than a program written in some other language.
From: Joe Marshall
Subject: Re: Popularity of programming languages
Date:
Message-ID: <isht8lfz.fsf@comcast.net>
······@news.dtpq.com (Christopher C. Stacy) writes:
>>>>>> On Thu, 26 Feb 2004 23:03:10 +0000, Daniel Barlow ("Daniel") writes:
> Daniel> When I can find Lisp-using alternatives for [...]
>
> Just because a program is written in Lisp, doesn't mean that it's
> going to be better than a program written in some other language.
No, but....
A program written in a safe language like Lisp is less likely to have
type errors and buffer overruns than a program written in an unsafe
language.
--
~jrm
From: Tim Bradshaw
Subject: Re: Popularity of programming languages
Date:
Message-ID: <ey3ishs6cmw.fsf@cley.com>
* Joe Marshall wrote:
> A program written in a safe language like Lisp is less likely to have
> type errors and buffer overruns than a program written in an unsafe
> language.
Java. Better to concentrate on things that are actually
distinguishing features of Lisp rather than ones that were 20 years
ago.
(I know, loads of stuff is still in C/C++ &co, but those systems are
orders of magnitude more likely to migrate to Java than Lisp.)
--tim
Tim Bradshaw <···@cley.com> writes:
> * Joe Marshall wrote:
>
> > A program written in a safe language like Lisp is less likely to have
> > type errors and buffer overruns than a program written in an unsafe
> > language.
>
> Java. Better to concentrate on things that are actually
> distinguishing features of Lisp rather than ones that were 20 years
> ago.
>
> (I know, loads of stuff is still in C/C++ &co, but those systems are
> orders of magnitude more likely to migrate to Java than Lisp.)
>
> --tim
I have to wonder how many of those "systems [that] are orders of
magnitude more likely to migrate to Java than lisp" were originally
written in C or C++ because of speed considerations. :-)
--
Fred Gilham ······@csl.sri.com
We have a two party system. One party wants to drive the country
full-speed off a cliff. The other party wants to drive off the same
cliff, but insists on obeying the posted speed-limit.
From: Tim Bradshaw
Subject: Re: Popularity of programming languages
Date:
Message-ID: <ey31xogxzws.fsf@cley.com>
* Fred Gilham wrote:
> I have to wonder how many of those "systems [that] are orders of
> magnitude more likely to migrate to Java than lisp" were originally
> written in C or C++ because of speed considerations. :-)
My guess is that many C systems were, and will migrate, if they do,
because of cultural compatibility. C++ systems I'd guess were
generally done because it was OOP (and therefore fashionable at the
time), and compatible(ish) with C, but turned out to be an enormous
disaster. They'll migrate because they have to, and again, Java is
fairly culturally compatible.
I'd guess that C will survive for new systems in a niche: small
systems, anything which needs to be really close to the metal or
quick, glue code for Java &co esp stuff that has to talk to Unix. C
will also survive for large systems which are already in C, such as
the Unix kernel. C++ will be entirely displaced by Java except in
legacy systems.
--tim
Tim Bradshaw <···@cley.com> writes:
> I'd guess that C will survive for new systems in a niche: small
> systems, anything which needs to be really close to the metal or
> quick, glue code for Java &co esp stuff that has to talk to Unix. C
> will also survive for large systems which are already in C, such as
> the Unix kernel. C++ will be entirely displaced by Java except in
> legacy systems.
"and Windows programming, where it will be displaced by C#."?
I doubt Java is going to take over as the main language for writing
Windows apps. Could be wrong, though (or have missed context, of
course).
Cheers,
mwh
--
While preceding your entrance with a grenade is a good tactic in
Quake, it can lead to problems if attempted at work. -- C Hacking
-- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html
From: Tim Bradshaw
Subject: Re: Popularity of programming languages
Date:
Message-ID: <ey33c8wfi9t.fsf@cley.com>
* Michael Hudson wrote:D
> "and Windows programming, where it will be displaced by C#."?
> I doubt Java is going to take over as the main language for writing
> Windows apps. Could be wrong, though (or have missed context, of
> course).
Yes, I'd guess C# for windows.
--tim
Tim Bradshaw <···@cley.com> wrote:
> My guess is that many C systems were, and will migrate, if they do,
> because of cultural compatibility. C++ systems I'd guess were
> generally done because it was OOP (and therefore fashionable at the
> time), and compatible(ish) with C, but turned out to be an enormous
> disaster. They'll migrate because they have to, and again, Java is
> fairly culturally compatible.
> I'd guess that C will survive for new systems in a niche: small
> systems, anything which needs to be really close to the metal or
> quick, glue code for Java &co esp stuff that has to talk to Unix. C
> will also survive for large systems which are already in C, such as
> the Unix kernel. C++ will be entirely displaced by Java except in
> legacy systems.
Why? How is java so much better? In what way is C++ a "disaster" when
compared to the similarly widespread alternatives? The only major thing
Java has going for it in comparison to C++ (AFAICT) is garbage
collection, and the penalty for it is a language that is generally much
slower than lisp. If lisp is "too slow", how can anyone put up with
java?
Michael
·······@bcect.com (Michael Sullivan) writes:
> Why? How is java so much better? In what way is C++ a "disaster" when
> compared to the similarly widespread alternatives? The only major thing
> Java has going for it in comparison to C++ (AFAICT) is garbage
> collection, and the penalty for it is a language that is generally much
> slower than lisp. If lisp is "too slow", how can anyone put up with
> java?
A much bigger difference than GC between Java and C++ is the object
reference model. Getting rid of pointer diddling removes a huge class
of bugs, and makes things much easier for the programmer. In addition,
it allows certain optimizations with respect to aligned memory access
and object compaction that can't be done in the presence of pointer
dereferencing. A much less significant improvement is Java's stronger
type system (although it's still weak, in the sense that you can cast
anything to Object and back and not notice until run-time, if you
notice it at all). You can have garbage collection in C++ (the
Boehm-Demers-Weiser is the only one I am aware of, though) and forget
about destructors (this is what I do), but that's about the only
benefit you get. On the other hand, you can have a language with
Lisp-like uniform object referencing, but manual memory management
(I'm not aware of any, and also in this case you wouldn't be able to
take advantage of memory compaction).
As far as I know, Java is slow because the bytecode is required by
Sun, and nobody can do JIT compilation right (probably because the
bytecode was designed without much thought being given to it's
usefulness as an intermediary compilation target). Right now, this is
fast enough for some people (not fast enough for me - it's a dog on my
PIII 500Mhz system with half a gig of ram, while CMUCL + Paserve chug
along nicely on a P200 with 128Mbytes of memory - not that I'm able to
get the current release of the JRE for FreeBSD anyway). Also, most of
the performance comparisons I see for JITs and VMs are against
competition, which unsurprisingly makes small gains look like huge
leaps to the uninformed. In a few years, this will probably change (as
a nice side-benefit, we'll probably find out how to compile stack VMs
to native code really nicely).
> Michael
Vladimir
From: Tim Bradshaw
Subject: Re: Popularity of programming languages
Date:
Message-ID: <ey3oerjyph8.fsf@cley.com>
* Michael Sullivan wrote:
> Why? How is java so much better? In what way is C++ a "disaster" when
> compared to the similarly widespread alternatives?
No GC, no bounds checking by default. Overcomplex and obscure object
system. Constrained in all sorts of bad ways by compatibility with
C. Historically poor compatibility between implementations (including
the same implementation over time). C++ in the hands of average
programmers is even worse than C is.
> The only major thing
> Java has going for it in comparison to C++ (AFAICT) is garbage
> collection, and the penalty for it is a language that is generally much
> slower than lisp. If lisp is "too slow", how can anyone put up with
> java?
Languages are not slow, implementations may be. Garbage collection
and bounds checking are *huge* advantages. Combined with cultural
compatibility with C/C++ they make for a pretty good combination.
--tim
From: Joe Marshall
Subject: Re: Popularity of programming languages
Date:
Message-ID: <r7wh9akc.fsf@comcast.net>
Andr� Thieme <······································@justmail.de> writes:
> I would like to see if some people are maybe a bit disappointed that
> Lisp is so unpopular.
Nope. I'm a misanthrope, I enjoy watching people use Perl and C++.
> Maybe some even want to change it.
Whatever for?
--
~jrm
Andr� Thieme <······································@justmail.de> writes:
> Wade Humeniuk wrote:
>
> > Andr� Thieme wrote:
> >
> >> How does the popularity of a programming language affect this
> >> language? Wouldn't Lisp become even more usefull (more libs) if it
> >> had more users?
> >>
> > Why are you asking?
>
> I would like to hear some opinions about it.
> I would like to see if some people are maybe a bit disappointed that
> Lisp is so unpopular. Maybe some even want to change it. Or I might be
> surprised that noone really cares about the popularity and is not
> interested in helping to make Lisp more popular.
>
> And what is your opinion about it?
Actually, diamonds are not so popular. I don't have any and I would
not want to buy any. If you gave me one, first thing I'd do would be
to try to sell it. Are you disappointed that diamonds are so
unpopular?
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Andr� wrote:
> I would like to see if some people are maybe a bit
> disappointed that Lisp is so unpopular.
That is not good English. The word "popular" has various
meanings. One of my dictionaries offers
3. Liked or admired by the people or by people generally or
by specified class
4. prevalent among the people
Is Lisp popular or unpopular? Some say of Lisp "My only
regret is that I have but one life to lay down for Lisp ;-)"
while others ask of C++ "How many more billions of dollars
will be flushed down the sewer that is C++?".
Lisp easily beats C++ in popularity if you take meaning 3,
while C++ wins on meaning 4. So "popular" is a hopeless
choice of word.
It gets worse. An older dictionary offers
2. Suitable to or intended for common people; easy to be
comprehended; not technical or abstruse; plain; familiar:
as, a /popula/r treatise on astronomy
So one might might make the claim that Lisp is not popular
intending this as both a reason for it not being widely
deployed, and entirely appropriate to a powerful computer
programming language.
So, what was the question? (without using the word popular)
Alan Crowe
Edinburgh
Scotland
From: André Thieme
Subject: Re: Popularity of programming languages
Date:
Message-ID: <c1o0dj$cnd$1@ulric.tng.de>
Alan Crowe wrote:
> Andr� wrote:
>
>>I would like to see if some people are maybe a bit
>>disappointed that Lisp is so unpopular.
>
>
> That is not good English. The word "popular" has various
> meanings. One of my dictionaries offers
Yes, good point, thanks for informing me.
I am lucky that at least most posters understood by the context what I
wanted to say, which would be something like "widespread".
Andr�
Andr� Thieme <······································@justmail.de> writes:
> Yes, good point, thanks for informing me.
> I am lucky that at least most posters understood by the context what I
> wanted to say, which would be something like "widespread".
Which would place it in the company of such august concepts as
"unix", "hotmail", "malaria", "hydrogen", "stupidity" and "reality tv".
Way to go!
-dan
--
"please make sure that the person is your friend before you confirm"
Daniel Barlow <···@telent.net> writes:
> Andr� Thieme <······································@justmail.de> writes:
> > Yes, good point, thanks for informing me.
> > I am lucky that at least most posters understood by the context what I
> > wanted to say, which would be something like "widespread".
>
> Which would place it in the company of such august concepts as
> "unix", "hotmail", "malaria", "hydrogen", "stupidity" and "reality tv".
(substitute "unix" "windows")
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
On Sun, 29 Feb 2004 05:09:16 +0000, David Steuber wrote:
> Daniel Barlow <···@telent.net> writes:
>
>> Andr� Thieme <······································@justmail.de> writes:
>> > Yes, good point, thanks for informing me.
>> > I am lucky that at least most posters understood by the context what I
>> > wanted to say, which would be something like "widespread".
>>
>> Which would place it in the company of such august concepts as
>> "unix", "hotmail", "malaria", "hydrogen", "stupidity" and "reality tv".
>
> (substitute "unix" "windows")
You would have done better to just add windows.
Unix fits in there quite nicely. ;-)
Andr� Thieme wrote:
> Alan Crowe wrote:
>
>> Andr� wrote:
>>
>>> I would like to see if some people are maybe a bit
>>> disappointed that Lisp is so unpopular.
>>
>> That is not good English. The word "popular" has various
>> meanings. One of my dictionaries offers
>
> Yes, good point, thanks for informing me.
> I am lucky that at least most posters understood by the context what I
> wanted to say, which would be something like "widespread".
The fact that Common Lisp is not so widespread has both advantages and
disadvantages.
Advantages: You can be one of the early adoptors in a new generation of
Common Lisp users. Common Lisp was mainly used by big companies and
research institutes on big and expensive machines until the AI Winter in
the late 80's. Since a few years, consumer hardware is powerful enough
to run Common Lisp so that people don't even care anymore to run
software that sucks up more resources than languages like Common Lisp
ever did. So we have achieved a turning point that effectively makes
Common Lisp a new language in the sense that it is now usable in a very
different market. Other languages are currently more widespread because
they have gained popularity in times in which resource constraints were
still important factors to balance against. On the other hand, you can
recognize that widespread languages have evolved to become ever more
flexible over time. Lisp-like languages are arguably among the logically
next steps.
Being an early adoptor means that you can learn important skills earlier
than other people, and make yourself easily a good name because you are
not just the next Joe Java. Any substantial contribution to this
community immediately makes you a recognized expert in the area that you
choose.
Disadvantages: This all takes more work and time. That's always the case
when you take risks. As Richard Gabriel once told me, "only the
creatively intelligent can prosper in the Lisp world."
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Disadvantages: This all takes more work and time. That's always the
> case when you take risks. As Richard Gabriel once told me, "only the
> creatively intelligent can prosper in the Lisp world."
I sure hope that doesn't leave me out in the cold.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
"Andr� Thieme" <······································@justmail.de> wrote in
message ·················@ulric.tng.de...
> How does the popularity of a programming language affect this language?
> Wouldn't Lisp become even more usefull (more libs) if it had more users?
>
> This website tries to measure the popularity of some programming
languages:
> http://www.tiobe.com/tpci.htm
>
>
> Andr�
The web site uses the Google search:
+"<language> programming" -tv
to construct statistics. The search is done both upon general web pages and
upon Google groups. If one wishes Lisp to be more "popular":
Do: Use a signature including "Lisp Programming"
Don't: Include "tv" in the post
*sigh*
Andr� Thieme <······································@justmail.de> writes:
> How does the popularity of a programming language affect this
> language? Wouldn't Lisp become even more usefull (more libs) if it had
> more users?
Regardless of Lisp's popularity, new libraries *are* coming. See for
example the increasing number of projects hosted at Common-Lisp.net.
> This website tries to measure the popularity of some programming languages:
> http://www.tiobe.com/tpci.htm
Garbage in, garbage out.
Consider this gem from that page: "The index can be used to rate
whether [...] to make a strategic decision about what programming
language should be adopted when starting to build a new software
system." I'd be really interested in knowing which companies make such
strategic decisions based on Google queries.
Despite alternating popularity, recessions, market downturns, the AI
Winter and active bashing, Lisp is still around after over four
decades. And there are 9 *commercial* Lisp vendors still in business.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso wrote:
> Despite alternating popularity, recessions, market downturns, the AI
> Winter and active bashing, Lisp is still around after over four
> decades. And there are 9 *commercial* Lisp vendors still in business.
It's 2004. We can start to say "nearly five decades". ;)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Duane Rettig
Subject: Re: Popularity of programming languages
Date:
Message-ID: <4oerlfnsa.fsf@franz.com>
Pascal Costanza <········@web.de> writes:
> Paolo Amoroso wrote:
>
> > Despite alternating popularity, recessions, market downturns, the AI
> > Winter and active bashing, Lisp is still around after over four
> > decades. And there are 9 *commercial* Lisp vendors still in business.
>
> It's 2004. We can start to say "nearly five decades". ;)
Nah... "nearly half a century!"
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
"Duane Rettig" <·····@franz.com> wrote in message
··················@franz.com...
> Pascal Costanza <········@web.de> writes:
>
> > Paolo Amoroso wrote:
> >
> > > Despite alternating popularity, recessions, market downturns, the AI
> > > Winter and active bashing, Lisp is still around after over four
> > > decades. And there are 9 *commercial* Lisp vendors still in business.
> >
> > It's 2004. We can start to say "nearly five decades". ;)
>
> Nah... "nearly half a century!"
No no no!
"A generation of development"
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> "Duane Rettig" <·····@franz.com> wrote in message
> ··················@franz.com...
>
>>Pascal Costanza <········@web.de> writes:
>>
>>
>>>Paolo Amoroso wrote:
>>>
>>>
>>>>Despite alternating popularity, recessions, market downturns, the AI
>>>>Winter and active bashing, Lisp is still around after over four
>>>>decades. And there are 9 *commercial* Lisp vendors still in business.
>>>
>>>It's 2004. We can start to say "nearly five decades". ;)
>>
>>Nah... "nearly half a century!"
>
>
> No no no!
>
> "A generation of development"
Bah, that one is due for collection. C'mon, we're approaching Lisp's
Golden Anniversary.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Ray Dillinger
Subject: Re: Popularity of programming languages
Date:
Message-ID: <40455DB7.8C50E3F0@sonic.net>
André Thieme wrote:
>
> How does the popularity of a programming language affect this language?
> Wouldn't Lisp become even more usefull (more libs) if it had more users?
>
Not if the users were idiots. Nothing is more damaging to a language
than a bunch of dummies who want it to be easy for *them* to understand.
If you pander to them, you eventually wind up with COBOL. Or Visual
Basic -- pathetically limited languages which are, nevertheless, easy
to understand. Their popularity (with idiots) both resulted from and
forced them to be what they became.
Bear
Ray Dillinger <····@sonic.net> writes:
> Andr� Thieme wrote:
> >
> > How does the popularity of a programming language affect this language?
> > Wouldn't Lisp become even more usefull (more libs) if it had more users?
> >
>
> Not if the users were idiots. Nothing is more damaging to a language
> than a bunch of dummies who want it to be easy for *them* to understand.
> If you pander to them, you eventually wind up with COBOL. Or Visual
> Basic -- pathetically limited languages which are, nevertheless, easy
> to understand. Their popularity (with idiots) both resulted from and
> forced them to be what they became.
The majority of humans are idiots. Success comes from creating
something that idiots will pay for.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
From: Ray Dillinger
Subject: Re: Popularity of programming languages
Date:
Message-ID: <4047571D.3AD32595@sonic.net>
David Steuber wrote:
>
>
> The majority of humans are idiots. Success comes from creating
> something that idiots will pay for.
Welcome to my quote file. :-)
Bear