> Raph went through the code later on, and found the obvious cut'n'pastes. > So he says, libjpeg is not something you'd ever rewrite. In this particular case, obviously he was wrong. (And he was certain to be wrong with libjpeg :) However, I don't think there is a hard and fast rule wrt code reuse. It seems to me that libraries / code get features added, which may not be the features you need. To put this another way, often two features are taken away : small size and fast speed. (This is not true of libjpeg). It's a trade off between feature sets and these two desirable assets. Sometimes code requires that you 'enter my world'. As in, this nice capability requires that the following parts are also made available. Ever downloaded a nice sounding Perl module to find it requires three other modules? Or a library or application that requires you install X, Y and Z? Of itself, this may not be a bad thing. Sometimes these extra things are needed, and they are provided in a convenient and compatible way. Sometimes they are somewhat thoughtlessly thrown in : accept my world. I find Java a bit that way. Yet, once you accept the basic premise, it becomes the `true way' :) (Please don't flame me for my Java prejudices. I'm biased against all programming languages, except the one true one, of course). Give you a practical example. Jeff mentioned a Linux VCR. Now suppose you wanted to build one, for a display target you have a choice of: raw frame buffer, X and other. Amongst other, I would include SDL, which is a sort of thin layer game API (quoting SDL is a library that allows you portable low level access to a video framebuffer, audio output, mouse, and keyboard. With SDL, it is easy to write portable games) Now, all of these are right, depending on circumstances. If you wanted to just add VCR capability to a normal workstation, probably X or SDL. If you wanted a stand-alone device that could be built as cheaply as possible, then framebuffer or SDL. > It takes less time to search for something that does what you require > than it does to develop it from scratch. Of course, I say this whilst > having an annoying time finding something appropriate for the SLUG > site. "From scratch" has crossed my mind a number of times. >From scratch is often a very correct answer. Even when you have something working, you often intuitively suspect there's a better way. Perl 6, we are told, will be re-written from scratch. To me, this does not indicate a weakness in Perl. This indicates a great strength and confidence. It means that the people building Perl have great faith in their abilities, in the way they work together, and an unstoppable optimism. They believe in their process, which is really what software is about. Software is soft-ware, it is deliberately changeable. We do things in software rather than hardware because we like to tinker, to change, to find a better way. Hardware is fixed, immutable. Of course, not all software is changeable. Some software, issued by centralised despotic organisations, has all the hallmarks of an unyielding, grey totalitarian frame of mind. Free thinking, fun seeking individuals reject this prescription. Those of us who revel in our freedom have adopted a modern, post serf existence. We accept the rights, responsibilities and freedoms offered to the free software emancipist. We participate in the process, we respect the creators of software, we help our fellow citizens in this new cyber land of freedom. We jealously strive to protect our freedom, knowing how hard won it was, how fragile it can be. And so we tinker, we throw away, we re-use. Sure we squabble, we disagree, we come back shame faced 'perhaps you were right, my hubris'. So from scratch, re-use, all part of the endless process. The process almost redefines us, the collaboration seemingly creating a new organism. Now good night, and dream of a new tomorrow. Jamie -- SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/ More Info: http://slug.org.au/lists/listinfo/slug
