Fwd: Re: [Lame-dev] Re: Fwd: ping-pong patches, round #3

[Alexander L. <Ale...@le...>]

------ Forwarded message ------
             From: Alexander Leidinger <Alexander@Leidinger.net>
          Subject: Re: [Lame-dev] Re: Fwd: ping-pong patches, round #3
             Date: Thu, 14 Dec 2000 11:46:31 +0100 (CET)
               To: n-s...@ic...

On 14 Dec, Naoki Shibata wrote:

>>Yes, the old one worked, but the new one is "more correct", or better:
>>it gives more hints about the code flow.
> 
>>That's IMHO an improvement, and improvements are good by definition,
>>right?
>>He produces an infrastructure on
>>which he want's to improve various things. We can't do listening tests
>>on not written code, and maintaining a huge diff is very time consuming,
>>time which is better spend on improving lame.
> 
> If you believe so, please make your branch and make cleaner, c++ compilable,
> lower memory consumption and 8086 friendly lame on that branch. I always

I don't care about C++ compatibility and 8086 friendly code, but if we
can get a lame which uses less memory while still being as fast and good
as now I will applaud.

> thought that I storongly dislike Frank's code. I also think he's changing
> code because simply he doesn't like the original code, and after his change,
> I don't like his new code. Perhaps it's a matter of each person's sense of values.

Do we talk about his style or about the quality of his code?

> I can't explain why I don't like his code. I think the original code is
> not so bad, and his new code always looks VERY UGLY.

I didn't like his style entirely, but there isn't a style which
satisfies everyone.
And if you look at the quality, it looks sometimes strange, but if you
have a closer look at it, and perhaps ask Frank about details, you will
see he has some valid points in doing it the way he does it (perhaps not
everytime, but most of the time).

He isn't diplomatic, and I didn't want to have him as a coworker, but he
does good work.

> Do you really think T_IF,T_ELIF,T_END macros introduced by Frank is good?

At the first look, they look strange/ugly. But if I look a little bit
longer at it, it is just syntactic sugar, it's "switch () {case ...}"
for strings. The names of those macros aren't the best ones, but it's
not the first time I see such macros. I can't say "I have problems" or
"I have no problems" with them.

> Do you really think new bitrate histgram display introduced by Frank is good?
> I dislike both of them.

Are you talking about "%" and "*"? If yes: Yes, I like the additional
information I get out of this histogram, I didn't like the "%"
character, but I like the information he represents.

> Again, perhaps this is a matter of each person's sense of values, but it
> seems that at least Mark, I and Takehiro don't like Frank's sense of
> values. I strongly hope that Frank's code will never be introduced if
> there is no functional improvement.

Let's talk about KLEMM_43 (tables.c, see ping-pong patches #3): He
want's wo make small changes, step after step. But Mark didn't likes it.
If it didn't improves speed/quality, it shouldn't get committed (that's
how I understand Mark). But it's a lot harder to find bugs after a huge
megapatch than to find bugs which slept in with a small modification.

Sometimes you need first a "cosmetic change" (I'm talking about
refactoring) to be able make a good functional improvement. And I didn't
like mixing functional improvements with cosmetic changes.

BTW.: What does functional improvement mean for you? Is less memory
usage while producing the same quality in the same amount of time a
functional improvement for you?

Bye,
Alexander.

-- 
                Where do you think you're going today?

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E