Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Productivity study

2 views
Skip to first unread message

connell...@gmail.com

unread,
May 19, 2006, 2:11:15 PM5/19/06
to
Hi folks,

Many of you have probably seen the article "Lisp as an Alternative to
Java" by Norvig. I ran into the article when I was learning Common
Lisp, and Googled "lisp productivity." I created a summary PDF of the
productivity information in the two studies cited by Norvig:


http://barnesc.blogspot.com/2006/05/programming-language-productivity.html

Now my main question is: is there more recent research in a similar
vein? That is, are there more recent empirical studies of particular
problems which compare languages such as Lisp and C++? It seems like
there should be an entire academic research area devoted to the
empirical study of language productivity for specific problem domains,
but I can't seem to find it! (I did try "Cited by..." in Google
Scholar...)

Thanks,
Connelly Barnes

Pascal Bourguignon

unread,
May 19, 2006, 2:33:12 PM5/19/06
to
connell...@gmail.com writes:

Think about it!

If somebody wrote a paper saying: "Hey, there's a programming language
that gives 10x to 50x the productivity than any other programming
language, and have consistently done so for 50 years." that would be
widely received:

- what would do the 90% of the programmers (the cobol, php, java &
crews) do?

- worse, what would the searchers in programming productivity and
methodology do?

Try to find anything invented in the last 40 years that wasn't already
invented and use routinely in lisp ten to 40 years before...


I mean, really, think about it, if instead of writing newsposts about
programming productivity, you'd be writing lisp programs, and instead
of answering to such a programming productivity post I'd be writing
lisp programs, imagine the _actual_ increase in programming productivity!

--
__Pascal Bourguignon__ http://www.informatimago.com/
Small brave carnivores
Kill pine cones and
Fear vacuum cleaner

David Steuber

unread,
May 19, 2006, 5:03:06 PM5/19/06
to
Pascal Bourguignon <p...@informatimago.com> writes:

> I mean, really, think about it, if instead of writing newsposts about
> programming productivity, you'd be writing lisp programs, and instead
> of answering to such a programming productivity post I'd be writing
> lisp programs, imagine the _actual_ increase in programming productivity!

Lisp programmers would probably be more productive if there were more
Lisp programmers writing projects in Lisp.

--
http://www.david-steuber.com/
1998 Subaru Impreza Outback Sport
2006 Honda 599 Hornet (CB600F) x 2 Crash & Slider
The lithobraker. Zero distance stops at any speed.

Ken Tilton

unread,
May 19, 2006, 5:08:48 PM5/19/06
to

David Steuber wrote:
> Pascal Bourguignon <p...@informatimago.com> writes:
>
>
>>I mean, really, think about it, if instead of writing newsposts about
>>programming productivity, you'd be writing lisp programs, and instead
>>of answering to such a programming productivity post I'd be writing
>>lisp programs, imagine the _actual_ increase in programming productivity!
>
>
> Lisp programmers would probably be more productive if there were more
> Lisp programmers writing projects in Lisp.
>

Awesomely good point.

kt

--
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.

Bob Felts

unread,
May 22, 2006, 11:29:05 PM5/22/06
to
Pascal Bourguignon <p...@informatimago.com> wrote:

[...]

>
> Think about it!
>
> If somebody wrote a paper saying: "Hey, there's a programming language
> that gives 10x to 50x the productivity than any other programming
> language, and have consistently done so for 50 years." that would be
> widely received:
>
> - what would do the 90% of the programmers (the cobol, php, java &
> crews) do?

Some would start to learn Lisp, the rest would continue doing what they
are already doing.

>
> - worse, what would the searchers in programming productivity and
> methodology do?
>

1) Try to duplicate the results,
2) See if there are alternatives to Lisp which have the same dramatic
productivity gains,
3) Research ways to make Lisp better.

Pascal Bourguignon

unread,
May 23, 2006, 8:43:18 AM5/23/06
to
wr...@stablecross.com (Bob Felts) writes:

> Pascal Bourguignon <p...@informatimago.com> wrote:
>
> [...]
>
>>
>> Think about it!
>>
>> If somebody wrote a paper saying: "Hey, there's a programming language
>> that gives 10x to 50x the productivity than any other programming
>> language, and have consistently done so for 50 years." that would be
>> widely received:
>>
>> - what would do the 90% of the programmers (the cobol, php, java &
>> crews) do?
>
> Some would start to learn Lisp, the rest would continue doing what they
> are already doing.
>
>>
>> - worse, what would the searchers in programming productivity and
>> methodology do?
>>
>
> 1) Try to duplicate the results,

