> I get the impression that larger Lisp projects will not approach the team size you mention above.
Evidence from for example the AT&T switching project is that a team of one hundred working with Lisp technology is as productive as a team of 1000 working in C++ technology (building ATM switching systems).
The hard part is to keep the technology alive over a longer period of time inside a company, since most companies are not prepared to use Lisp technology at that scale.
Because you define the term "marketplace"
(nice in combination with "free") for
yourself?
> Because the lisp community (with exceptions) has never understood free (libre) software.
How does it come then that there are so many
free Lisp systems (alone for Common Lisp
there are GCL, CMUCL, CLisp, SBCL, ECL,...)
and Lisp software? Tons of Scheme systems
(the complex MIT Scheme, the Scheme Shell scsh,
the cross platform DrScheme, the tiny
SIOD,...).
> Where is GNU ? Everywhere!
Actually not on my computers - GNU software
is not really "free" - one is bound by
the GPL.
Anyway, what do we see?
Guile (a Scheme implementation,
which is, hmm, a Lisp dialect) is the "official"
scripting language (remember GIMP?) for GNU.
Emacs and XEmacs are **widely** used. Weren't
they mostly Lisp programs?
> Most people who work on free software do so because they benefit from it directly. It gives them features they need.
Dream on.
> So what is better (1) enrich yourself at other people's expense or (2) enrich yourself and others? Wake up lispers!
I guess you should just forget your romantic
ideas.
There is Lisp software out there.
I applaud more the guys who are maintaining
the CMUCL and CLisp (drives for example Yahoo Store) implementations - both excellent and free,
instead a random guy who has no idea what he
is talking about.
Common Lisp is a multi-paradigm language.
It *supports* Functional, Imperative and
Object-Oriented Programming. It does not
*enforce* their usage, but offers a good
substrate for programming in those styles.
Lisp does not offer any built-in support
for Logical Programming - but there are
tons of extensions for doing it.
> LISP has no typing,
Well, that's wrong. Lisp has "typing". Read
the Common Lisp ANSI standard.
> function arity, partial evaluation,
These are easy to do.
> composition,
Sure it has.
> list comprehension,
This is only syntactic sugar.
> or even function predicates
> (not sure if that's the right name, it's
> where it only applies the function if the
> predicate matches).
Again only sugar - trivial to implement.
> Sure you can do all of those in lisp, but you have to do it by hand.
Yes, but it is damn easy and it has been done
a thousand times already.
> I could do the same in python, java, or even C, if I were wont to do such grunt work by hand.
Lisp has functions as first-class values and a
bendable syntax - so this is all trivial in Lisp.
The ANSI CL standard already has 1500 pages -
if the Lisp community standardizes all kinds
of random features that are available, it would
be more in the range of 25000 pages.
Haskell and some other languages are not
"more" "functional languages" compared
to Lisp - but they offer a different view
on Functional Programming (enforcing FP,
statically typed, non-strict, complex syntax,
...). Some of those languages have been
implemented on top of Lisp.
> lisp to me feels like pascal with prefix syntax.
The comparision is flawed:
Pascal even does not *support*
Functional Programming.
Haskell feels to me like a statically typed,
non-strict Lisp. YMMV.
> Perhaps you are correct -- I haven't programmed professionally in Lisp for 16 years. But back then Lisp certainly did not
Well, 16 years is some time, isn't it?;-)
> It is very difficult to make an efficient and portable non-reference-counting garbage collector.
I'd say, that the performance of Python is so "bad" (it's not native compiled and VM based), that a reference counting memory management can't make it much worse. Still for a lot of tasks the performance may look good enough. This changes if more of the code stops using built-in mechanisms, but instead relies on user code. The built-in code is written in C and usually several times more efficient, than the Python code, which runs on the VM. This can also be seen in VM-based Common Lisp implementations.
Reference counting has advantages. But it also has severe drawbacks. For a discussion of these issues see the book "Garbage Collection, Algorithms for Automatic Dynamic Memory Management" from Richard Jones and Rafael Lins. See also:
> that GC'ed languages should have ref-counted garbage collectors as their main garbage collectors
I hope not. Lisp and Smalltalk systems nowadays have much more sophisticated GCs. The Lisp I'm using on the Mac has a Incremental Generational Ephemeral;-) GC plus a Mark and Sweep GC. The Ephemeral GC goes after short lived objects in RAM (and uses the MMU to find changed pages) and runs almost unnoticably.
I agree that it would be better if all variables
had to be declared before being assigned to. Not
enforcing this causes bugs due to typos that would
otherwise be immediately discovered by the
interpreter. But Python is far from the only
language with this flaw. Most dialects of Lisp (not
including Scheme) and Perl also suffer from this
problem
Most Lisp compilers tell you about undeclared variables.
? (defun foo (baz) bar)
;Compiler warnings :
; Undeclared free variable BAR, in FOO.
; Unused lexical variable BAZ, in FOO.
Regarding functions picking up their enclosing
lexical variables, this would certainly also
be nice, but is really not much more than a
nicety.
Sure not. It is one of the essences of
Functional Programming.
Despite this, full lexical scoping and true
garbage collection are on the slate for future
versions of Python. How this can be done
without damaging Python's efficiency and
portability remains to be seen.
Funny, Python's efficiency (without native code
compilers;-) )? If you look through the
GC literature you see that reference counting
is considered not to be the memory management
algorithm of choice (besides some special uses).
*Real* GCs are considered more efficient. Reference
Counting originally has been developed for Lisp
in 1960. Nowadays almost no Lisp uses reference
counting anymore - go figure. Reference
counting does not deal with cycles, etc.
Well, lexical scoping... I think it helps
to read the original articles on Scheme and
one might understand why all modern Lisps
(ANSI Common Lisp, Dylan, EuLisp, Scheme,
ISLisp,...) now default to lexical scoping.
I guess, after some design iterations Python
will look like a blend between Haskell and Lisp.
;-)
>Even compiled LISP still has the equivalent of (eval 'symbol) which is a lookup from a symbol... this is another example of its interpreted legacy. A compiled C++ program doesn't need to keep the symbol table around!
How one accesses symbol values has nothing to do with interpretation or compilation. Why dont you just read a bit literature about Lisp compilation (like "Lisp In Small Pieces) and I guess things will be more clear. Variable access through symbol tables happens only if you are accessing global variables. Local variables are accessed directly from the current lexical or dynamic environment.
Common Lisp is a dynamic programming language - that means, a lot of things can be changed at runtime - Lisp implementations also have means to compile some of these dynamisms away. This is a language design decision and has nothing to do with being compiled or interpreted.
There are a lot Common Lisp compilers (see http://www.lisp.org) - especially many of them are available for Linux. Here are some Lisps with compilers: GCL, CMU CL, LispWorks, ACL, CLICC, CLisp, SCL, Liquid Common Lisp, MCL,...Systems like MCL are compiling *everything* by default. CLICC is just a batch compiler.
Slashdot Mirror
> I get the impression that larger Lisp projects will not approach the team size you mention above.
Evidence from for example the AT&T switching project is that a team of one hundred working with Lisp technology is as productive as a team of 1000 working in C++ technology (building ATM switching systems).
The hard part is to keep the technology alive over a longer period of time inside a company, since most companies are not prepared to use Lisp technology at that scale.
> How come it has so few users,
...)
...).
It has a lot of users - you would be surprised.
> and nearly no presence in the marketplace?
Because you define the term "marketplace"
(nice in combination with "free") for
yourself?
> Because the lisp community (with exceptions) has never understood free (libre) software.
How does it come then that there are so many
free Lisp systems (alone for Common Lisp
there are GCL, CMUCL, CLisp, SBCL, ECL,
and Lisp software? Tons of Scheme systems
(the complex MIT Scheme, the Scheme Shell scsh,
the cross platform DrScheme, the tiny
SIOD,
> Where is GNU ? Everywhere!
Actually not on my computers - GNU software
is not really "free" - one is bound by
the GPL.
Anyway, what do we see?
Guile (a Scheme implementation,
which is, hmm, a Lisp dialect) is the "official"
scripting language (remember GIMP?) for GNU.
Emacs and XEmacs are **widely** used. Weren't
they mostly Lisp programs?
> Most people who work on free software do so because they benefit from it directly. It gives them features they need.
Dream on.
> So what is better (1) enrich yourself at other people's expense or (2) enrich yourself and others? Wake up lispers!
I guess you should just forget your romantic
ideas.
There is Lisp software out there.
I applaud more the guys who are maintaining
the CMUCL and CLisp (drives for example Yahoo Store) implementations - both excellent and free,
instead a random guy who has no idea what he
is talking about.
> That's debateable.
Common Lisp is a multi-paradigm language.
It *supports* Functional, Imperative and
Object-Oriented Programming. It does not
*enforce* their usage, but offers a good
substrate for programming in those styles.
Lisp does not offer any built-in support
for Logical Programming - but there are
tons of extensions for doing it.
> LISP has no typing,
Well, that's wrong. Lisp has "typing". Read
the Common Lisp ANSI standard.
> function arity, partial evaluation,
These are easy to do.
> composition,
Sure it has.
> list comprehension,
This is only syntactic sugar.
> or even function predicates
> (not sure if that's the right name, it's
> where it only applies the function if the
> predicate matches).
Again only sugar - trivial to implement.
> Sure you can do all of those in lisp, but you have to do it by hand.
Yes, but it is damn easy and it has been done
a thousand times already.
> I could do the same in python, java, or even C, if I were wont to do such grunt work by hand.
Lisp has functions as first-class values and a
bendable syntax - so this is all trivial in Lisp.
The ANSI CL standard already has 1500 pages -
if the Lisp community standardizes all kinds
of random features that are available, it would
be more in the range of 25000 pages.
Haskell and some other languages are not
"more" "functional languages" compared
to Lisp - but they offer a different view
on Functional Programming (enforcing FP,
statically typed, non-strict, complex syntax,
...). Some of those languages have been
implemented on top of Lisp.
> lisp to me feels like pascal with prefix syntax.
The comparision is flawed:
Pascal even does not *support*
Functional Programming.
Haskell feels to me like a statically typed,
non-strict Lisp. YMMV.
> Perhaps you are correct -- I haven't programmed professionally in Lisp for 16 years. But back then Lisp certainly did not
;-)
r y/r.html#reference.counting
;-) GC plus a Mark and Sweep GC. The Ephemeral GC goes after short lived objects in RAM (and uses the MMU to find changed pages) and runs almost unnoticably.
Well, 16 years is some time, isn't it?
> It is very difficult to make an efficient and portable non-reference-counting garbage collector.
I'd say, that the performance of Python is so "bad" (it's not native compiled and VM based), that a reference counting memory management can't make it much worse. Still for a lot of tasks the performance may look good enough. This changes if more of the code stops using built-in mechanisms, but instead relies on user code. The built-in code is written in C and usually several times more efficient, than the Python code, which runs on the VM. This can also be seen in VM-based Common Lisp implementations.
Reference counting has advantages. But it also has severe drawbacks. For a discussion of these issues see the book "Garbage Collection, Algorithms for Automatic Dynamic Memory Management" from Richard Jones and Rafael Lins. See also:
http://www.xanalys.com/software_tools/mm/glossa
> that GC'ed languages should have ref-counted garbage collectors as their main garbage collectors
I hope not. Lisp and Smalltalk systems nowadays have much more sophisticated GCs. The Lisp I'm using on the Mac has a Incremental Generational Ephemeral
I agree that it would be better if all variables
;-) )? If you look through the
...) now default to lexical scoping.
had to be declared before being assigned to. Not
enforcing this causes bugs due to typos that would
otherwise be immediately discovered by the
interpreter. But Python is far from the only
language with this flaw. Most dialects of Lisp (not
including Scheme) and Perl also suffer from this
problem
Most Lisp compilers tell you about undeclared variables.
? (defun foo (baz) bar)
;Compiler warnings :
; Undeclared free variable BAR, in FOO.
; Unused lexical variable BAZ, in FOO.
Regarding functions picking up their enclosing
lexical variables, this would certainly also
be nice, but is really not much more than a
nicety.
Sure not. It is one of the essences of
Functional Programming.
Despite this, full lexical scoping and true
garbage collection are on the slate for future
versions of Python. How this can be done
without damaging Python's efficiency and
portability remains to be seen.
Funny, Python's efficiency (without native code
compilers
GC literature you see that reference counting
is considered not to be the memory management
algorithm of choice (besides some special uses).
*Real* GCs are considered more efficient. Reference
Counting originally has been developed for Lisp
in 1960. Nowadays almost no Lisp uses reference
counting anymore - go figure. Reference
counting does not deal with cycles, etc.
Well, lexical scoping... I think it helps
to read the original articles on Scheme and
one might understand why all modern Lisps
(ANSI Common Lisp, Dylan, EuLisp, Scheme,
ISLisp,
I guess, after some design iterations Python
will look like a blend between Haskell and Lisp.
;-)
>Even compiled LISP still has the equivalent of (eval 'symbol) which is a lookup from a symbol ... this is another example of its interpreted legacy. A compiled C++ program doesn't need to keep the symbol table around!
...Systems like MCL are compiling *everything* by default. CLICC is just a batch compiler.
How one accesses symbol values has nothing to do with interpretation or compilation. Why dont you just read a bit literature about Lisp compilation (like "Lisp In Small Pieces) and I guess things will be more clear. Variable access through symbol tables happens only if you are accessing global variables. Local variables are accessed directly from the current lexical or dynamic environment.
Common Lisp is a dynamic programming language - that means, a lot of things can be changed at runtime - Lisp implementations also have means to compile some of these dynamisms away. This is a language design decision and has nothing to do with being compiled or interpreted.
There are a lot Common Lisp compilers (see http://www.lisp.org) - especially many of them are available for Linux. Here are some Lisps with compilers: GCL, CMU CL, LispWorks, ACL, CLICC, CLisp, SCL, Liquid Common Lisp, MCL,