python vs perl lines of code

[akameswaran at gmail.com]

> 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
> readability.

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?