THe interest, on my part, is more academic than practical. I find data, particularly "dirty" data very fascinating, and I like trying to find ways to make useful statements when all you have is bad data. Maybe a pipe-dream, but it's still fun to try. So this little exercise would be quite enjoyable - a horribly dirty data set that nobody thinks could be useful. The good guys always fall for the bad data!! At an architectural or even development management perspective - there is always someone, somewhere who wants to evaluate "developer efficiency" or something similarly vague concept for which there aren't good tools for evaluation. Let's face it in the corp world these kind of figures are sometimes percieved to have value. SO if I were a corp programmer in python and a manager says to me my output is way behind the perl guys - I could pull this silly fact and .... well you see.
My quick comment about his code being torn apart by perl advocates was mainly because his post seems to be complimentary to python - but your right both sides would tear him apart. ANd you took the flame bait so I'll respond :D Perhaps - ALL OTHER THINGS BEINGS EQUAL - should better be read as WRITTEN BY ME!! For the most part I have found it easier to maintain the shorter programs I have written and found it more time consuming to maintain longer programs. Really what's so dumb about this? Have you found, as a general trend you spend more time maintaining your shorter programs? I did say it was flame bait, and I never said the statement is useful - all other things are never equal in the real world. I am constantly amused by how we, as programmers, spend so much time quantifying everything else, react so negatively when anyone suggests quantitative analysis of code for anything except execution time. Course what interests me now - is how could we prove if my statement was in fact very very dumb or not? In all honesty I don't know, but it sure tastes good grilled. -- http://mail.python.org/mailman/listinfo/python-list