How many times do you need to duplicate results?

How do you get money to duplicate result?

What if you submitted a proposal to duplicate Archimedes' result (ok,
you wouldn't need a big budget, just a bathtub, some liquid and a
body, but you could try to add a decimal; perhaps the results don't
hold for some kind of bodies or some kid of liquid, or in some kind of
gravity: let's duplicate Archimedes' results on Saturn!).


> 2) See if there are alternatives to Lisp which have the same dramatic
> productivity gains,

Well, if the original study showed that lisp was better than anything
else, what would be the point to search for alternatives to lisp?
Isn't it the same as the first item?


> 3) Research ways to make Lisp better.

But researchers who are doing this kind of productivity studies are
not _able_ to make a better lisp. Otherwise that's what they would
have done!


That's why my conclusion is that they would be out of job.


>> Try to find anything invented in the last 40 years that wasn't already
>> invented and use routinely in lisp ten to 40 years before...
>>
>>
>> I mean, really, think about it, if instead of writing newsposts about
>> programming productivity, you'd be writing lisp programs, and instead
>> of answering to such a programming productivity post I'd be writing
>> lisp programs, imagine the _actual_ increase in programming productivity!

--
__Pascal Bourguignon__ http://www.informatimago.com/

THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.

va...@acd.net

unread,
May 23, 2006, 10:18:11 AM5/23/06
to
Pascal Bourguignon wrote:
> connell...@gmail.com writes:
>
> > Hi folks,
> >
> > Many of you have probably seen the article "Lisp as an Alternative to
> > Java" by Norvig. I ran into the article when I was learning Common
> > Lisp, and Googled "lisp productivity." I created a summary PDF of the
> > productivity information in the two studies cited by Norvig:
> >
> >
> > http://barnesc.blogspot.com/2006/05/programming-language-productivity.html
> >
> > Now my main question is: is there more recent research in a similar
> > vein? That is, are there more recent empirical studies of particular
> > problems which compare languages such as Lisp and C++? It seems like
> > there should be an entire academic research area devoted to the
> > empirical study of language productivity for specific problem domains,
> > but I can't seem to find it! (I did try "Cited by..." in Google
> > Scholar...)
>
> Think about it!
>
> If somebody wrote a paper saying: "Hey, there's a programming language
> that gives 10x to 50x the productivity than any other programming
> language, and have consistently done so for 50 years." that would be
> widely received:
>
> - what would do the 90% of the programmers (the cobol, php, java &
> crews) do?

They would continue to write in their language de jour, likely in
imperative style, since that is the style they are most comfortable
with. It's been my experience that most programmers prefer to work this
way. Just because Lisp is more productive doesn't mean just anybody can
pick it up. In fact, I would be willing to wager that most programmers
can't pick up the full Lisp style. It can be hard, and we tend to lose
sight of that. (For example, a typical programmer will whine about all
those parentheses, FCS, when there are several modern text editors that
will blink, color, bounce the cursor, and error highlight parentheses
for you automatically.) Php, cobol, java -- all those languages are too
constraining and limit the programmer. Even if the language is meant to
be OO, how it is applied is quite another matter. The usual programmer
will just use OO to wrap his imperative constructs. Taken to the
extreme, I worked with one tech lead who put her entire program into
one very long, imperative procedure. She left the company shortly after
her project was cancelled. Now she's a consultant. I realize one data
point does not establish my point, but I could list numerous other
examples.

If Lisp limits the programmer it's only due to either our imagination
or our own intellectual capability. IMNSHO, the reason why there hasn't
been an inarguably better Lisp is because Lisp is no longer the
limiting component -- it is us. Note how we are still finding new ways
to apply it. And this can be embarressing to those who aren't able,
which could explain why there is no stampede toward a more capable
language.

Bob Felts

unread,
May 23, 2006, 2:06:18 PM5/23/06
to
Pascal Bourguignon <p...@informatimago.com> wrote:

