python vs perl lines of code
akameswaran at gmail.com
akameswaran at gmail.com
Fri May 19 23:26:30 CEST 2006
> Yes, like the shorter version might be overlooking many real world
> situations and is naive code. As for generalization, if you bet that the
> shorter one is later written, that's to me a generalization. I agree that
> there is a change that after reexamining the code, and algorithm can be
> written shorter, but I have also seen algorithms refactored for better
All very good points - I need to be more specific. I've been working
on some data analysis stuff etc, lately - so I'm often time just
reimplementing a specific algo or library I've written. The actual
program as a whole generaly does get larger. But I was really
thinking about a handful of data manipulation or aggregation algo's
that were functionaly fine - but I realized could be done better.
> > Two points here. I have since the beginning stating a HYPOTHESIS - a
> > theory. One which my experince leads me think MIGHT be true.
> Enough to bet on it ;-)
I'm a gambling man, what can I say?
> >> Yup, and this is exactly what frightens me the whole time in this
> >> thread. People looking for quality rules based on line count. It's
> >> wrong.
> > Please note my original hypothesis was maintainability - not quality!
> Aren't those closely related?
Yep, but not the same thing. Maintainability is a subset of quality.
> > important important distinction - and one I may have muddles myself as
> > I got drawn into the conversation.
> > And what frightens me are people who are so dogmatically convinced
> > becasue of their long 10 years of experience - that they know exactly
> > what does and doesn't matter, and have no intellectual curiosity
> > anymore. There are no objective tests for maintainability that I am
> > aware of.
> Because it depends a lot on the skill level of the maintainer. By just
> counting lines and characters you can't measure quality IMO. It's a naive
> way of measuring and it reminds me of the early days of search engines.
> And if you mistake understanding that it's not a good way to measure
> things as having no intellectual curiosity, you're again mistaken.
All I would ask is what objective evidence does either of actually
have? How can you know? What is a fair way to even count line
numbers? From there how do we begin to objectively measure software
quality? That's why this discussion interests me, and why I don't
understand why you are so adamant it doesn't work. I'll agree that I
have never seen line count/char count type data used for anything other
than marketing swill and kitty litter. Doesn't mean it can't be used.
But first things first... and this one I think is solvable - their has
got to be an equitable way to count how much code was written - maybe
it isn't lines maybe it is. In truth, since you are so opposed to the
idea, I'd be curious if you can think of a way to measure the quantity
of code objectively? ANd that's it - not can we make a qualitative
statement beyond that. But simply can we quanitfy the amount of code
in some fashion that allows a reasonable comparison?
More information about the Python-list