Hi all,
I just found some interesting information on the Web site of Software
Productivity Research, Inc. The Information deals with "Function Points &
Feature Points", which I've just learned about. The Page (Paper) is by
Capers Jones, Chairman, Software Productivity Research, Inc. is from March
1996.
What I understand so far is that Function Points & Feature Points are a
way of rating the degree of difficulty of a software project and determining
manpower requirements, cost, and schedules. It's best if you read the
detail from their site.
http://www.spr.com/library/0langtbl.htm
I found this site while reading some information on Smalltalk. This
"Paper" seems to give Smalltalk better marks for productivity than Lisp.
I've only recently started using Smalltalk and have very little real
experience with this environment. My first reaction to this information is
how would Comp.Lang.Lisp respond to this "Paper"? The people that are
active on C.L.L. seem to feel Common Lisp is the most productive language
they have ever used. But this review of "Language Productivity" does not
put Common Lisp (CLOS) at the top. C, C++ and Java are where I think they
should be, but Lisp looks a little out of place (or left out).
If anyone has any references to this kind of information since 1996 would
you please post them. Of course any comments regarding the use of Function
Points & Feature Points are most welcome.
Thanks,
Steven
Steven L. Collins wrote:
> you please post them. Of course any comments regarding the use of
> Function Points & Feature Points are most welcome.
I find it ridiculous. If counting code-lines does not even say much on
complexity of a program in the *same* language (particularily if different
programmers are observed) - what should I say if someone tries to compare
e. g. Common Lisp and HTML with similar quantifications?
Does this mean I should use HTML instead of Common Lisp because it has more
points? ;-)
ciao,
Jochen
From: james anderson
Subject: Re: Funtions Points & Feature Points
Date:
Message-ID: <3B3AF257.44B8469E@setf.de>
the table enumerates ratios between program complexity - as expressed in
"feature points", and program size - as expressed in source code
statements. the author argues elsewhere that these individual factors
correlate independently with development costs. and that, whereas the
first factor is language-invariant, while the second is not, the choice
of the language with the most favorable ratio for a given problem domain
will yield the program with the fewest statements. thereby generating
the lowest development costs. the argument is not new and the author
makes no claims of originality. their contribution is to the complexity
calculation, where they claim a better means to predict complexity by
including an explicit factor for algorithmic complexity.
i was not surprised at the relative standing of html and clos. at
level=22, s/fp=15 and level=20, s/fp=21 they're not even that far apart.
one account for the difference is that html is, to a large extent, declaration-free.
html, with statements such as
<a href='some url' target='newWindow'>open a document</a>
is quite expressive. more expressive than clos is in its respective
problem domain. which does mean it is to be preferred for it's problem
domain. that's all he's claiming.
the results would have more authority if they were more explicit about
the respective problem mix and about analysis based on extrapolations
from "making an educated guess as to their levels" rather than automated
code analysis, but that gives me no cause to argue with the problem
statement itself.
...
Jochen Schmidt wrote:
>
> Steven L. Collins wrote:
>
> > you please post them. Of course any comments regarding the use of
> > Function Points & Feature Points are most welcome.
>
> I find it ridiculous. If counting code-lines does not even say much on
> complexity of a program in the *same* language (particularily if different
> programmers are observed) - what should I say if someone tries to compare
> e. g. Common Lisp and HTML with similar quantifications?
>
> Does this mean I should use HTML instead of Common Lisp because it has more
> points? ;-)
>
> ciao,
> Jochen
james anderson <··············@setf.de> writes:
>
> i was not surprised at the relative standing of html and clos. at
> level=22, s/fp=15 and level=20, s/fp=21 they're not even that far apart.
> one account for the difference is that html is, to a large extent, declaration-free.
>
> html, with statements such as
> <a href='some url' target='newWindow'>open a document</a>
> is quite expressive. more expressive than clos is in its respective
> problem domain. which does mean it is to be preferred for it's problem
> domain. that's all he's claiming.
>
Erm. he's comparing HTML and CL? As programming languages? And this
was published? In a refereed journal? Stop, please, I'm laughing so
much it hurts badly.
Now let's see, if we take him seriously - difficult, I admit - then
he's just obviously wrong:
Lisp, with expressions such as
(with-html-output (s)
((:a :href "http://www.tfeb.org/lisp/hax.html#HTOUT"
:target "newWindow")
"Lisp is a superset of HTML"))
is quite expressive. more expressive than HTML is in its
respective problem domain. which does mean it is to be preferred
for its problem domain. that's all I'm claiming.
--tim (I'm getting stitch now)
From: james anderson
Subject: Re: Funtions Points & Feature Points
Date:
Message-ID: <3B3B9C3D.80F646DE@setf.de>
while i agree, that lisp/clos would be preferred for programs which
generate description of user interfaces, i suggest that the situation is
not quite so hilarious as you suggest with respect to the descriptions
themselves. ....
Tim Bradshaw wrote:
>
>
> Erm. he's comparing HTML and CL? As programming languages? And this
> was published? In a refereed journal? Stop, please, I'm laughing so
> much it hurts badly.
>
> Now let's see, if we take him seriously - difficult, I admit - then
> he's just obviously wrong:
>
> Lisp, with expressions such as
>
> (with-html-output (s)
> ((:a :href "http://www.tfeb.org/lisp/hax.html#HTOUT"
> :target "newWindow")
> "Lisp is a superset of HTML"))
>
> is quite expressive. more expressive than HTML is in its
> respective problem domain. which does mean it is to be preferred
> for its problem domain. that's all I'm claiming.
>
> --tim (I'm getting stitch now)
james anderson wrote:
> while i agree, that lisp/clos would be preferred for programs which
> generate description of user interfaces, i suggest that the situation is
> not quite so hilarious as you suggest with respect to the descriptions
> themselves. ....
Are you sure? Anybody who describes their research methodology as:
<quote>Research was done by reading descriptions and genealogies
of languages and making an educated guess as to their levels. KL,
CLOS, TWAICE, and FASBOL are examples of languages that were
assigned tentative levels merely from descriptions of the
language, rather than from actual counts.</quote>
is surely a comic genius writing for the computer science section
of Punch or the New Yorker?!
It made me l.o.l! :)
Jochen Schmidt wrote:
> Steven L. Collins wrote:
> > you please post them. Of course any comments regarding the
> > use of Function Points & Feature Points are most welcome.
>
> I find it ridiculous. If counting code-lines does not even
> say much on complexity of a program in the *same* language ...
Function points tries to get away from lines of code.
I have not been able to use it successfully because my problems
do map into the existing function point categories, and any
attempt to figure the function point value of our tasks is
foiled by the variability of the different developers.
Construx has an interesting estimation application based on
empirical data that includes Lisp. It will estimate the best
head-count for a project and how many more heads (or less) to
add to meet a release date. But I still haven't figured out
the right inputs (in function points) to get good output.
Try it out for yourself:
http://www.construx.com
Thanks,
Jeff Sandys
On Wed, 27 Jun 2001 20:01:31 -0400, "Steven L. Collins"
<·······@ix.netcom.com> wrote:
> I found this site while reading some information on Smalltalk. This
>"Paper" seems to give Smalltalk better marks for productivity than Lisp.
>I've only recently started using Smalltalk and have very little real
>experience with this environment. My first reaction to this information is
>how would Comp.Lang.Lisp respond to this "Paper"? The people that are
>active on C.L.L. seem to feel Common Lisp is the most productive language
>they have ever used. But this review of "Language Productivity" does not
>put Common Lisp (CLOS) at the top. C, C++ and Java are where I think they
>should be, but Lisp looks a little out of place (or left out).
One thing to bear in mnd about the CLOS rating is that it was decided upon by
reading about the features of CLOS - not based upon analysis of any CLOS
programs. I think the authors would have had difficulty assessing the effects
on productivity of something like MOP, for example, without actually seeing it
in use, as it's so unique.
The Lisp rating also appears low to me. One of the advantages Lisp has in
spades is an ability build custom languages targetted to your programming
domain. If you can do this in your particular domain you could, IMHO, get an
increase in productivity which appears similar to the values given to
spreadsheet tools in this paper.
> If anyone has any references to this kind of information since 1996 would
>you please post them. Of course any comments regarding the use of Function
>Points & Feature Points are most welcome.
I think the Fateman paper at
http://www.franz.com/resources/educational_resources/white_papers/fault.prevention.pdf
and the Norvig paper at
http://www.norvig.com/java-lisp.html
give good background as to where these productivity benefits come from.
I haven't seen anything similar to SPR - it's a shame that they stopped
working on this area as most developers don't identify their language
selection as the reason for poor productivity - the SPR figures show that they
should be doing that.
Mark
"Steven L. Collins" <·······@ix.netcom.com> writes:
> What I understand so far is that Function Points & Feature Points are a
> way of rating the degree of difficulty of a software project and determining
> manpower requirements, cost, and schedules. It's best if you read the
> detail from their site.
> http://www.spr.com/library/0langtbl.htm
I don't see a cross-reference to the actual code so that the
experiment can be tested for reproducibility. That might just be an
oversight in what you sent us (perhaps a pointer into only part of the
results), or I might have just missed it. But absent an ability to
inspect the actual data, I don't see how "good science" (including
"peer review") can happen.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> "Steven L. Collins" <·······@ix.netcom.com> writes:
>
> > What I understand so far is that Function Points & Feature Points are
a
> > way of rating the degree of difficulty of a software project and
determining
> > manpower requirements, cost, and schedules. It's best if you read the
> > detail from their site.
> > http://www.spr.com/library/0langtbl.htm
>
> I don't see a cross-reference to the actual code so that the
> experiment can be tested for reproducibility. That might just be an
> oversight in what you sent us (perhaps a pointer into only part of the
> results), or I might have just missed it. But absent an ability to
> inspect the actual data, I don't see how "good science" (including
> "peer review") can happen.
>
Here is the link to the core information on Function & Feature Points
http://www.spr.com/library/0funcmet.htm
In my original post I provided a link to a table on "Language Levels".
There was a link on this page to the Main body of the discussion, but it
may not have been obvious. Sorry for any confusion.
Steven
"Steven L. Collins" <·······@ix.netcom.com> writes:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@world.std.com...
> > "Steven L. Collins" <·······@ix.netcom.com> writes:
> >
> > > What I understand so far is that Function Points & Feature Points are
> a
> > > way of rating the degree of difficulty of a software project and
> determining
> > > manpower requirements, cost, and schedules. It's best if you read the
> > > detail from their site.
> > > http://www.spr.com/library/0langtbl.htm
> >
> > I don't see a cross-reference to the actual code so that the
> > experiment can be tested for reproducibility. That might just be an
> > oversight in what you sent us (perhaps a pointer into only part of the
> > results), or I might have just missed it. But absent an ability to
> > inspect the actual data, I don't see how "good science" (including
> > "peer review") can happen.
> >
>
> Here is the link to the core information on Function & Feature Points
> http://www.spr.com/library/0funcmet.htm
>
> In my original post I provided a link to a table on "Language Levels".
> There was a link on this page to the Main body of the discussion, but it
> may not have been obvious. Sorry for any confusion.
>
>
>
> Steven
Hey, this is great stuff and resolves a lot of things I've been worried
about. I wish I'd seen it before!
"Source code statements were counted, then compared to the size of the same
program in languages of known levels. Assembly, APL, C, OBJECTIVE C, FORTH,
FORTRAN, LISP, PILOT, and PROLOG are languages that produce the same source
code count as COBOL. So code sizes were compared to the known quantity of COBOL
source code."
"Research was done by reading descriptions and genealogies of languages and
making an educated guess as to their levels. KL, CLOS, TWAICE, and FASBOL are
examples of languages that were assigned tentative levels merely from
descriptions of the language, rather than from actual counts."
The part I like best is Forth and Lisp are rated the same. I always knew it.
To quote Yoda, "You will know. When your code you try to read six months from
now.
Regards, KBK
"Kurt B. Kaiser" <···@shore.net> wrote in message ···················@float.ne.mediaone.com...
>
> Hey, this is great stuff and resolves a lot of things I've been worried
> about. I wish I'd seen it before!
>
> "Source code statements were counted, then compared to the size of the same
> program in languages of known levels. Assembly, APL, C, OBJECTIVE C, FORTH,
> FORTRAN, LISP, PILOT, and PROLOG are languages that produce the same source
> code count as COBOL. So code sizes were compared to the known quantity of COBOL
> source code."
>
> "Research was done by reading descriptions and genealogies of languages and
> making an educated guess as to their levels. KL, CLOS, TWAICE, and FASBOL are
> examples of languages that were assigned tentative levels merely from
> descriptions of the language, rather than from actual counts."
>
> The part I like best is Forth and Lisp are rated the same. I always knew it.
>
> To quote Yoda, "You will know. When your code you try to read six months from
> now.
>
Wow. The only things that came to my mind when I visited the site were,
'What are their products?' followed by,'Ahhh, Snake Oil'. Can't figure
out for the life of me where that second thought came from...
Geoff