How do you measure the size of a Lisp program? I now how it's done for
'C' (Barry Boehm descibes how to count FIDSI in COCOMO), but
what about Lisp? Do you cont the number of '(' , or function calls
or what? Is there a standard way of reporting size?
Thanks,
Bill
PS.
I can't find a Common Lisp way to get at command line arguments.
Any hints please?
--
Bill Birch | ·······@hemel.bull.co.uk
Bull Info. Sys. Ltd. |
Maxted Road, | Imp: HM14 UK03
Hemel Hempstead, | Tel: +44 442 884367
HERTS, HP2 7DZ, U.K. | Fax: +44 442 884570
nil desperandum..
In article <·····················@hemel.bull.co.uk> ······@hemel.bull.co.uk (Bill Birch) writes:
How do you measure the size of a Lisp program? I now how it's done for
'C' (Barry Boehm descibes how to count FIDSI in COCOMO), but
what about Lisp? Do you cont the number of '(' , or function calls
or what? Is there a standard way of reporting size?
Thanks, Bill
I guess it depends on what you want the "size" is supposed to measure.
When I program, the more I refine the code the smaller it becomes.
This does not mean that it does less, often the contrary is the case.
(This is more often true of Lisp than of C, since second order
functions is often the cause of the shrinking). So size isn't
necessarily a good measure of how much a program does.
And sometimes the process of making the code smaller, makes it more
readable and sometimes not. So the size isn't necessarily a good
measure of readability and thus not ease of maintenance.
The number of classes has been mentioned as a good measure of
complexity. But I bet that a complex (by this measure) program written
without the classes would be much more complex. However, for a
well-written (CLOS) program the number of classes may be the best
measure you have.
--
Hallvard Traetteberg
Dept. of Knowledge Based Systems
Center for Industrial Research
Box 124 Blindern, 0314 Oslo 3
NORWAY
Tlf: +47 2 45 20 10
Fax: +47 2 45 20 40
Email: ········@si.no
Bill Birch (······@hemel.bull.co.uk) writes:
>How do you measure the size of a Lisp program? I now how it's done for
>'C' (Barry Boehm descibes how to count FIDSI in COCOMO), but
>what about Lisp? Do you cont the number of '(' , or function calls
>or what? Is there a standard way of reporting size?
It depend on what you want to know. If you need to know how much space
it requires on your disk, count the characters :-). If you mean to
measure a programmer's productivity, a crude measure (yrch!) would be
counting lines. This doesn't take into account what the programmer(s)
did besides writing code (i.e. debugging, writing of test functions
you won't find in the final version, conceptual design, etc.). BTW,
this also holds for C or FORTRAN programs.
(What's "FIDSI", by the way?)
The more high-level a language is, the more difficult is the task of
assessing the complexity of a program. You can write a program for
symbolically computing the derivative of a function on two pages. On
the other hand, a small parser for a complex syntax may take more than
that although its task may be much simpler than doing symbolic math.
Now, if you do similar tasks in C, you'll find that the symbolic math
program turns out much larger than the parser (I mean longer by lines
of code).
Personally, I can't really see how the size of a program should be
measured. You can't even compare programs written in the same language
because often, size is also a matter of programming style.
Does anybody have a clear definition of the "size of a program"? (I
mean, not a rule how to compute it, just a definition of what is is
supposed to mean.)
>I can't find a Common Lisp way to get at command line arguments.
>Any hints please?
It depends on the version of LISP you're using. Some LISP systems
allow users to access them via a special data structure, some provide
a special function, and some allow you to specify an initial function
to be called on the command line. I'm afraid, there's no general
solution to that. In the worst case, write a small shell script as a
wrapper around the LISP system incantation, write any arguments passed
to that script to a file, and tell your LISP initialization file to
check for the presence of that file and its contents.
Greetings,
--Juergen Wagner ·······@csli.stanford.edu
········@iao.fhg.de
·······@Csli.Stanford.EDU (Juergen Wagner) writes:
>Bill Birch (······@hemel.bull.co.uk) writes:
>>How do you measure the size of a Lisp program? I now how it's done for
>>'C' (Barry Boehm descibes how to count FIDSI in COCOMO), but
>>what about Lisp? Do you cont the number of '(' , or function calls
>>or what? Is there a standard way of reporting size?
>(What's "FIDSI", by the way?)
Format Independant Deliverable Source Instructions - read Boehm's book
for a definition.
>Personally, I can't really see how the size of a program should be
>measured. You can't even compare programs written in the same language
>because often, size is also a matter of programming style.
Please understand that Software Engineers use many measures of
program size and effort. One of the simplest (to calculate) is
Lines of Code (LOC).
Please respond to this message if you actually know the answer!
Persons who write code without measuring their effort (in LOC
, Function Points or whatever) are not invited to respond.
I woud expect the _professionals_ to have a thing or two to say
about Lisp Metrics??
(setq *Flame* t)
I meet so many programmers who say "The program I am most proud of
was a tripe-grundge-orrary-inference-compiler , blah,blah ..."
But when you ask them "And how many days effort did you put into
it?" They don't know! When you ask them "How big was the program?"
They don't know! These are the same programmers who if you ask
"How long will it take you to write an XYZ program?", they don't
know! Even if they already wrote one!
Professionals keep metrics.
(setq *Flame* nil)
>Does anybody have a clear definition of the "size of a program"? (I
>mean, not a rule how to compute it, just a definition of what is is
>supposed to mean.)
Yes, ask a software engineer.
--
Bill Birch | ·······@hemel.bull.co.uk
Bull Info. Sys. Ltd. |
Maxted Road, | Imp: HM14 UK03
Hemel Hempstead, | Tel: +44 442 884367
HERTS, HP2 7DZ, U.K. | Fax: +44 442 884570
nil desperandum..
In article <··················@bermuda.gte.com>, ····@gte.com (Joseph D. Morrison) writes:
> In article <····················@hemel.bull.co.uk> ······@hemel.bull.co.uk (Bill Birch) writes:
>
>> Please understand that Software Engineers use many measures of
>> program size and effort. One of the simplest (to calculate) is
>> Lines of Code (LOC).
>
> Many people seem to use LOC as a measure of the "value" of a piece of
> software. (I'm not suggesting that you do this; I'm simply making an
> observation about many people I've met.) I think it's much more
> interesting to consider LOC as a *cost* item. In my experience, given
> a functional spec, a good programmer can "bring it in" using fewer LOC
> than a mediocre programmer. Naturally, there are other measures of
> quality that come into play as well...
>
> (Consider: "how big a skyscraper did your company build?" "Well, we
> used 18 godzillion gallons of concrete" "wow, that's pretty big".)
>
>> (setq *Flame* t)
>> I meet so many programmers who say "The program I am most proud of
>> was a tripe-grundge-orrary-inference-compiler , blah,blah ..."
>> But when you ask them "And how many days effort did you put into
>> it?" They don't know! When you ask them "How big was the program?"
>> They don't know! These are the same programmers who if you ask
>> "How long will it take you to write an XYZ program?", they don't
>> know! Even if they already wrote one!
>>
>> Professionals keep metrics.
>>
>> (setq *Flame* nil)
>
> (call-with-open-flame
> (lambda (f)
> (I meet so many programmers who are pedantic, inflexible and
> closed-minded who say "Professional programmers always write at
> least 1 line of comments per 10 lines of code, blah, blah ...".
>
> Some of the best programmers I have met don't keep statistics
> such as the ones you suggest, because they're spending all their
> time doing real software engineering, not writing wrappers for "wc".
>
> Don't get me wrong; I agree that there are cases where it's
> important to keep such statistics. However, if I'm writing the
> tripe-grundge-orrery-inference-compiler at home in my spare time,
> because I want to automate tripe-grundging on my own personal
> orrery (and maybe market the software afterward), then I sure as
> heck ain't gonna keep statistics!
>
> Professionals keep an open mind, and use metrics when necessary.)))
>
>> > Does anybody have a clear definition of the "size of a program"? (I
>> > mean, not a rule how to compute it, just a definition of what is is
>> > supposed to mean.)
>> Yes, ask a software engineer.
>
> I'm a software engineer. The "size of a program" refers to the extent
> to which it influences the programming community. GNU Emacs, for
> instance, is a very large program.
>
> (Do I really need to include the smiley? Probably... :-) :-) :-)
>
> Joe Morrison
> --
> GTE Laboratories Incorporated Email: ·········@gte.com
> 40 Sylvan Road Phone: (617) 466-2614
> Waltham, Massachusetts, 02254
As a matter a fact, I suppose this kind of discussing is fruitless.
If you like programming on a LLL (LispLikeLanguage) or on an CLTL(1)(2), your
should unterstand, that the future of the LISP is not in bytes/line or
bytes/page or written non-erronous lines/day.
THE MOST OF THE PEOPLE IN THE BUSINESS WE ARE DOING NOWADAYS ARE LOOKING FOR
THE C-LIKE-LANGUAGES.
And what is the reason??????
We are talking about bytes/line/page/(or men/woman)/day instead of talking
something that matters.
HEIIIII....
BABY(S)????
Are YOU sane ??=?????