GSoC application review - reimplementing personal metadata importers

[Matěj Laitl]

On 25. 4. 2013 Konrad Zemek wrote:
> I'm a mature programmer. I have well over five years of real programming
> experience (not the home-grown kind), and in that there's over half a
> year of commercial experience. I'm not claiming I'm very experienced -
> obviously five years is a lot less than ten or fifteen, but still that's
> enough to have both "fastest code" and "shortest code" phases well
> behind me. I favor clean, easily understandable and maintanable code,
> making (sensible) sacrifices of speed and linecount. I've also
> programmed in assembly a bit and analyzed how compilers work, so I'm
> very much aware that modern compilers more often than not optimize the
> code that makes its intentions clear to be actually faster than
> hand-optimized code doing the same thing.
> 
> That's basically what I've done in my first (of many, hopefully) review;
> the cleanup wasn't to make it faster, it was for it to be understandable
> (e.g. I myself had problems with figuring out what value is actually
> returned), and therefore of better quality.

The answer couldn't have been better. ;) (not that any answer was required)

[other students: this doesn't mean you need to have 5 year experience of 
professional programming, in fact this by itself shouldn't affect the chance of 
being accepted at all. GSoC is much more about learning than "getting work 
done". It is just a coincidence that "getting work done" is the best way of 
learning.]

Konrad, you may be actually more experienced programmer than many of us (e.g. 
me, hehe) :-), but we'd still love to show/teach you specifics of F/LOSS.

> And to touch on the private inheritance. ;-) Although it's seldom used,
> it actually makes code clearer and gives out more information at a
> glance than composition. (Of course composition should be favored over
> inheritance, but inheritance should be used where appropriate.) The
> thing is to read it the right way: while you'd read "A: public
> BaseClass" as "A is a BaseClass", private inheritance would be read as
> "A is implemented in terms of BaseClass". So now that very single-line
> declaration gives you information that underneath A is built on top of
> BaseClass - and all of that without looking through A's actual
> implementation to see that A is a BaseClass wrapper. It's all about
> semantics and choosing a language construct that best represents what
> the code is supposed to do.

I wouldn't phrase myself better. ;)

	Matěj