Re^5: Code Statements/Lines per Function Point

Update: Anyone who understands function-points will realize from my post that I didn't. However, the point I'm making still has validity. You cannot take the same number of function-points and the cost/fp in language A and use them to estimate the total cost when implementing in language B. That's the point I didn't realize I was trying to make.

It would be interesting, however, to see what the average cost/fp is in Perl as opposed to other languages, such as C.

I don't know of any such project. hv's response to your post may have some useful info.

However, I feel the need to correct a further misconception. The number of function-points will be lower in Perl than in most comparable languages. Let's take C, for example, and use a case that's heavily biased towards Perl - creating a linked list.

In C, this would require a bunch of maintenance code dealing with pointer arithmetic and calls to malloc(), free(), and code to insert, delete, and a bunch of state information.
In Perl, you use an array.

The code provides the exact same functionality, but requires as few as 10% of the function-points in Perl as in C.

Let's take another example that's heavily biased to Perl - parsing textfiles. Again, let's compare vs. C.

In C, you have to open the file, allocate memory, use tok(), strcmp, and a bunch of other crazy stuff. When I used to do this, I had macros calling macros calling macros ... and it was still ugly.
In Perl, you open the file, use a regex or two, add the values to an array of hashes, and be done with it.

Again, we're talking about 90% fewer function-points in Perl as in C.

You may think I'm picking on C cause it showcases Perl very nicely, but Pascal isn't much better. Java starts to compare well, but still comes up short. Frankly, Perl is simply more expressive than nearly any other language in common use. And, that doesn't even count the code that using CPAN provides.

In other words, I don't think you're going to be able to take function-point counts from another language and have them be useful in estimating time to develop in Perl.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Comment on Re^5: Code Statements/Lines per Function Point

Replies are listed 'Best First'.
Re^6: Code Statements/Lines per Function Point by PerlingTheUK (Hermit) on Aug 25, 2004 at 14:16 UTC
Thank you dragonchild, I see your point. Yet I do not really want to compare Perl against any other language. I just would like to use my new understanding of software engineering and reviewing of code and productivity to get a hang about my own abilities and much more so even be able to estimate the cost of future developments in a slightly better way. As fas as now I use to build a very detailed framework of code on my mind and then calculating down that the average slightly complicated Regexp costs me 10 minutes, opening a file and reading it costs me 1.5, ... The problem is that as soon as I decide to use slightly different objects, define a different output file type for convenience, ... The additional time required might be affected by this. So I try to find a more general approach, that does not force me to sit down for two hours and basically plan how to write a program that takes me two weeks time when considering the cost, as this very fast approach normally does. Yet I would like to be able to estimate how the effort of a line of Delphi/Pascal code relates to Perl. I think it is true that the line number cannot be considered so the operations approach seems to be very reasonable and also produces a compareable value. Cheers, PerlingTheUK	[reply]
Re^7: Code Statements/Lines per Function Point by dragonchild (Archbishop) on Aug 25, 2004 at 14:32 UTC
I think the issue you're trying to grasp at is how long does it take to implement a given specification in a given language. Function-points (which I just learned about ... thank you!) are probably the sanest (if very complex) way of describing the cost of the specification in a language-agnostic fashion. The problem is that the cost for a given language depends a great deal on many factors, some of which could be: The expressiveness of the language The amount of book-keeping the language provides for you The expected performance of the result The skill of the programmer(s), both in terms of the best and the average The size of the team (bigger is not always better!) The expected maintainers The allowed usage of outside modules The architecture decisions that have already been made Any current codebase and how easy/safe it is to make modifications to it For example, I might be tasked with building a web application from scratch. I am told to do what needs done to make it happen. So, I pick Apache, mod_perl, Perl 5.8.x, and use whatever CPAN modules are necessary to make it happen. But, if I was told I had to use Java, Oracle's AppServer, and I had to interface with existing code, the amount of time it takes goes up dramatically, even though I am handed what seems like half the project on a silver platter. Both of those assume a single developer. What if I had to interface with three teams, one of which is at a different location, and coordinate between two departments? What if I had to use more than one language? What I'm getting at is that the cost of a project very rarely depends mostly on the choice of language. In fact, the choice of language may account for less than 10% of the cost of a project. Now, one should minimize as many costs as possible, so choosing the right language for the task (which may not always be Perl) is a good goal. However, focusing on it may be premature optimization. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]