[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: time to rewrite dpkg



* Marcus Brinkmann said:

> > > Of course, you are entitled to your opinion. But the decisions are made by
> > > people who to do the work.
> > Not in this case. This is not their graduate project, nor an experiment.
> > It's a package which the entire Debian distribution relies on
> 
> You're wrong, reread what Aaron said. The CURRENT dpkg is what the entire
> distribution relies on. The CURRENT dpkg is written in C. You should be
> happy.
> 
> If you believe it would be better to rewrite dpkg in C, go for it. More
> power to you!
I have just one question to you - have you read the ENTIRE thread??? Or just
several lines? If so, then please go back AND READ IT. Only then you have a
right to jump upon me like that. Before you joined the discussion, we were
DISCUSSING matters, now we're FIGHTING and flaming each other. Thank you.

> > > The size of the language or the size of the binaries?
> > binaries, of course. Who cares about the language?
> 
> Interesting. So you prefer bloated program code instead of bloated binaries?
> The time a human needs to understand and maintain a program is less
> valuaable to you than a few kilobytes of source code? People read program
> code, but they almost never read binaries directly.
Yeah, yeah. Go back to one of your previous postings and read what you said:
"language doesn't guarantee anything. You have to code it." These are your
words and right now you are contradicting yourself. IF you design the code
well and implement it well, then it doesn't matter what language you use.
You seem to me a little bit fanatic, because what you suggest in the
statement above is that C cannot be used to write clear programs. That's a
bag of moonshine. C, C++, Python, Lisp, Scheme, Smalltalk - you name it, all
can be used to write awfully complicated code which nobody understands. The
design is what matters when you talk about readibility of the code. Look at
the linux sources, they are in C and theay readable and clear. Point taken?

> > > The language was carefully designed to avoid bloat of the binaries. C++ does
> > Dream. C++ does bloat programs.
> 
> Some compiler bloat. The language does not.
Yes, but you use a compiler to produce a binary, not the language...

> And bloat is put a bit too simple. I don't care about a few kilobytes if it
> has direct and noticeable positive effect in the source code.
You don't care, good. I do care.

> > You would be surprised what problems people have with all the try/catch
> > blocks. 
> 
> You would be surprised what problems people have with all this pointer
> arithmetic. 
> You would be surprised what problems people have with all these regular
> expressions.
> You would be surprised what problems people have with all these parentheses.
> You would be surprised what problems people have with all these gotos.
> You would be surprised what problems people have with all these mnemonics.
> Did I get my point across?
yes, now I know you understand it well. But I don't know why are you trying
to pick up a flamewar? What are you so angry about? Why can't you discuss
instead of flaming?

> > You are talking about things like STL or other template-based libraries?
> > Then they will increase the binary size, and they will do it significantly.
> 
> How scary. What exactly is the problem with a bigger binary?
Hmm... what exactly? If we have 10 programs written in C that have to fit 
on one diskette and each of them adds extra 30KB, plus several dozens of
kilobytes for the libraries, then what has to fit on one diskette is at the
very least 300KB, and that's the problem I see.

> > > Your knowledge of the C++ language is a few years behind of current
> > > standards and implementation.
> > C++ isn't in state of flux anymore, true, but egcs (and it's the only
> > compiler around on the GNU platform which can be used to do serious C++
> > programming) is.
> 
> See, I am the maintainer of libgtkmm. This is a huge wrapper library around
> Gtk, which uses a lot of templates, classes, derivation, whatever. The
> maintainer (currently about three people are actively working on the code)
> were able to maintain compatibility even with g++ 2.7.2.3 (which is
> horribly broken in every respect) until recently. I don't see them rewriting
> their code everytime with another egcs release.
I never said every time. Once again, please, read the entire thread.

marek

Attachment: pgpBz5gHU64jc.pgp
Description: PGP signature


Reply to: