Xdg-list digest, Vol 1 #432 - 11 msgs

[Linas Vepstas]

Hi George,

I have a hard time taking this argument seriously.  I don't find 
the technical claims to be convincing.  There are numerous factual
errors, exagerations, incorrect and imprecise claims.  You are
attacking glib without actually understanding what it is, and 
what it means to use it.  

On Mon, Jul 21, 2003 at 09:56:30AM -0400, George Staikos was heard to remark:
> 
>   If the glib is so trivial, the implementing such structures again is also 
> trivial.  Come on, I've done it dozens of times.  I know what the effort is 
> and it's minor.

glib is not trivial, there's thousands of lines of code in there.
Its a lot of work.  Saying glib is trivial is like saying STL is
trivial: its not.

>   We're talking about the interface here.  If you think glib should be allowed 
> internally, so should any other library that developers of this software want 
> to use that is licence compatible.

Some API's want to return linked lists.  Should every library define 
its own linked list format?

>    Great, so you accept that other options are also fair.  Proposal: Qt based 
> libraries as part of the freedesktop spec.  Oh doesn't sound so good anymore?

Qt is not suitable for use inside of non-graphical, server apps. 
Its also not suitable for C programmers.

> > links against? The containers stuff is a small and ultimately trivial
> > part of glib, if you don't use them, people will simply invent their own
> 
>    What other part do you intend to use exactly?
> 
> > linked list structures, which is a pointless waste of time. If they do
> > use them, it's still just a linked list, which you would have to have
> > dealt with anyway.
> 
>    It took you far longer to write this email than it would take to make a 
> linked list.

Would an acceptable compromise position be to write a new, C linked list
utility, specificially for use in public API's ?  

What exactly are we arguing over here?

>   Not all developers agree that glib is clean or easy to maintain.

Who, besides you, thinks that glib is messy?
Can we stick to the facts?

>    I argue that glib decreases the quality of code.  Can you call me wrong?  
> No, you can disagree, that's all.

No, you're wrong.  This is a baseless claim, based on your lack of
experience.   You haven't actually written much C code that uses
glib.  I suspect you code in C++ mostly.  The world looks different
when you code mostly in C++.

>    No, because it incurs performance penalties for many, lengthens development 
> time, and_makes_us_maintain_ugly_and_inferior_code.

All of these statements are factually incorrect.   

> Be honest.

Don't throw rocks if you live in a glass house.

>    My views on this are clear, 

But they are based on mis-apprehensions and un-truths. 

> If you want 
> everyone to cooperate, you have to be sensitive to all of their views, all of 
> their requirements, 

I haven't seen any requirements yet ... 

> and understanding of their points of view.  

And the view seems to boil down to "C sucks", which is a non-starter.

Do you actually have a proposal for something better?  If a programmer
wants to code in C, do you know of *any* library that even comes close
to what glib provides?


--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933