Lisp vs. C++ (not off-topic)

[Josh Stern]

On Tue, 10 Oct 2006 20:01:10 +0000, Makaan wrote:

> I think the number of lines is over rated.

I guess it depends on who is rating and how they do it.  The most obvious
problem with line counting is that it doesn't insure an apples-to-apples
comparison unless there is some way to hold quality relatively
constant.   Using small explicit tasks is one way to try to achieve the
latter.

>This is a very simple example and
> doesn't really compare anything useful. Lisp may have fewer lines but
> the number of parenthesis counter balances this.

What they actually measured in the referenced study was the amount of time
the coding took to complete the task.  If problems with LISP syntax still
hurt productivity of experienced developers then that would have already
been factored into the comparison.  

Looking at lines of code wasn't the base measure of productivity - it
was rather the blog author's attempt to try and explain the amount of time
it took. But my understanding parallels his in the sense that studies
which have looked at larger projects still found number of lines of code
required to be about the best predictor of the amount of time required for
a given type of project - i.e. you can't compare app coding to real-time
embedded coding, but you can you can compare across similar tasks, and
some say lines of similar quality across similar task is a way to look at
the effect of the programming language on productivity. That doesn't mean
it's a great predictor -  but it seems as good as anything else people
have come up with.

> It really needs to compare something more complicated like a
>telephone
> PBX exchange. Lisp has a number of advantages including built in lists
> and this is a list problem.  It doesn't compare anything except the
> implementation of lists of data and should focus on something much more
> complex with larger variables like a 3d game engine.

At least the author of the blog was taking library data structures like
lists and hashmaps for granted, so that wasn't the issue per se, though he
finds fault with the existing interfaces from a productivity point of
view.