This looks very good to me, yet is there any given source linking the number of opcodes to function points, so I can roughly use them to estimate the time required for a project?
| [reply] |
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
| [reply] |
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.
| [reply] |