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.

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.

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!

Abigail

Reducing design times can be a good thing, but not at all costs.

I agree. But the "not at all costs" goes for a lot of things ;-) So it was implied, at least in my mind.

We are not interested in how fast our code is?

Who is the "we" here? Perl Mon(k|ger)s? That's not really your average Perl programmer, is it? In my experience, people only start to worry about efficiency when they have to wait for it when they feel they shouldn't have to wait for it.

..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)...

To me, that means you already have taken re-usability into account. Because you make your code modular. Many, many (bad) Perl programmers do not even do that. The simple fact that you use named parameters to subroutines, might be considered catering for re-usability in my book.

This (needing a test-suite, ed) sounds simple, but this is very, very hard.

Yes, but is that a reason not to build test-suites? Without the extensive test-suite that Perl has nowadays, many, many other bugs were caught before 5.8.1 was released. That the fork/srand bug wasn't spotted, was simply because no one had bothered to write a test for it in earlier versions of Perl. Even though specific code was made in earlier versions of Perl to ensure children would get different random sequences. Fortunately, tests are added to test new aspects of Perl whenever they are added to Perl nowadays (generally speaking), but one needs to remain vigilant in that aspect ;-).

... watch the people howl that it's not a "solution in Perl"

I generally don't watch those people. ;-) And whether people howl in the Monastery over a piece of code, is not an indication by itself of good or bad code. "Think for yourself!" ;-)

Liz

We are not interested in how fast our code is?

Who is the "we" here?

You tell me. It's the same we as in your

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.

Perl Mon(k|ger)s? That's not really your average Perl programmer, is it? In my experience, people only start to worry about efficiency when they have to wait for it when they feel they shouldn't have to wait for it.

I have noticed that many Perl people are obsessed about speed. Whether it's people newbies asking "What is the best way to do X", where if you ask them what "best way" means is "the fastest" way, to seasoned visitors of this site who scold you for using map because for is 3% faster on their particular machine. Why do you think Benchmark is a popular module?

Most of us programmers are obsessed with speed. Would you buy a 1 GHz CPU if you can get a 2 GHz CPU for just a few Euros more? If so, then you're an exception.

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)

To me, that means you already have taken re-usability into account. Because you make your code modular.

Actually, the main reason for making my code modular is for the opposite reason: it makes it easier to throw away code and replace it with something new.

This (needing a test-suite, ed) sounds simple, but this is very, very hard.

Yes, but is that a reason not to build test-suites?

No, I never said anything like that. I just pointed out that even with a mega test suit, you still can't prove that reusing components won't break anything. Or more general: a test suite can prove the existence of a bug, but it can't prove the non-existence of a bug.

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".

And whether people howl in the Monastery over a piece of code, is not an indication by itself of good or bad code.

While that is true, good or bad code wasn't the point you brought up. What you brought up was:

Whether this looks nice or not, is basically immaterial.

I just pointed out that for many people it is important how code looks.

Abigail