Re: [Ekiga-devel-list] Design of the engine : why abstract Ekiga::Foo and Ekiga::FooImpl matter

[Julien Puydt <jpuydt free fr>]

Hi,

Le 14/01/2015 10:32, Eugen Dedu a écrit :
> On 14/01/15 08:43, Julien Puydt wrote:
> > I think the purely abstract Ekiga::Foo and Ekiga::FooImpl is better : it
> > is more expensive, but you do get what you paid for.
>
> Hi Julien,
>
> In case my opinion is useful:  I think you are right in theory and also
> in a big program with many developers working 100% on it.  However, I
> personnaly vote for pragmatism, for simple code ("simple is better!") In
> our case, each time the code gets better from theory point of view, gets
> harder to understand by someone wishing to be involved of.
>
> Cheers!


Eh, my pragmatism says that it's the contrary : if we have few 
developers with little spare time, it's vitally important to make sure 
that code which compiles is code which works. Let the tools handle as 
much as possible. Let's get out of the way so they can help. Will you 
buy it if I call it "hardened design" ?


I call "very bad" a situation where a code modification somewhere will 
compile perfectly, but silently and subtly break a few other places, 
which will have to be found out by manual testing, hopefully before a 
release by a tester... but more realistically after the release by a 
user, tracked and fixed one by one with no help from the tools.


You can get the impression that things are easy and your productivity is 
extremely high when you get something working in five minutes. But if 
hours of debugging and fixing are hidden around the corner, I don't 
think it's wise.


I have seen students write a fusion sort implementation which worked 
wonderfully when given a list/array of length a power of two, and broke 
in all other cases. But the code was so wonderfully short !


Let's not forget there's a fine line between simple and stupid!


Snark