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

[Bradley Arsenault]

On 5/3/06, Nuage <address@hidden> wrote:
> Hello, please don't read this e-mail, you'll just loose your time, unless you
> want to join the flame party.
>
> Bradley Arsenault wrote:
> > You guys suffer from Not Invented Here syndrome:
> > http://en.wikipedia.org/wiki/Not_Invented_Here
>
> 1) Please don't insult us. (IRMBTSDMITWIW syndrome for you, nah. "I Repeat
> Myself Because They Still Don't Make It The Way I Want")
I'm not insulting you. I'm arguing ideals that this projects
developers hold that I believe are keeping this project from being
developed at a faster rate.

> 2) You're saying the same things many times. Most of the time, your emails are
> long and redundant, with the same key idea all the time, and then don't really
> helps to solve the problem, which is the goal of the mailing list. (I am about
> to stop reading your emails because of this.) Maybe you just need to know that
> reading english takes us longer than you.
I reinforce opponions on purpose, its how we learn to write persuasive
writing in english class.

I write long emails because I need to support my points. I don't try
to just say "Ok, believe what I believe because I say so". I try for a
more convincing approach, "Believe me for these reasons, and this is
the information supporting these reasons. This is how things could be
done better, this is why, I hope you agree with me."

Summarries don't convince anyone.

> 3) We are trying take the best decision given what we thing, which can be
> different of what you think. You have to accept it. (This is not a reason to
> "flood" the mailing list with your long emails.)

So you think that I can not put what i think is wrong into question,
and that I should just blindly follow the original coders of the
project on their ideals even if I think their ideals are bad. Thats
like saying "Lets all become Nazis!" without any real reason or
background information.


> Now, about code rewriting:

> - I sometimes rewrite code because I can write it faster than understand the
> code of someone else.
The code of someone else is already made, tested, debugged, etc...


> - I sometimes rewrite code because I can tune it for my own needs.
Like I'll explain below, you tune it less often than not.

> - I sometimes rewrite code because I don't need all the features.
Thats a blatent reason, more features is generally better unless they
impede on usability.

> - I sometimes rewrite code because I'm lazy to read the documentation.
Another blatent reason, you probably are too lazy to write the
documentation as well and make it difficult for others to understand
your code.

> - I sometimes rewrite code because the other code is buged.
This is a good reason, but very rare. Most of the time, the library
has been tested by the author and works fine, and will probably work
better than anything you write because they have had the time to test
their library (because they devoted much more time than you have into
making it).

> - I sometimes rewrite code because it's some funny code to write.
Code can be fun to write, but the boring code isn't. Further more, its
generally only fun to write code that you *haven't* written before. If
you have ever lost your changes to the source of a program and had to
remake them, you will understand.



> - As much as I don't re-use the code of someone else, I don't re-use my own
> code, because I want to make it clearer, change the internal structure, tune it
> another way, or anything.
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.


> - I do know why it's not good to rewrite code, any I know why I still do it.

It sounds to me like you rewrite code because you don't make your code
abstract enough to be fine-tunable without changing its internals. If
you re-used code excessivly, to the point that you would be extremely
un-comfortable doing things the way you have done them, you would
probably find that more often than not you don't need to "change the
internals", because when you change the internals to suite one task,
you break another. So you design it in such a way that it can be used
everywhere you need it to. This can be said for small utilitiy
functions sitting here and there arround the source files, as well as
overall-reuse design patterns.

I'm not here to insult anyone. I'm not here to make your guy's lives
hell because you don't believe what I believe. If I absolutely hated
everyone here I wouldn't be working on the project.

No. I am here because I think the project might be more productive if
they followed atleast part of what I have learned from various books.
I see so much potential in this project, I can see that the developers
have done a very good job with it. I also see that the projects
development is slow, and, in particular, I have noticed that the
project reinvents the wheel many times over, which is probably why the
development is as slow as it is.

I see that the project could benifit from organization, maybe a bit of
targetted programming (rather than re-inventing the wheel). I have
observed this. A while back I decided I wasn't going to sit back and
let a project that I liked allot continue on slowly and painfully, if
perhaps I could do something about it.

So i've been trying. Trying to convince everyone that code re-use is
good. Trying to convince everyone to make a specific, global to-do
list. I'm defeated by the majority, however, you guys are very
resistant to change, even though I try to give clear, and full
explanations (and rather long) as to why I think a particular idea is
a bad one. I don't cut the slack and give short explanations because
short explanations don't explain anything, they summarize. And people
aren't convinced by summaries.