Re: Time to rewrite dpkg IN IDL! :)
On Fri, May 21, 1999 at 08:26:00AM +1000, Hamish Moffatt wrote: Besides, any advantage in a nice OO design is lost by implementing it in C++! There is no need to do it in C++. My whole point is that I think an OO methodology would work well in this case simply due to the maintainability factor. gasp We could do it in .ADA!/gasp daniel
Re: Time to rewrite dpkg IN IDL! :)
And thus spake Daniel James Patterson, on Fri, May 21, 1999 at 09:30:31AM +1000: On Fri, May 21, 1999 at 08:26:00AM +1000, Hamish Moffatt wrote: Besides, any advantage in a nice OO design is lost by implementing it in C++! There is no need to do it in C++. My whole point is that I think an OO methodology would work well in this case simply due to the maintainability factor. gasp We could do it in .ADA!/gasp One thing that people seem to be forgetting (not necessarily you, but I figured this was a good time to pipe in) is that it is desirable for dpkg to 1) have a small footprint and 2) have few depencies. I see the second as more important, because fewer dependencies mean fewer chances to screw something up that will break dpkg (as we've seen with C++ libraries breaking apt, etc). -- Elie Rosenblum That is not dead which can eternal lie, http://www.cosanostra.net And with strange aeons even death may die. Admin / Mercenary / System Programmer - _The Necronomicon_
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 01:20:20AM -0700, Aaron Van Couwenberghe wrote: Argo-UML. It's a UML design tool, designed to export Java; however, its nature makes it useful for any (distributed or otherwise) OO design project. I don't have a URL with me. http://www.ics.uci.edu/pub/arch/uml/index.html found that on freshmeat. daniel
Re: Time to rewrite dpkg IN IDL! :)
On Fri, May 21, 1999 at 08:26:00AM +1000, Hamish Moffatt wrote: I think a good object-oriented design can be easier to follow too. In circumstances where there is naturally some use for inheritance it is very useful indeed. I don't see any natural inheritance in managing packages, though. Well just because you don't see one doesn't mean there isn't any. For example, we can have different package formats (and different versions of our own format, compatibility!) represented by classes derived from a common abstract class. This makes adding support for additional formats (or changing the exisiting format while adding compatibility mode) very easy and painless. OO is not only useful for natural inheritance, or, to put it another way, there are lots of inheritances were you don't see them at first glance. I think that forcing a procedural program into classes just for the sake of it would destroy the clarity you're looking for. Absolutely. Happily, package management is not procedural at all. It can be implemented in a procedural way of course (anything can). But object management will be useful. The recognition for Object Oriented languages has still a long way to go. Mathematicians are way ahead of programmers with this respect (you see, math is an OO modelling of the whole world and even more. Math is also descriptive, but this is orthogonal to this discussion :). Thanks, Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: Time to rewrite dpkg IN IDL! :)
Aaron Van Couwenberghe [EMAIL PROTECTED] writes: I have grown increasingly aware of FUD of this type about C++ and OO languages. OO is designed to *increase* interoperability, flexibility, and extensibility -- definately not the other way around. OO isn't limited to C++, and C++ isn't limited to OO. The two overlap, but they are far from identical. Some people dislike C++ because it's not OO *enough*! C is generally far more interoperable with other languages (even other OO languages) than C++ is. C++ is great if you're *only* using C++, but if you're using a different language, with a different object model (or none), you're in trouble. References to alien, polymorphic, multiply-inherited objects are scary, especially when much of their structure and behavior is officially defined as implementation defined by the language standard. But C has its own problems, not least of which is that it's a primitive procedural language with no built-in OO features to speak of. And with emphasis on primitive. I think an interesting approach would be to use CORBA. Make dpkg into a networkable server for polymorphic package objects! G'wan, I dare ya! :-) -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote: I think an interesting approach would be to use CORBA. Make dpkg into a networkable server for polymorphic package objects! G'wan, I dare ya! :-) I don't see why not. Software is becomming more and more complex, people are expecting more and more out of it. The more modern and advanced things Debian can tout, the cooler we'll look. I don't have any experience in industry working with OO, but I have a little knowledge from what I work on at uni. A proper OO approach could produce a highly maintainable and extensible (and non-language specific) design that could be implemented easily enough in _many_ languages. There are a few OO tools (I'm thinking Rational Rose in particular) that can do code generation from UML work, which could mean that we could decide on a design before decending to our baser instincts to argue about what language it should be implemented in :) daniel
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 08:25:17PM +1000, Daniel James Patterson wrote: On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote: There are a few OO tools (I'm thinking Rational Rose in particular) that can do code generation from UML work, which could mean that we could decide on a design before decending to our baser instincts to argue about what language it should be implemented in :) Speaking of baser instincts, Rationale Rose isn't free software, is it? Are there any nice (or even not-nice) OO design tools that are? Apart from xfig, I mean. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``There's nothing worse than people with a clue. They're always disagreeing with you.'' -- Andrew Over pgp86pUKDMA8S.pgp Description: PGP signature
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 08:44:39PM +1000, Anthony Towns wrote: Speaking of baser instincts, Rationale Rose isn't free software, is it? Are there any nice (or even not-nice) OO design tools that are? No unfortunatley it isnt. There is a solaris version, which is a bad port of the win32 version, and the win32 version doesn't run under wine. I have found dia useful, but only from a diagram drawing point of view, unlike Rose which does all the extra bits as well. daniel
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 08:25:17PM +1000, Daniel James Patterson wrote: On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote: I think an interesting approach would be to use CORBA. Make dpkg into a networkable server for polymorphic package objects! G'wan, I dare ya! :-) I don't see why not. How about it's complete overkill? (and non-language specific) design that could be implemented easily enough in _many_ languages. There are a few OO tools (I'm thinking Rational Rose in particular) that can do code generation from UML work, which could mean that we could decide on a design before decending to our baser instincts to argue about what language it should be implemented in :) I don't see anything in the Debian packaging system which fits OO very well at all. We have just one type of package; there are no special sub-types, for example. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 09:14:26PM +1000, Hamish Moffatt wrote: How about it's complete overkill? I don't think so. Yes you can write maintainable code with plain C, but with the number of developers moving in and out of Debian, I think that a decent OO approach for core software could make it more maintainable for _everyone_. I often feel that I'd like to help contribute code to some things, but, not being an overly confident programmer, I am daunted by code that takes a long time to understand. I personally find OO design much easier to follow. This is personal preference however. I don't see anything in the Debian packaging system which fits OO very well at all. We have just one type of package; there are no special sub-types, for example. Perhaps there should be then? After the little work I've done (yes, and _you_ know just how much Hamish :P), I do see advantages behind the OO approach. Besides, as I said, at this stage, do the analysis, not the coding. It can always be scrapped if it looks like it would be pointless, but I'd like to see some non-emotive reasons not to even _consider_ it. daniel
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 08:54:45PM +1000, Daniel James Patterson wrote: On Thu, May 20, 1999 at 08:44:39PM +1000, Anthony Towns wrote: Speaking of baser instincts, Rationale Rose isn't free software, is it? Are there any nice (or even not-nice) OO design tools that are? No unfortunatley it isnt. There is a solaris version, which is a bad port of the win32 version, and the win32 version doesn't run under wine. Argo-UML. It's a UML design tool, designed to export Java; however, its nature makes it useful for any (distributed or otherwise) OO design project. I don't have a URL with me. -Aaron
Re: Time to rewrite dpkg IN IDL! :)
On Fri, May 21, 1999 at 12:27:32AM +1000, Craig Sanders wrote: C++ may be OO, but it's not very good OOand it tends to compile into code which is both bloated and slow. dpkg is already far too slow on old hardware...hell, it's too slow on a P200 with 200MB of RAM, now that the status and available files have over 3300 packages detailed in them. Yeah, it's slow, and it's written in C. And you want to cinvince me by your un-emotional argumentation that it will be even slower in C++? Strange. Last time I took a look at Stroustrups language it seemed that it would be carefully designed to not enforce too much overhead on language features, and no overhead on language features not used. Stroustrups book goes into detail, and always mentions which run time overhead you have to expect when you use a certain language feature. Most features are only one function call away. Exceptions are the single exception. Use of them will reduce the amount of code you have to write, and improves error handling drastically. Some functions that have a lot of error conditions to check that are fourty lines of C code with deep nesting are reduced to four or five lines of flat C++ code. The speed of dpkg has little to do with the language (as long as you use a compiled and not interpreted language). The number of packages is the cause of the speed problem, and the involved algorithms (parsing the ASCII file and putting it into a data structure). I am sure there is really room of improvement here. Picking one compiled language in favour of another for speed consideration but ignoring things like maintenability and development of code looks simple-minded to me. The difference in speed will be unnoticable if the same algorithms are used. Marcus -- The purpose of Free Software is Free Software. The End and the Means are the same. -- Craig Sanders Marcus Brinkmann [EMAIL PROTECTED]
Re: Time to rewrite dpkg IN IDL! :)
Hamish Moffatt [EMAIL PROTECTED] writes: On Thu, May 20, 1999 at 08:25:17PM +1000, Daniel James Patterson wrote: On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote: I think an interesting approach would be to use CORBA. Make dpkg into a networkable server for polymorphic package objects! G'wan, I dare ya! :-) I don't see why not. How about it's complete overkill? Sure, and without complete overkill, how will we take full advantage of the second-system effect? :-) I don't see anything in the Debian packaging system which fits OO very well at all. We have just one type of package; there are no special sub-types, for example. Then you're not looking very carefully. It's overkill may turn out to be a valid objection, but it couldn't benefit from OO is, IMO, completely false. Elisp packages spring to mind. We *do* have different classes of package; we just force them all into the same mold. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Time to rewrite dpkg IN IDL! :)
* Marcus Brinkmann said: dpkg is already far too slow on old hardware...hell, it's too slow on a P200 with 200MB of RAM, now that the status and available files have over 3300 packages detailed in them. Yeah, it's slow, and it's written in C. Linux is slow. It's written in C. Yeah... And you want to cinvince me by your un-emotional argumentation that it will be even slower in C++? [snip] ignoring things like maintenability and development of code looks simple-minded to me. The difference in speed will be unnoticable if the same algorithms are used. Now you've proven it. You're a fanatic. And you offend people. Thanks. marek pgpHDpoQLf95Z.pgp Description: PGP signature
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote: I think an interesting approach would be to use CORBA. Make dpkg into a networkable server for polymorphic package objects! G'wan, I dare ya! :-) Wowch! Nothing against CORBA, I love it, but if I think about the overhead. I recently compiled the 2.2 Kernel: 6 minutes, I compiled MICO: 2 hours!!! Ok, I know, handling the complexity of today computing needs powerful tools, and CORBA is jsut the way to go, but i do not think, the world is ripe for that in the *very basic* tool on any system. If you have to run a server like that just to install Debian, you can well double the minimum amount of needed memory. So, having a way to access dpkg via CORBA would be a great thing, but still it has to work without as well. Should be possible to have a simple C++ library but have IDLs for it as well in some way, so the objects can be shared. Ciao, Nobbi -- __ -- JESUS CHRIST IS LORD! -- To Him, even that machine here has to obey... -- -- _Norbert Nobbi Nemec -- Hindenburgstr. 44 ... D-91054 Erlangen ... Germany -- eMail: [EMAIL PROTECTED]Tel: +49-(0)-911-204180
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 09:27:10PM +1000, Daniel James Patterson wrote: On Thu, May 20, 1999 at 09:14:26PM +1000, Hamish Moffatt wrote: How about it's complete overkill? I don't think so. Yes you can write maintainable code with plain C, but with the number of developers moving in and out of Debian, I think that a decent OO approach for core software could make it more maintainable for _everyone_. I often feel that I'd like to help contribute code to some things, but, not being an overly confident programmer, I am daunted by code that takes a long time to understand. I personally find OO design much easier to follow. This is personal preference however. I think a good object-oriented design can be easier to follow too. In circumstances where there is naturally some use for inheritance it is very useful indeed. I don't see any natural inheritance in managing packages, though. I think that forcing a procedural program into classes just for the sake of it would destroy the clarity you're looking for. Besides, any advantage in a nice OO design is lost by implementing it in C++! Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 01:02:00PM -0700, Chris Waters wrote: Hamish Moffatt [EMAIL PROTECTED] writes: I don't see anything in the Debian packaging system which fits OO very well at all. We have just one type of package; there are no special sub-types, for example. Then you're not looking very carefully. It's overkill may turn out to be a valid objection, but it couldn't benefit from OO is, IMO, completely false. Elisp packages spring to mind. We *do* have different classes of package; we just force them all into the same mold. Can you expand the Elisp example? Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 08:45:09PM +0200, Marcus Brinkmann wrote: On Fri, May 21, 1999 at 12:27:32AM +1000, Craig Sanders wrote: C++ may be OO, but it's not very good OOand it tends to compile into code which is both bloated and slow. dpkg is already far too slow on old hardware...hell, it's too slow on a P200 with 200MB of RAM, now that the status and available files have over 3300 packages detailed in them. Yeah, it's slow, and it's written in C. And you want to cinvince me by your un-emotional argumentation that it will be even slower in C++? Strange. Last time I took a look at Stroustrups language it seemed that it would be carefully designed to not enforce too much overhead on language features, and no overhead on language features not used. Stroustrups book goes into detail, and always mentions which run time overhead you have to expect when you use a certain language feature. Most features are only one function call away. in theory, theory and practice are the same. in practise, they're different. i've always favoured practical considerations over nice theories. In practice, C++ programs are larger and slower than they ought to be. craig -- craig sanders
Re: Time to rewrite dpkg IN IDL! :)
On Thu, May 20, 1999 at 10:09:34PM +0200, Marek Habersack wrote: Now you've proven it. You're a fanatic. And you offend people. Thanks. there's no excuse for personal attacks. if you have a point to make, then make it but don't stoop to ad hominem attacks. i think i'll just ignore the rest of the thread now...it probably isn't worth reading if it's got down to this level. craig -- craig sanders
