Re: Perl's Longevity

As processor speeds continue to creep up and memory becomes even more abundant the need to be efficient in terms of cycles and memory decreases. As a result it will typically be more efficient to use a very high level languague like Perl to get stuff done. This is because IMHO you can get a given task done faster in Perl than say trying to do the same thing in.....ASM, C, C++, Java in roughly that order. So it will be more efficient/cheaper to do it in a VHLL.

If you look at the Microsoft .NET framework you will see that they are abstracting like mad adding Intermediate Languague, Bytecode and JIT compilation layers into their language model - it makes Perl look positively like a thoroughbred race horse. But then I am a firm believer in the intel/M$ consiracy. M$ write more and more bloated software in slower and slower languages to justify people having to by faster and faster intel hardware.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Comment on Re: Perl's Longevity

Replies are listed 'Best First'.
Re: Re: Perl's Longevity by Elian (Parson) on Apr 14, 2003 at 18:09 UTC
As processor speeds continue to creep up and memory becomes even more abundant the need to be efficient in terms of cycles and memory decreases. That's a dangerous thing to think. While it is true, to some extent, you have to be very careful that you don't become less efficient faster than the machines become faster. Otherwise you end up with software whose newer versions run slower than the older versions, even with hardware upgrades. It's also a dangerous thing to think as you quickly end up with software that won't run on older, or even current, machines for no particularly good reason. (Burning time and memory to give you more time to play Warcraft is not a good reason) And, of course, thinking "my time is more valuable than any computer's" is incorrect for a not incosiderable number of programmers...	[reply]
Re: Re: Perl's Longevity by t'mo (Pilgrim) on Apr 14, 2003 at 16:40 UTC
I don't understand your argument. Are you for or against "layering" and abstracting? The way I read Paul G.'s article, he is for layering. (See the paragraph beginning "Another way to burn up cycles is to have many layers of software between the application and the hardware..." and the subsequent four paragraphs.) In my experience, it has proven to be a useful technique. Now, if you are arguing that layering, done badly, is a problem, then I agree (also through experience) whole-heartedly. ...every application I have ever worked on is a glorified munger...	[reply]