> wr...@stablecross.com (Bob Felts) writes:
>
> > Pascal Bourguignon <p...@informatimago.com> wrote:
> >
> > [...]
> >
> >>
> >> Think about it!
> >>
> >> If somebody wrote a paper saying: "Hey, there's a programming language
> >> that gives 10x to 50x the productivity than any other programming
> >> language, and have consistently done so for 50 years." that would be
> >> widely received:
> >>
> >> - what would do the 90% of the programmers (the cobol, php, java &
> >> crews) do?
> >
> > Some would start to learn Lisp, the rest would continue doing what they
> > are already doing.
> >
> >>
> >> - worse, what would the searchers in programming productivity and
> >> methodology do?
> >>
> >
> > 1) Try to duplicate the results,
>
> How many times do you need to duplicate results?
>

Oh, I dunno. We could ask Pons and Fleischman. ;-)

But, seriously, how many formal studies are there on Lisp productivity?
I've read Ron Garrett's Lisp vs. Java paper and there is plenty of
anecdotal evidence floating around. Good grief, I've got some myself.
The company I work for decided to implement PSP & TSP to try to improve
software quality. I didn't take the full two week course, but I asked
around about the first coding assignment; it took me about 185 lines of
C, about 1.5 hours. I learned that, from statistics gathered over many,
many programmers, that this exercise usually takes somewhere between 2
and 8 hours for individuals to complete. I don't remember the LOC
numbers.

It was 15 lines of Lisp, and took me about 30 minutes, but I'd like to
re-write it now that I know more Lisp. I hadn't learned about (error
...) or (format ...)) when I coded it up. ... ok, now it's 22 lines.

But that's hardly convincing evidence to take to management.

> How do you get money to duplicate result?
>

Research grants. Thesis projects, where research subjects are a captive
audience. ...

> What if you submitted a proposal to duplicate Archimedes' result (ok,
> you wouldn't need a big budget, just a bathtub, some liquid and a
> body, but you could try to add a decimal; perhaps the results don't
> hold for some kind of bodies or some kid of liquid, or in some kind of
> gravity: let's duplicate Archimedes' results on Saturn!).
>

Do you think that productivity gains due to Lisp are as well documented
as Archimedes experiment? What are some of the refereed publications
that demonstrate the superiority of Lisp and account for other
possibilities? It is a well known result that productivity (using the
same language) can differ by an order of magnitude between individual
programmers (cf. the PSP results, Brooks or Weinberg, I don't remember
which (maybe both), ...) -- perhaps highly productive programmers
gravitate to Lisp and that accounts for much of the gains (obviously not
true at least based on my one data point, but these questions have to be
answered). How much is due to the interpreted environment vs. the
language itself? And so on...

>
> > 2) See if there are alternatives to Lisp which have the same dramatic
> > productivity gains,
>
> Well, if the original study showed that lisp was better than anything
> else, what would be the point to search for alternatives to lisp?
> Isn't it the same as the first item?
>

I don't think so. First, it would have to be shown that Lisp is the
ultimate language.

>
> > 3) Research ways to make Lisp better.
>
> But researchers who are doing this kind of productivity studies are
> not _able_ to make a better lisp. Otherwise that's what they would
> have done!
>

Maybe. I'm too much of a newbie for anyone to take this obversation
very seriously (including myself), but parts of Scheme are a lot cleaner
than Lisp.

I also wish that SLIME had a concept of redirection, so that instead of
something like:

(foo '(1 2 3 4 5 ...))

I could type:

(foo <in-file.txt) >out-file.txt

Maybe I can and I just haven't found it yet.

>
> That's why my conclusion is that they would be out of job.
>

Don't underestimate:
1) the power of inertia, and
2) the ability of humans to ignore that which is better for that which
is familiar.

Wasn't it Churchill who said, "Man will occasionally stumble over the
truth, but most of the time he will pick himself up and continue on."?

Pascal Bourguignon

unread,
May 23, 2006, 2:58:01 PM5/23/06
to
wr...@stablecross.com (Bob Felts) writes:
> Do you think that productivity gains due to Lisp are as well documented
> as Archimedes experiment? What are some of the refereed publications
> that demonstrate the superiority of Lisp and account for other
> possibilities? It is a well known result that productivity (using the
> same language) can differ by an order of magnitude between individual
> programmers (cf. the PSP results, Brooks or Weinberg, I don't remember
> which (maybe both), ...) -- perhaps highly productive programmers
> gravitate to Lisp and that accounts for much of the gains (obviously not
> true at least based on my one data point, but these questions have to be
> answered). How much is due to the interpreted environment vs. the
> language itself? And so on...

All right, you're convincing me that there's matter for a serrious study.

(There are C interpreter / REPL-like environment so we could indeed to
fine-grained tests).


The next questions is whether there are sufficient lisp programmers to
make a statistically significant study! :-)


> Don't underestimate:
> 1) the power of inertia, and
> 2) the ability of humans to ignore that which is better for that which
> is familiar.

I was more cynical, and with my rethorical questions hinted that they
do know or gues sthe truth, but that they dedicately avoid it because
they don't like the consequences (programmers would have to admit that
they lost time working with inferior languages building inferior
libraries, and productivity searchers would have to stop milking this
"research" branch and try to find something new and inventive to
reasearch).

> Wasn't it Churchill who said, "Man will occasionally stumble over the
> truth, but most of the time he will pick himself up and continue on."?

--
__Pascal Bourguignon__ http://www.informatimago.com/

COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.

Giorgos Keramidas

unread,
May 23, 2006, 4:11:46 PM5/23/06
to
On Tue, 23 May 2006 14:06:18 -0400, wr...@stablecross.com (Bob Felts) wrote:
> I also wish that SLIME had a concept of redirection, so that instead of
> something like:
>
> (foo '(1 2 3 4 5 ...))
>
> I could type:
>
> (foo <in-file.txt) >out-file.txt
>
> Maybe I can and I just haven't found it yet.

If you are using SLIME, then you are using Emacs.

Emacs has `M-x write-region RET filename RET' that can do at least the
second part of this.

Regards,
Giorgos

Bill Atkins

unread,
May 23, 2006, 4:26:36 PM5/23/06
to
wr...@stablecross.com (Bob Felts) writes:

> I also wish that SLIME had a concept of redirection, so that instead of
> something like:
>
> (foo '(1 2 3 4 5 ...))
>
> I could type:
>
> (foo <in-file.txt) >out-file.txt
>
> Maybe I can and I just haven't found it yet.

While I oppose the use of reader macros when a simple function will
do, you'll be happy to know that what you propose is quite possible in
Common Lisp:

(set-macro-character #\<
(lambda (stream char)
(declare (ignore char))
(let ((s (gensym)) (length (gensym)) (seq (gensym)))
`(with-open-file (,s ,(read stream)
:direction :input)
(let* ((,length (file-length ,s))
(,seq (make-string ,length)))
(read-sequence ,seq ,s)
,seq)))))

(set-macro-character #\>
(lambda (stream char)
(declare (ignore char))
(let ((s (gensym)))
`(with-open-file (,s ,(read stream)
:direction :output
:if-exists :supersede)
(format ,s "~S" cl:*)))))

CL-USER> 333
333
CL-USER> >"foo.txt"
333
CL-USER> <"foo.txt"
"333"
CL-USER> (length <"foo.txt")
3

The second isn't quite what you asked for, since the output macro has
to be a separate input to the REPL, but then I think these would both
work much, much better as (slurp "foo.txt") and (spit 33 "foo.txt").

Bill

P.S. The reader macros I give require you to put the filename in
quotes. I think this is a feature, but it is also possible to use the
quoteless syntax you specified.

--
You fool! You fell victim to one of the classic blunders! The most
famous is, "Never get involved in a land war in Asia", but only
slightly less well-known is this: "Never go in against a Sicilian when
death is on the line"!

Rob Warnock

unread,
May 25, 2006, 4:30:43 AM5/25/06
to
Bob Felts <wr...@stablecross.com> wrote:
+---------------

| I also wish that SLIME had a concept of redirection, so that instead of
| something like:
| (foo '(1 2 3 4 5 ...))
| I could type:
| (foo <in-file.txt) >out-file.txt
| Maybe I can and I just haven't found it yet.
+---------------

It's not Common Lisp, and it's not SLIME, but there is such a thing.
It's called "Scsh", a.k.a. "The Scheme Shell":

http://sourceforge.net/projects/scsh/
http://www.scsh.net/
...
Scsh has two main components: a process notation for running programs
and setting up pipelines and redirections, and a complete syscall
library for low-level access to the operating system, i.e. to POSIX,
the least common denominator of more or less all Unices, plus widely
supported extensions such as symbolic links and BSD sockets. Moreover,
scsh provides an awk facility for pattern-directed computation over
streams of records, a rich facility for matching regular-expression
patterns in strings, event-based interrupt handling, user-level
threads, a futuristic module system, and an interactive environment.


-Rob

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

Bob Felts

unread,
May 25, 2006, 8:02:13 AM5/25/06
to
Rob Warnock <rp...@rpw3.org> wrote:

Thanks! I'll check it out...

0 new messages