> > I can't vouch for the accuracy of the information, but Capers Jones and > > Software Productivity Research believe that Eiffel and perl will have > > higher productivity than Ada. > > > > They put Ada at 10-20 function points per staff-month > > and perl or Eiffel at 16-23. > > That's true... but are you sure that supports the conclusion that Eiffel > and perl provide greater productivity? I'm not the expert on the Neither am I. But... > Capers-Jones metrics but as I recall, "function points" aren't to be > interpreted as a measure of potential productivity They're an Function points are not a measure of productivity, they are a measure of capability. Hence, function points per month is a better measure of productivity than SLOC per month. On that point, at least, I can agree with Jones. > abstract characterization of the "power" of a language, but I would > think that true productivity involves more than just "how high-level" is > the programming language. > > Some factors that come to mind: > > * When life-cycle issues dominate Correct. Jones' table does not explain whether the "month" in "function points per month" is entire life cycle, or length of coding phase. > * When team development issues dominate > > * Project size/scope -- how well does development tend to scale up > when using language X? > > * Suitability to the task. As I recall, Visual Basic rates pretty > high on "function points", but I wouldn't write a compiler or a > protocol stack using it... Correct again. Jones didn't say so, but I'm convinced that his numbers, if valid at all, are only valid when the language is in its proper domain. He rates Excel (the spreadsheet _without_ Visual Basic) at 50, compared to Eiffel at 15 and Ada at 6.5 (Java and C++ tied at 6.0). > * To really evaluate productivity I think you would have to evaluate > languages plus collateral resources such as component libraries, > e.g. C++/STL, Java/JDK, Ada/whatever (that's just one example, of > course). I don't consider that a productivity issue. A language that doesn't have them and can't interface well to others is certainly lower than one that does or can. But since Ada can easily call Java classes or C libraries or POSIX or etc. it's baloney to claim those items give their languages any advantage over Ada. > I realize you were responding to the "function points" language in the > flyer (but you did say, "higher productivity"! :-) > > Actually, I think Tucker should (a) bag the "function points" language, > and (b) bite the bullet and say that productivity is way higher with > Ada, not "at least as high" (what if, say, car dealers said "come on > down and trade that car in for a new Belchfire -- it's _at_least_as_good_ > as what you're driving now!"). My point was not against the claim of productivity, just that the term is not very clear. Not even that there's anything to change about it. A flyer like that is no place for long lists of empirical proof. Nevertheless, there are three groups of possible readers: 1. Those already convinced. 2. Those that won't be convinced without empirical evidence. 3. Those that won't be convinced.