Re: [glob2-devel] Flame thread (insults, code rewrite and other trolls!)

[Kai Antweiler]

> No, you are arguing general points, because of philosophical reasons

I remember that you started this philosophical "discussion".
And you're quite aggressive too - though not a match for Bradley.
(By the way: I have removed some of your insults from the "> lines")


> PROBLEM : printfs are used, they are in the process of being replaced.

No!
A much bigger problem was brought up by focussing on the "evilness"
of dependencies in general.


> SOLUTION A : use boost
> CON : is not a used dependency. compile times long(er).
> PRO : off-the-shelf. works.
>
> SOLUTION B implement our own solution
> CON : not tested. Need to be developped
> PRO : exactly adapted to our needs, was done in a few hours.
>

No!!!

You missed the point.
It is CON :
1. you need to debug (and miss more bugs than the lib guys)
2. you need to document (and probably won't do enough)
3. you don't know what your needs are and eventually have to rewrite
   things big style, because you'd been so minimalistic.

The development time is just waste for the implementer.
The rest damages everyone.
Don't tell me you never encountered these points.

The only good reason not to implement your ideas as extensively as
possible is that it takes too much time - which is a really good
argument.  But it does not cut it when you use libraries.

Please take a look at:
http://mitpress.mit.edu/sicp/full-text/book/book.html

or at least watch the videos:
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/

(If this doesn't convince you, you'll still have got a bit amusement.)


> Repetition is not proof. 

Bradley you should stop putting so much effort into convincing people,
after you have recognized that they don't want to be convinced.
This is the point when a useful discussion becomes a religious battle.
No matter who's right: everyone will loose.


> solutions can be evaluated precisely. To convince, you must _show_ the 
> tradeofs to be in favour of your side.

It's not that easy.  Knowing the arguments doesn't imply knowing the
weight of the arguments.  Going into the extremes like saying that:
using 5 million dependencies will result into much too long compile
time or that in the worst case each feature you add will cause you to
rewrite every function of the code, leads to wrong impressions.


> plus flaming people is no good to convince anyone. 

Yes.  So please take a minute or two before sending your next mail
and look through it, if it contains any funny remark that might insult
someone.  (Both of you)


> Godwin. Insult. You need to calm down, you now ?

Agreed.  I don't repeat it, since in germany you would have lost
your job for this.


> games are all about tuning...

Really good point.  And if your structure doesn't allow easy tuning
you worsen your game.  Leo and I are constantly proposing improvements
which should be doable in a few minutes, but are not.

(By the way Leo had thought this "construction site exploitation" bug
that allows you to imprison your opponent, and got to something which
should be extensible to a solution.)


> Warning, I will use CAPS because I feel like it.
>
> WE ARE IMPLEMENTING A TINY BIT OF FUNCTIONNALITY. NOT "A WHOLE LIBRARY OF 
> FUNCTIONS". 

True.  So we have to find our own way between being minimalistic and
that whole library.
I don't know you.  Maybe you are into algorithms (like me) and don't
see a reason why being minimal will turn out bad on the average.

So here is the thing:
Software/Algorithm reusablity is the source of a new layer of
thinking.  You don't think about computer programs as circuits.  You
need layers of abstraction to do something big.
(Or you get a piece of code of which nobody will know what it does.)
For everything you do, you have to find the right layer of abstraction,
and with libraries you have more layers you can choose from, and 
you can easily change between them.

Try to write algorithms using turing machines - it's fun, but you
won't get far.


>> Refactoring code is fine. Chaning existing code is fine. But remaking
>> it again and again, same old shit, that isn't great or good. Make it
>> once, and make it generic enough to be used over and over again.
>> Depending on the number of times you use the code, you can save 80-90%
>> of the time. You also keep new bugs from being introduced by mistakes.
>
> This is true. Besides the point but true.

pardon?


I hope I haven't repeated myself, or someone else.
And I hope I haven't insulted anyone.

-- 
Kai Antweiler