Re: Downside of Perl (relative) popularity

You are probably right that sometimes it is better to restart a project from scratch than to try to re-use pieces of code that really don't belong together.

I have to object though to the way you seem to consider C superior to Perl. C is right for low-level stuff, basically when you want efficient code, both fast and using little memory. When you are writing perl, the interpreter for example. For most other tasks the price is too high. You loose a _LOT_ in development time and potential bugs or security problems. I have worked in very few projects where the cost of using C would have been justified. And I have been involved in a lot of projects, both in C (in my pre-Perl days) and in Perl.

So yes, start from scratch, but why not start from scratch in Perl?

Comment on Re: Downside of Perl (relative) popularity

Replies are listed 'Best First'.
Re: Re: Downside of Perl (relative) popularity by stefp (Vicar) on Mar 29, 2001 at 20:28 UTC
So yes, start from scratch, but why not start from scratch in Perl? I put it to harshly when I said starting from scratch. . In fact I am dabbling with linux networking stuff: ipvsadm, keepalived.and ip commands and some added configuration layers. Eventually I end up with the same data in different configuration files. keepalived polls services defined by ipvsadm so its configuration file repeats material needed for ipvsadm. Compatibility with installed stuff is a criteria as well. So It is difficult to decide which configuration file is authoritative for what. Anyway I need to deal with inconsistencies between them. I intend to provide a Perl API to some C code extracted from these commands. But I am not sure I will be given the time to do it. What I want is to avoid to massage many configuration files but to have one that drives everything. In other words, one should not always work by adding layers on top of layers in Perl () but must deal with C to reorganize and/or to provide an clean Perl API. () later edition In Perl or any scripting language. My point was that because some managers know you can pee code in whatever language, they may prefer quick fixes over quick fixes and one ends up in a mess. -- stefp	[reply]

Replies are listed 'Best First'.

Re: Re: Downside of Perl (relative) popularity
by stefp (Vicar) on Mar 29, 2001 at 20:28 UTC

So yes, start from scratch, but why not start from scratch in Perl?

I put it to harshly when I said starting from scratch. . In fact I am dabbling with linux networking stuff: ipvsadm, keepalived.and ip commands and some added configuration layers. Eventually I end up with the same data in different configuration files. keepalived polls services defined by ipvsadm so its configuration file repeats material needed for ipvsadm. Compatibility with installed stuff is a criteria as well.

So It is difficult to decide which configuration file is authoritative for what. Anyway I need to deal with inconsistencies between them. I intend to provide a Perl API to some C code extracted from these commands. But I am not sure I will be given the time to do it. What I want is to avoid to massage many configuration files but to have one that drives everything.

In other words, one should not always work by adding layers on top of layers in Perl (*) but must deal with C to reorganize and/or to provide an clean Perl API.

(*) later edition In Perl or any scripting language. My point was that because some managers know you can pee code in whatever language, they may prefer quick fixes over quick fixes and one ends up in a mess.

-- stefp

[reply]