How long (measured in lines of code) is the longest CL program you know
of? I basically want to know for what projects CL could be the language
of choice. This if of pure theoretical interest for me as I don't plan
to start a ten million loc project any time soon ;)
In OCaml I know of two middle sized applications:
a compiler with 250k lines and a theorem prover with 300k lines.
In languages like Java or C++ some programs count millions of lines of
code (the Mozilla browser has around 30 millions). I don't know if this
is a coincident that these languages are all statically typed...
I know that Lisp programs tend to be in some cases _much_ smaller than a
C++ counterpart. Anyway, are there any Lisp programs beyond the 500k
lines mark?
Regards,
Andr�
In article <············@ulric.tng.de>, Andr� Thieme
<······································@justmail.de> wrote:
> How long (measured in lines of code) is the longest CL program you know
> of? I basically want to know for what projects CL could be the language
> of choice. This if of pure theoretical interest for me as I don't plan
> to start a ten million loc project any time soon ;)
>
> In OCaml I know of two middle sized applications:
> a compiler with 250k lines and a theorem prover with 300k lines.
> In languages like Java or C++ some programs count millions of lines of
> code (the Mozilla browser has around 30 millions). I don't know if this
> is a coincident that these languages are all statically typed...
>
> I know that Lisp programs tend to be in some cases _much_ smaller than a
> C++ counterpart. Anyway, are there any Lisp programs beyond the 500k
> lines mark?
SBCL: 241787 total
CMUCL: 393941 total
McCLIM: 78544 total
Maxima: 209297 total
I think these are probably the Mozillas of the CL world. I can't think
of any larger CL projects OTOH.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
> SBCL: 241787 total
> CMUCL: 393941 total
> McCLIM: 78544 total
> Maxima: 209297 total
>
> I think these are probably the Mozillas of the CL world. I can't think
> of any larger CL projects OTOH.
So these compilers implement themself in Lisp?
Do you have an idea why there is not a one million loc project done in
Lisp? I mean, when it is possible to get up an application at 200k lines
it could probably mean that it is even possible to climb up in
code-length...
Thanks for your numbers!
In article <············@ulric.tng.de>, Andr� Thieme
<······································@justmail.de> wrote:
> Brian Mastenbrook wrote:
>
> > SBCL: 241787 total
> > CMUCL: 393941 total
> > McCLIM: 78544 total
> > Maxima: 209297 total
> >
> > I think these are probably the Mozillas of the CL world. I can't think
> > of any larger CL projects OTOH.
>
> So these compilers implement themself in Lisp?
I counted only the Lisp portion. SBCL in particular is ANSI Common Lisp
and bootstraps from OpenMCL and a few non-buggy versions of clisp. Yes,
these compilers are implemented in Lisp... that is the norm.
> Do you have an idea why there is not a one million loc project done in
> Lisp? I mean, when it is possible to get up an application at 200k lines
> it could probably mean that it is even possible to climb up in
> code-length...
Probably lack of need or desire to work on a program that large. I
would guess that certain large commercial applications might get
larger, but who knows? In the meantime these projects are large enough
as they are.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
"Brian Mastenbrook" <····················@cs.indiana.edu> wrote in message
············································@cs.indiana.edu...
> In article <············@ulric.tng.de>, Andr� Thieme
> <······································@justmail.de> wrote:
> > So these compilers implement themself in Lisp?
>
> I counted only the Lisp portion. SBCL in particular is ANSI Common Lisp
> and bootstraps from OpenMCL and a few non-buggy versions of clisp. Yes,
> these compilers are implemented in Lisp... that is the norm.
There's actually another point, perhaps, to be made.
For my little project, the core of the system is 1750 lines of what folks
would consider "code".
But, I also have ~5000 lines of "data". But the data is coded using Lisp
macros, so...it's really Lisp.
If someone had written my system in C (or most anything else), they would
have inevitably used some other format for their data other than their
language syntax. Some grammar they had to parse, or something else (like
XML) that they could parse "for free".
Also, it's fair to say that my system had no user interface. No GUI,
"command line", nothing. Anything I scripted was done using a simple Lisp
function wrapper. It lived solely in the listener and relied on it for its
interactions with the user. It also, of course, relied upon the editor for
the source files.
So, I got a "free" grammar to help me represent my data, and "free" UI,
neither of which I had to code at all.
I don't think there's anything inherent in CL that would prevent a system
from reaching a million LOC, but I'm more impressed with what it did for me
in 1750.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> I don't think there's anything inherent in CL that would prevent a system
> from reaching a million LOC, but I'm more impressed with what it did for me
> in 1750.
Well said!
Sometimes it's the little thing that is the big thing.
My set of temporal logic code is about 15000 LOC.
There are a lot of duplications and the code needs refactoring, but that
is pretty much what I came up with.
I have other separate projects that are samller, but not so much.
Cheers
Marco
Andr� Thieme wrote:
> Will Hartung wrote:
>
>> I don't think there's anything inherent in CL that would prevent a system
>> from reaching a million LOC, but I'm more impressed with what it did
>> for me
>> in 1750.
>
>
> Well said!
> Sometimes it's the little thing that is the big thing.
Andr� Thieme wrote:
>
> Brian Mastenbrook wrote:
>
> > SBCL: 241787 total
> > CMUCL: 393941 total
> > McCLIM: 78544 total
> > Maxima: 209297 total
> >
> > I think these are probably the Mozillas of the CL world. I can't think
> > of any larger CL projects OTOH.
>
> So these compilers implement themself in Lisp?
>
> Do you have an idea why there is not a one million loc project done in
> Lisp? I mean, when it is possible to get up an application at 200k lines
> it could probably mean that it is even possible to climb up in
> code-length...
Ah, but there is not yet in the universe enough functionality required
for 1m LOC to cover.
Don't forget the whole CL language is there, too, and that replaces a
lot of code. Then you have macros, which let you extend the language
even closer towards the functional domain (and who knows how many lines
of code they (the macros) write.
If anyone can figure out how to count LOC in a directory tree on
win32... hmm, a lisp function to count carriage returns? That would give
us the LOC for CliniSys, which does a rather astonishing amount of work.
Stand by (i've always been curious)... but I'll wait to learn if there
is a DOS function or win32 utility ...wingrep counting CRs? hmmm....
kt
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> Andr� Thieme wrote:
> >
> > Brian Mastenbrook wrote:
> >
> > > SBCL: 241787 total
> > > CMUCL: 393941 total
> > > McCLIM: 78544 total
> > > Maxima: 209297 total
> > >
> > > I think these are probably the Mozillas of the CL world. I can't think
> > > of any larger CL projects OTOH.
> >
> > So these compilers implement themself in Lisp?
> >
> > Do you have an idea why there is not a one million loc project done in
> > Lisp? I mean, when it is possible to get up an application at 200k lines
> > it could probably mean that it is even possible to climb up in
> > code-length...
>
> Ah, but there is not yet in the universe enough functionality required
> for 1m LOC to cover.
If there's ever a 1e6 LOC Lisp program, it'll be either a horrible
shame, or the herald of a new era of software engineering, where we
can manage insane amounts of complexity.
In the <<2k LOC area, I tend to write verbose code. With larger
systems, I'm proud of every line I remove. Big abstractions are
wonderful. I once rewrote a C++ program that weighed in at ~250k LOC
(about average, some great parts, a lot of normal bits) to be a < 10k
LOC Common Lisp program. I was insufferable.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Andr� Thieme wrote:
> > >
> > > Brian Mastenbrook wrote:
> > >
> > > > SBCL: 241787 total
> > > > CMUCL: 393941 total
> > > > McCLIM: 78544 total
> > > > Maxima: 209297 total
> > > >
> > > > I think these are probably the Mozillas of the CL world. I can't think
> > > > of any larger CL projects OTOH.
> > >
> > > So these compilers implement themself in Lisp?
> > >
> > > Do you have an idea why there is not a one million loc project done in
> > > Lisp? I mean, when it is possible to get up an application at 200k lines
> > > it could probably mean that it is even possible to climb up in
> > > code-length...
> >
> > Ah, but there is not yet in the universe enough functionality required
> > for 1m LOC to cover.
>
> If there's ever a 1e6 LOC Lisp program, it'll be either a horrible
> shame, or the herald of a new era of software engineering, where we
> can manage insane amounts of complexity.
Oh, I would guess that there are several Lisp applications that are
quite a bit larger than 1e6 LOC.
A 'simple' game like Jak II already is about 900000 LOC of GOAL
(a Lisp dialect).
You can only guess what amount of Lisp code has been written for,
say, Cyc during its twenty (!) years of development or for some of
the commercial/military scheduling/planning applications.
Thomas F. Burdick wrote:
> If there's ever a 1e6 LOC Lisp program, it'll be either a horrible
> shame, or the herald of a new era of software engineering, where we
> can manage insane amounts of complexity.
I'm sure there are already systems that big, they're sizes are just
not in the public domain. They also probably won't be individual
programs, but large systems of programs. As an example, how big is
something like a modern Unix system? If you count just the kernel,
it's probably not that huge, even in C. But the kernel is not the
whole system (how usefiul is a naked Unix kernel? not very): you
should count all the utilities and so on too. The famous `Windows is
vast' trick is based on this. Yes it *is* vast, but that's *not* just
the kernel.
Or, to put it another way: a full xemacs distribution has over 1.5
million lines of emacs lisp (this is 21.4.12 + whatever version of the
sumo lisp packages my predecessor installed I think).
--tim
Kenny Tilton wrote:
>
> Andr� Thieme wrote:
> >
> > Brian Mastenbrook wrote:
> >
> > > SBCL: 241787 total
> > > CMUCL: 393941 total
> > > McCLIM: 78544 total
> > > Maxima: 209297 total
> > >
> > > I think these are probably the Mozillas of the CL world. I can't think
> > > of any larger CL projects OTOH.
> >
> > So these compilers implement themself in Lisp?
> >
> > Do you have an idea why there is not a one million loc project done in
> > Lisp? I mean, when it is possible to get up an application at 200k lines
> > it could probably mean that it is even possible to climb up in
> > code-length...
>
> Ah, but there is not yet in the universe enough functionality required
> for 1m LOC to cover.
>
Damn. CliniSys is only 70k LOC. I must be slowing down. Here is what it
includes:
- Cells!
- ModelGraphics (a GUI from scratch, including tab controls, scrollbars,
textedit widgets, list and tree views, etc etc)
- A typesetting language to easily generate WYSIWYG forms. The
typesetting language is really a document authoring language. It also
specifies ICR (for automatic training and recognition of forms),
validation, and storage in an ODB. ie, the code also identifies scanned
documents automatically via 2d barcodes, chops the scanned images up
field by field for the ICR library (3rd party) to "read", then stores
the results.
- A browser application from which documents are printed, scanned,
edited.
- Workgroup capabilities, allowing remote users to inquire about issues
with documents. Also an internal mail capability (for security).
- A homebrew partial replication scheme for the distributed DB so
everyone has the data on site, for performance and system availability.
- A system and process documentation browser, for guidance on how other
documents are to be collected and managed
- Rule-based enforcement of "good clinical practice"
That looks like it might be ten times less than what I would expect from
C/C++/Java, based on the 100k LOC C app I once developed.
kt
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> If anyone can figure out how to count LOC in a directory tree on
> win32... hmm, a lisp function to count carriage returns? That would give
> us the LOC for CliniSys, which does a rather astonishing amount of work.
> Stand by (i've always been curious)... but I'll wait to learn if there
> is a DOS function or win32 utility ...wingrep counting CRs? hmmm....
>
Well you could go here: http://www.microsoft.com/windows/sfu and install
the unix package then type
wc -l `find . -name '*.cl' `
and look at the last line to start.
marc
Marc Spitzer wrote:
> Well you could go here: http://www.microsoft.com/windows/sfu and install
> the unix package then type
>
> wc -l `find . -name '*.cl' `
>
> and look at the last line to start.
Alas, I have no Unix system available to try this out.
Marc, could you maybe provide the numbers? Would be very nice :)
Andr� Thieme <······································@justmail.de> writes:
> Marc Spitzer wrote:
>
> > Well you could go here: http://www.microsoft.com/windows/sfu and install
> > the unix package then type wc -l `find . -name '*.cl' `
> > and look at the last line to start.
>
>
> Alas, I have no Unix system available to try this out.
Which is where SFU helps - it is a collection of Unix tools for
Windows, much like cygwin.
Andr� Thieme <······································@justmail.de> writes:
> Do you have an idea why there is not a one million loc project done in
> Lisp? I mean, when it is possible to get up an application at 200k
> lines it could probably mean that it is even possible to climb up in
> code-length...
The system I'm involved with is 100,000 lines, (including blanks
and comments).
Last year we rewrote the UI from a Java/CORBA solution in
portable aserve. We scrapped almost 100,000 lines of java,
and rewrote it in 10,000 lines of lisp.
In the past, I was involved with a 500,000 lines C++ project
which implemented _far_ fewer function points than our current
system does.
Maybe there are not many large lisp systems because they don't
need to be large?
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Brian Mastenbrook <····················@cs.indiana.edu> writes:
> Andr� Thieme writes:
>> Anyway, are there any Lisp programs beyond the 500k lines mark?
>
> SBCL: 241787 total
> CMUCL: 393941 total
> McCLIM: 78544 total
> Maxima: 209297 total
>
> I think these are probably the Mozillas of the CL world. I can't think
> of any larger CL projects OTOH.
Not a Common Lisp program, but still Lisp:
Emacs: 890.263 total
(There's 337.792 lines of C in addition to that).
On Mon, 26 Jan 2004 18:44:28 -0500, Brian Mastenbrook wrote:
>>In article <············@ulric.tng.de>, Andr� Thieme
>> How long (measured in lines of code) is the longest CL program you know
>> of? I basically want to know for what projects CL could be the language
>> of choice. This if of pure theoretical interest for me as I don't plan
>> to start a ten million loc project any time soon ;)
>> I know that Lisp programs tend to be in some cases _much_ smaller than a
>> C++ counterpart. Anyway, are there any Lisp programs beyond the 500k
>> lines mark?
>
> SBCL: 241787 total
> CMUCL: 393941 total
> McCLIM: 78544 total
> Maxima: 209297 total
>
> I think these are probably the Mozillas of the CL world. I can't think
> of any larger CL projects OTOH.
For comparision, Symbolics Genera 8.3 .lisp sources are about
460000 lines, mostly ZetaLisp, though.
--
On Tue, 27 Jan 2004 02:31:35 +0200, Martti Halminen <···············@kolumbus.fi> wrote:
> For comparision, Symbolics Genera 8.3 .lisp sources are about 460000
> lines, mostly ZetaLisp, though.
That'd be the whole OS including GUI, Lisp runtime and compiler?
That's very impressive!
Edi.
On Tue, 27 Jan 2004 01:46:41 +0100, Edi Weitz wrote:
> On Tue, 27 Jan 2004 02:31:35 +0200, Martti Halminen <···············@kolumbus.fi> wrote:
>
>> For comparision, Symbolics Genera 8.3 .lisp sources are about 460000
>> lines, mostly ZetaLisp, though.
>
> That'd be the whole OS including GUI, Lisp runtime and compiler?
Yeah, that was the contents of my sys.sct directory, seems to
contain pretty much everything (CLIM -directory is empty, but
C, Pascal and Fortran compilers are also included in the count...).
--
On Tue, 27 Jan 2004 01:46:41 +0100, Edi Weitz wrote:
> On Tue, 27 Jan 2004 02:31:35 +0200, Martti Halminen <···············@kolumbus.fi> wrote:
>
>> For comparision, Symbolics Genera 8.3 .lisp sources are about 460000
>> lines, mostly ZetaLisp, though.
>
> That'd be the whole OS including GUI, Lisp runtime and compiler?
Yeah, that was the contents of my sys.sct directory, seems to
contain pretty much everything (CLIM -directory is empty, but
C, Pascal and Fortran compilers are also included in the count...).
--
Martti Halminen <···············@kolumbus.fi> wrote in message news:<····························@kolumbus.fi>...
> On Mon, 26 Jan 2004 18:44:28 -0500, Brian Mastenbrook wrote:
> >>In article <············@ulric.tng.de>, Andr� Thieme
>
> >> How long (measured in lines of code) is the longest CL program you know
> >> of? I basically want to know for what projects CL could be the language
> >> of choice. This if of pure theoretical interest for me as I don't plan
> >> to start a ten million loc project any time soon ;)
>
> >> I know that Lisp programs tend to be in some cases _much_ smaller than a
> >> C++ counterpart. Anyway, are there any Lisp programs beyond the 500k
> >> lines mark?
> >
> > SBCL: 241787 total
> > CMUCL: 393941 total
> > McCLIM: 78544 total
> > Maxima: 209297 total
> >
> > I think these are probably the Mozillas of the CL world. I can't think
> > of any larger CL projects OTOH.
>
> For comparision, Symbolics Genera 8.3 .lisp sources are about
> 460000 lines, mostly ZetaLisp, though.
>
> --
Just for the record, my MacIvory's rel-8-3 directory has
2.3 million lines of Lisp code (it includes two versions
of Statice, Concordia, CLIM, CL-HTTP, Joshua, some graphics stuff,
C, Fortran, Pascal, and some other stuff). The number
includes blank lines and comments.
Brian Mastenbrook <····················@cs.indiana.edu> writes:
> SBCL: 241787 total
> CMUCL: 393941 total
> McCLIM: 78544 total
> Maxima: 209297 total
emacs (emacs-lisp): 649917 *.el
hemlock (common-lisp): 48897 *.lisp
garnet (common-lisp): 155941 *.lisp
gnustep (Objective-C): 1231074 *.[hcm]
Common-Lisp is a concise language.
1 Mloc of Common Lisp would correspond to 10 Mloc of C.
Do you know a lot of project in the 10 Mloc range?
--
__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 wrote:
> Brian Mastenbrook <····················@cs.indiana.edu> writes:
>
>>SBCL: 241787 total
>>CMUCL: 393941 total
>>McCLIM: 78544 total
>>Maxima: 209297 total
>
>
> emacs (emacs-lisp): 649917 *.el
> hemlock (common-lisp): 48897 *.lisp
>
> garnet (common-lisp): 155941 *.lisp
> gnustep (Objective-C): 1231074 *.[hcm]
>
>
> Common-Lisp is a concise language.
> 1 Mloc of Common Lisp would correspond to 10 Mloc of C.
> Do you know a lot of project in the 10 Mloc range?
Thanks for providing these numbers.
And nope, there are not many multi million loc projects.
I could only think of operating systems or modern webbrowsers like
Mozilla (with around 30 Mloc).
Andr� Thieme <······································@justmail.de> writes:
> How long (measured in lines of code) is the longest CL program you
> know of?
The activity planner for the Hubble space telescope is around 200k
loc.
--
John M. Adams
Andr� Thieme wrote:
> How long (measured in lines of code) is the longest CL program you know
> of? I basically want to know for what projects CL could be the language
> of choice. This if of pure theoretical interest for me as I don't plan
> to start a ten million loc project any time soon ;)
A related question that would interest me is: How many people were
involved in the largest CL program you know of? Both during a longer
period and at the same time?
Some of the prejudices against Lisp are that it's supposed not to be
suitable for large teams. Again, I expect the answer to be that Lisp
projects don't need to be that big, based on my own experience so far,
but I am stilled interested in other responses here.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
"Pascal Costanza" <········@web.de> wrote in message
··················@f1node01.rhrz.uni-bonn.de...
> Andr� Thieme wrote:
> Some of the prejudices against Lisp are that it's supposed not to be
> suitable for large teams. Again, I expect the answer to be that Lisp
>
> Pascal
I have heard this a number of times.
Where does this opinion come from?
On what is it based?
Rene.
"Rene de Visser" <··············@hotmail.de> writes:
> Where does this opinion come from?
My guess is that it comes from the fact that (almost?) nobody has
tried it, because amazingly big projects in lisp tend to be done
with amazingly few programmers. Which means that most of the known
ways of cooperating on lisp projects applies to small teams.
--
(espen)
>>>>> "Espen" == Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
Espen> "Rene de Visser" <··············@hotmail.de> writes:
>> Where does this opinion come from?
Espen> My guess is that it comes from the fact that (almost?) nobody has
Espen> tried it, because amazingly big projects in lisp tend to be done
Espen> with amazingly few programmers. Which means that most of the known
Espen> ways of cooperating on lisp projects applies to small teams.
Another possibility is that those who formed the oppinion, in their
usual fact-casual way, mixed up the team-size problem with
lisp-programmer availability problem, another popular "proof" that
Lisp Just Cannot Work Here (TM).
The big advantage of these omni-evident "truths" is that you need not
bother to confront their reality and can keep going on the way you
always intended to go.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Rene de Visser wrote:
> "Pascal Costanza" <········@web.de> wrote in message
> ··················@f1node01.rhrz.uni-bonn.de...
>
>>Andr� Thieme wrote:
>>Some of the prejudices against Lisp are that it's supposed not to be
>>suitable for large teams. Again, I expect the answer to be that Lisp
>>
>>Pascal
>
> I have heard this a number of times.
>
> Where does this opinion come from?
> On what is it based?
I guess it's because features like macros seem to support too much
variation in programming style, so that it seems harder to get a large
team to agree upon a useful set of rules, which in turn is considered
beneficial for a better understanding of other team members' source code.
However, I can only guess. Note that I don't believe that Lisp is not
suited for large teams. However, it's not clear to me how one would
argue that.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> I guess it's because features like macros seem to support too much
> variation in programming style, so that it seems harder to get a large
> team to agree upon a useful set of rules, which in turn is considered
> beneficial for a better understanding of other team members' source
> code.
>
> However, I can only guess. Note that I don't believe that Lisp is not
> suited for large teams. However, it's not clear to me how one would
> argue that.
According to Wheeler's study on Linux's size [1] a
small-but-significant portion of GNU/Linux is written in Lisp (about
2.4%). Mostly, this refers to Emacs Lisp files which presumably were
contributed by quite a number of different people (it should be easy
to find out how many exactly). I'm not sure whether this bunch of
people qualifies as a "team" in the software engineering sense, but it
shows that many developers can and do contribute to large Lisp
projects if they see a benefit for themselves or for the community.
[1] http://www.dwheeler.com/sloc/redhat71-v1/redhat71sloc.html
Pascal Costanza <········@web.de> writes:
> Rene de Visser wrote:
>
> > "Pascal Costanza" <········@web.de> wrote in message
> > ··················@f1node01.rhrz.uni-bonn.de...
> >
> >>Andr� Thieme wrote:
> >>Some of the prejudices against Lisp are that it's supposed not to be
> >>suitable for large teams. Again, I expect the answer to be that Lisp
> >>
> >>Pascal
> > I have heard this a number of times.
> > Where does this opinion come from?
> > On what is it based?
>
> I guess it's because features like macros seem to support too much
> variation in programming style, so that it seems harder to get a large
> team to agree upon a useful set of rules, which in turn is considered
> beneficial for a better understanding of other team members' source
> code.
>
> However, I can only guess. Note that I don't believe that Lisp is not
> suited for large teams. However, it's not clear to me how one would
> argue that.
On the other hand, when you compare macro vs. java wrappers, I'd say
that if you had a partition in the team with two groups of vastly
divergent opinions about the API, it would be easier and more
efficient (100% compile-time) to wrap an API with macros rather than
with java classes, for example.
But that's only to point to the real problem: when you have a big
project, you don't mix and match code randomly. You design modules and
define internal APIs. If the two groups can agree on the COMMON-LISP
API, they can surely agree on the self designed internal APIs.
--
__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 wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>Rene de Visser wrote:
>>
>>
>>>"Pascal Costanza" <········@web.de> wrote in message
>>>··················@f1node01.rhrz.uni-bonn.de...
>>>
>>>
>>>>Andr� Thieme wrote:
>>>>Some of the prejudices against Lisp are that it's supposed not to be
>>>>suitable for large teams. Again, I expect the answer to be that Lisp
>>>>
>>>>Pascal
>>>
>>>I have heard this a number of times.
>>>Where does this opinion come from?
>>>On what is it based?
>>
>>I guess it's because features like macros seem to support too much
>>variation in programming style, so that it seems harder to get a large
>>team to agree upon a useful set of rules, which in turn is considered
>>beneficial for a better understanding of other team members' source
>>code.
>>
>>However, I can only guess. Note that I don't believe that Lisp is not
>>suited for large teams. However, it's not clear to me how one would
>>argue that.
>
>
> On the other hand, when you compare macro vs. java wrappers, I'd say
> that if you had a partition in the team with two groups of vastly
> divergent opinions about the API, it would be easier and more
> efficient (100% compile-time) to wrap an API with macros rather than
> with java classes, for example.
>
> But that's only to point to the real problem: when you have a big
> project, you don't mix and match code randomly. You design modules and
> define internal APIs. If the two groups can agree on the COMMON-LISP
> API, they can surely agree on the self designed internal APIs.
I wonder whether part of this issue may not be an unintended consequence
of CL's higher productivity in both per-programmer and per-LOC terms. As
you get into larger projects, the time and personnel spent on such
not-obviously-line-of-code-generating activities as regularizing or
rewrapping macrology and other APIs could be much more visible in a
(still relatively small) lisp programmer team than it would be in a
larger group of the size typically required to implement the same
project in a less productive language. Think of it as Amdahl's law for
coding.
paul
"Rene de Visser" <··············@hotmail.de> wrote in message news:<············@news1.wdf.sap-ag.de>...
> "Pascal Costanza" <········@web.de> wrote in message
> ··················@f1node01.rhrz.uni-bonn.de...
> > Andr� Thieme wrote:
> > Some of the prejudices against Lisp are that it's supposed not to be
> > suitable for large teams. Again, I expect the answer to be that Lisp
>
> I have heard this a number of times.
>
> Where does this opinion come from?
> On what is it based?
Jonathan Rees persuasively argues in:
http://mumble.net/jar/articles/oo.html
"This is related to Lisp being oriented to the solitary hacker and
discipline-imposing languages being oriented to social packs, another
point you mention. In a pack you want to restrict everyone else's
freedom as much as possible to reduce their ability to interfere with
and take advantage of you, and the only way to do that is by either
becoming chief (dangerous and unlikely) or by submitting to the same
rules that they do. If you submit to rules, you then want the rules to
be liberal so that you have a chance of doing most of what you want to
do, but not so liberal that others nail you."
Tayssir John Gabbour wrote:
> Jonathan Rees persuasively argues in:
> http://mumble.net/jar/articles/oo.html
>
> "This is related to Lisp being oriented to the solitary hacker and
> discipline-imposing languages being oriented to social packs, another
> point you mention. In a pack you want to restrict everyone else's
> freedom as much as possible to reduce their ability to interfere with
> and take advantage of you, and the only way to do that is by either
> becoming chief (dangerous and unlikely) or by submitting to the same
> rules that they do. If you submit to rules, you then want the rules to
> be liberal so that you have a chance of doing most of what you want to
> do, but not so liberal that others nail you."
Yes, rules are a good idea. However, in my opinion rules are taken way
too seriously in many programming languages. What I mean by this is that
they take rules one step too far by making them unbreakable. I think
Common Lisp does this better than other languages in that regard.
Take the package system as an example. You can export symbols from a
package, and in this way declare an officially supported interface to
what you want to provide. However, Common Lisp also allows you to access
the symbols in a package that are not explicitly exported by way of the
:: notation. This flexibility can be a life saver.
In other languages, you cannot access non-exported entities, and you
can't do anything about it. From an engineering point of view that's not
a good idea because this might lead you into situations, for example, in
which you can't deliver a software because you have to wait for a
third-party vendor to release an updated version of their product. In
real life, it makes sense to be able to implement workarounds, as long
as it is clear who takes the responsibility in doing so.
Currently, I have such a situation: LispWorks doesn't implement
standard-slot-access, as defined in the MOP. However, it has a similar
internal function in the CLOS package called fast-standard-slot-access
which isn't exactly the same, but does what I need at the moment. Why
shouldn't I be allowed to use it?
BTW, Java provides another example of pretending to be safer than it
actually is: If you declare fields to be non-public (private, protected,
whatever), the language spec states that you cannot access them. This
seems to make people from the static typing community very happy.
However, the Java API provides ways to circumvent such restrictions
because this is needed in real life! (The official excuse is that
debuggers written in Java need to be able to inspect private parts.)
Life could be much simpler than that. Fortunately, it is much simpler
than that. ;)
BTW, you haven't quoted two other interesting comments by Jonathan Rees
from the same page. Before the quoted paragraph he says:
"by giving something up (e.g. the freedom to throw eggs at your
neighbor's house) you gain something that you want (assurance that your
neighbor won't put you in jail)"
However, there is no enforcement that prevents you from throwing eggs at
your neighbor's house, right? ;) You simply don't do it by convention. I
think conventions are a better solution than enforcements.
After the quoted paragraph he says:
"Correctness is undecidable (and generally unenforceable), so managers
go with whatever rule set (static type system, language restrictions,
"lint" program, etc.) shows up at the door when the project starts."
Doesn't sound particularly persuasive to me. What's the point in proving
something unrelated to your actual goal?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> wrote in message news:<············@f1node01.rhrz.uni-bonn.de>...
> Tayssir John Gabbour wrote:
> > "This is related to Lisp being oriented to the solitary hacker and
> > discipline-imposing languages being oriented to social packs, another
> > point you mention. In a pack you want to restrict everyone else's
> > freedom as much as possible to reduce their ability to interfere with
> > and take advantage of you, and the only way to do that is by either
> > becoming chief (dangerous and unlikely) or by submitting to the same
> > rules that they do. If you submit to rules, you then want the rules to
> > be liberal so that you have a chance of doing most of what you want to
> > do, but not so liberal that others nail you."
>
> Yes, rules are a good idea. However, in my opinion rules are taken way
> too seriously in many programming languages. What I mean by this is that
> they take rules one step too far by making them unbreakable. I think
> Common Lisp does this better than other languages in that regard.
Well, it's not like there aren't holes in Rees's gametheory analysis.
Relative strength is important, not absolute strength. In fact,
better tools may amplify one's relative ability to defend. It's not
like it's pleasant in a "safe" language to work with people who don't
care about good code. If you care more about your work than others,
you'll want increased ability to work around and deal with problems.
Because you can't really escape all sorts of leaky abstractions like
performance.
However, Rees was pretty eloquent about the POV he mentions, and a lot
of users probably do believe it on some level.
> BTW, Java provides another example of pretending to be safer than it
> actually is: If you declare fields to be non-public (private, protected,
> whatever), the language spec states that you cannot access them. This
> seems to make people from the static typing community very happy.
> However, the Java API provides ways to circumvent such restrictions
> because this is needed in real life! (The official excuse is that
> debuggers written in Java need to be able to inspect private parts.)
Well, it often seems the Java team has a role to play, which they do
to the hilt. It's a good rendition of the fascist design philosophy
where the creator knows better than the user. It was pretty
successful; maybe those imprisoned in its walls were pretty happy.
The adjectives used are manager-friendly, not codemonkey friendly,
like "safety". "Purity."
So I would argue that Java's decisions are more understandable in
light of the managers who are Java's true customers. Java is after
all a product.
> BTW, you haven't quoted two other interesting comments by Jonathan Rees
> from the same page. Before the quoted paragraph he says:
>
> "by giving something up (e.g. the freedom to throw eggs at your
> neighbor's house) you gain something that you want (assurance that your
> neighbor won't put you in jail)"
>
> However, there is no enforcement that prevents you from throwing eggs at
> your neighbor's house, right? ;) You simply don't do it by convention. I
> think conventions are a better solution than enforcements.
This is the reason for attack dogs. Shouldn't teams of programmers
have buttons to zap each other at their keyboards?
Pascal Costanza wrote:
> Andr� Thieme wrote:
>
>> How long (measured in lines of code) is the longest CL program you
>> know of? I basically want to know for what projects CL could be the
>> language of choice. This if of pure theoretical interest for me as I
>> don't plan to start a ten million loc project any time soon ;)
>
>
> A related question that would interest me is: How many people were
> involved in the largest CL program you know of? Both during a longer
> period and at the same time?
>
> Some of the prejudices against Lisp are that it's supposed not to be
> suitable for large teams. Again, I expect the answer to be that Lisp
> projects don't need to be that big, based on my own experience so far,
> but I am stilled interested in other responses here.
The largest lisp programming projects I've been directly involved in
were SK8, with about 6 programmers, and the Dylan version of the Newton
OS (which was written twice, once with about 20 programmers, most of
whom were not Lisp programmers, and once with 5 Lisp programmers --
unless you count Apple Cambridge, which was another half-dozen (very)
experienced Lisp people working on the Dylan compiler).
mikel evins <·····@evins.net> wrote in message news:<·····················@newssvr27.news.prodigy.com>...
> Pascal Costanza wrote:
>
> > Andr� Thieme wrote:
> >
> >> How long (measured in lines of code) is the longest CL program you
> >> know of? I basically want to know for what projects CL could be the
> >> language of choice. This if of pure theoretical interest for me as I
> >> don't plan to start a ten million loc project any time soon ;)
> >
> >
> > A related question that would interest me is: How many people were
> > involved in the largest CL program you know of? Both during a longer
> > period and at the same time?
> >
> > Some of the prejudices against Lisp are that it's supposed not to be
> > suitable for large teams. Again, I expect the answer to be that Lisp
> > projects don't need to be that big, based on my own experience so far,
> > but I am stilled interested in other responses here.
>
> The largest lisp programming projects I've been directly involved in
> were SK8, with about 6 programmers, and the Dylan version of the Newton
> OS (which was written twice, once with about 20 programmers, most of
> whom were not Lisp programmers, and once with 5 Lisp programmers --
> unless you count Apple Cambridge, which was another half-dozen (very)
> experienced Lisp people working on the Dylan compiler).
One of the larger Lisp projects was probably the ATM switch project
done at AT&T. The project went through several phases over
several years (at one time using special purpose Lisp boards
with a special operating system from Symbolics. Later using
ACL/AllegroStore and LispWorks). IIRC, at the peak time there might
have been about 100 people working on the project. At some Lisp
conference long ago there was a talk about that project.
http://www.att.com/news/0894/940818.nsa.html
······@corporate-world.lisp.de (Rainer Joswig) writes:
> mikel evins <·····@evins.net> wrote in message
> news:<·····················@newssvr27.news.prodigy.com>...
>
> > > Andr� Thieme wrote:
> > >
> > >> How long (measured in lines of code) is the longest CL program
> > >> you know of? [...]
>
> One of the larger Lisp projects was probably the ATM switch project
> done at AT&T. [...] At some Lisp conference long ago there was a
> talk about that project.
>
> http://www.att.com/news/0894/940818.nsa.html
This is pretty old; from 1994. Anything about this since then?
Google isn't really turning up much.
On Tue, 27 Jan 2004 14:55:02 +0100, Pascal Costanza <········@web.de>
wrote:
>
>A related question that would interest me is: How many people were
>involved in the largest CL program you know of? Both during a longer
>period and at the same time?
>
There were up to possibly 20 Lisp programmers involved at the
same time in writing software for the Connection Machine.
But this involved a number of projects that were pretty much
independent, even if many were loaded into the same software space.
Pascal Costanza wrote:
> A related question that would interest me is: How many people were
> involved in the largest CL program you know of? Both during a longer
> period and at the same time?
>
> Some of the prejudices against Lisp are that it's supposed not to be
> suitable for large teams. Again, I expect the answer to be that Lisp
> projects don't need to be that big, based on my own experience so far,
> but I am stilled interested in other responses here.
The Mirai 2D/3D animation system (a successor to the Symbolics
S-Products) was a large, high-end commercial product that was
almost completely written in Lisp (except for the renderer, some game
exporters, and a few miscellaneous libraries). We had about a
dozen people working on the Lisp modules at it's peak. The product
was great and Lisp certainly helped make it possible. Unfortunately, it
eventually failed because of marketing and business issues -- going up
against much larger, well-entrenched competitors with large installed
bases of users.
The Loom knowledge representation language has roughly 99,500 lines of
code, of which about 20,000 are comment lines.
Hmmm. Maybe I should write another 500 lines and push it over 100k :)
--
Thomas A. Russ, USC/Information Sciences Institute
From: André Thieme
Subject: Conclusions (was: Re: Length of Lisp programs)
Date:
Message-ID: <bvho1q$gbl$1@ulric.tng.de>
Thanks to all people who presented some numbers. It is relieving too see
that the length of a program is obviously not a limiting factor for Lisp
development.
The compactness of Lisp often allows to express problems with few lines
of code which I regard as a positive effect. When comparing the LOC
between different programming languages for a variety of problems,
chances are good to find Lisp in the top rankings. Although I am not
going to participate in a big project in a straightforward timeframe I
was just interested if the length of a program could possibly be a limit
for Lisp.
I think this I was not so sure about it cause I had a lengthy discussion
some weeks ago about the effectiveness of Python and Lisp compared to
Java and it turned out that my discussion partner was very convinced
that static typing is a must when the application is beginning to become
very long. After good experiences with Python I refused to accept this
as a fact. A second reason for my question might come from what I have
seen so far as the length of Lisp programs (which I found in the net).
They all were "short", most of the time well under 50k LOC.
Now, after following some programs I see clearly that the language
itself is not a limiting factor.
Although there are some long programs in Lisp who prove that it is
possible to write long programs, most of them are "short". I see two
main reasons why Lisp programs are short:
1. the environment of the language already provides very much
functionality that you don't have to program yourself
2. most people who are using Lisp are very good in it. The ideas of the
language fit very well into their minds, so the language is not alone a
factor for the quality of the Lisp programs - the quality of the
programmers is also very important (if not even more important).
Either Lisp attracts good programmers or the model of Lisp forces you to
become a good programmer after some time using it.
Well, from today on I will call Lisp "a silent language" :)
(cause of the compactness of most programs)
------------
Andr�
"Lisp is silent"
Andr� Thieme <······································@justmail.de> writes:
> Well, from today on I will call Lisp "a silent language" :)
> (cause of the compactness of most programs)
A concise language.
--
__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/
For comparison, the non-grapical portions of Allegro CL is 926,000
SLOC. The IDE is 216,000. Everything else (the many add-on products,
including things like AllegroServe) are 792,000. That's a grand total
of 1,934,000. I didn't include the 15,000 lines of Emacs Lisp.
The company's first product was Franz Lisp. The last version we
released contained 54,100 SLOC. Much of Franz Lisp was written in C,
though, about 60,000 SLOC. The Franz Lisp history predates Franz the
company. Most of the code was written before Franz, the company, was
started.
It appears we've been busy over the last 20 years.
Kevin