With programs, we're only interested in the "design" part of the process. What takes us less time to design a new program, is time won. We're not interested in the building of the car (compiling the program), whereas in the car business, this is one of the most important components.
Reducing design time isn't necessarely always "good". Designing a program by doing lots of "we just cut-and-paste this and that, and fiddle a bit with the innards", gives you quick design times, but not necessarely good programs. Not considering security issues or resource usage reduces design times, but isn't good either. Neither is looking at the literature. Reducing design times can be a good thing, but not at all costs. Just like code reduce can be good, but not at all costs either.
In most cases, we're only interested in whether the car will bring us from A to B (run as expected). We're generally not (as much) interested in how fast it does it, let alone how the car looks. For all we want, it could be a crate with four wheels, if it runs, it runs.We are not interested in how fast our code is? I think that performance times of programs are very important, not only for the programmer, also for the (end)user. Just look at all the threads here and other programmer forums that discuss how fast a piece of code is (or isn't).
So I think re-use needs to be thought of with every component you build in mind.
I don't. I find that if I do that, code tends to be overly complex, having too many hooks and parameters than necessary. I prefer code to be simple - if the need arises I can always change it for code to be reusable (which if the code is simple and modular, not to hard). For code that is be reused later on, this might be less efficient then if it was made with reuse in mind. But in my experience, that's largely compensated by not spending time making code that turns out not be reused, reusable.
I agree with you with regards to testing: you need a test-suite to be able to proof that new features work as expected. More importantly, you need to be able to verify that old features still work as before.This sounds simple, but this is very, very hard. Just look at perl itself. Even with a gazillion tests run, Perl manages to unintentionally break old code for each new release.
Just look at 5.8.1. It introduced randomized hash seeds. It reused the code that generates random numbers. Oops! Now the random number generator is seeded before the program starts running, causing forking programs to generate the same random numbers in both the parent and the child.
Finally, in software it is a lot easier to get different components to fit. Whether this looks nice or not, is basically immaterial. You just need the right glue. And Perl is just that!Yeah, right. Post some code here that does "$test = `cat file`" or "system 'cp file1 file2'" and watch the people howl that it's not a "solution in Perl". For many people, appearance is important, and they don't want to see glue if it can be avoided.
Abigail
In reply to Re: Re-use: moderation please.
by Abigail-II
in thread Re-use: moderation please.
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |