Re: TIEOWTTI

The difference between the "one way" and "multiple ways" is often a matter of the power behind the language. From what I have seen, languages that boast "one way" tend to be easier to learn and are often a better environment for programmers of low to medium skill. However, advanced programmers often get frustrated when encountering an implementation obstacle generated by the "one way" paradigm.

With Perl, "multiple ways" tend to offer much more power and flexibility, but at the cost of added danger. From what I have seen, programmers need to have a higher skill level to tackle tough projects in Perl, but the reward is fewer obstacles.

For example, I've never seen an AUTOLOAD type of functionality in Java. I can't do multiple inheritance if I think I need to. I can't do closures with Python. Most of the time, we shouldn't be allowed to even dream of doing some of those things, but if we need to, it's nice to know that we can.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Comment on Re: TIEOWTTI

Replies are listed 'Best First'.
Re: Re: TIEOWTTI by cascade_fx (Sexton) on Apr 16, 2002 at 13:47 UTC
The difference between the "one way" and "multiple ways" is often a matter of the power behind the language. From what I have seen, languages that boast "one way" tend to be easier to learn and are often a better environment for programmers of low to medium skill. However, advanced programmers often get frustrated when encountering an implementation obstacle generated by the "one way" paradigm. While I fully adhere to the There Is More Than One Way To Do It philosophy of Perl, I do have some experience which marks a more concrete benefit of the There Is Exactly One Way To Do It. While a more structured language may be easier to learn, more importantly (I think) it offers benefits in automatic/compile-time optimization. While in college, I took a high performance computing class where we learned all manner of ways to exploit architectural differences in various platforms as well as ways to exploit code structures to gain an increasing number of performance enhancements from particular pieces of code. We did most of our work in C and would use all the compile time options for optimizing compililation that the compiler offered. Generally we got pretty good results. However, when the problem was rewritten in Fortran using the same techniques and compile time options, it was much much faster. The reason being that Fortran's data typing and control structures require that they are strictly adhered to. Because of there being exactly one way to do it, the compiler can make optomizing assumptions that it just can't do in C (having to cover all of its potential bases). I love Perl and I think its benefits outwiegh any problems. In fact, I am happy with its performance, finding it to be a lot faster than I expected. It just seems that TIMTOWTDI may hamper its ultimate performance. On the other hand, writing a C program that can do the same complex manipulations that the average Perl program does can be very time consuming. Seen in that light, Perl gains its optimization benefits on the front end of a project. Then again, I could be wrong -- cascadefx	[reply]

Replies are listed 'Best First'.

Re: Re: TIEOWTTI
by cascade_fx (Sexton) on Apr 16, 2002 at 13:47 UTC

The difference between the "one way" and "multiple ways" is often a matter of the power behind the language. From what I have seen, languages that boast "one way" tend to be easier to learn and are often a better environment for programmers of low to medium skill. However, advanced programmers often get frustrated when encountering an implementation obstacle generated by the "one way" paradigm.

While I fully adhere to the There Is More Than One Way To Do It philosophy of Perl, I do have some experience which marks a more concrete benefit of the There Is Exactly One Way To Do It. While a more structured language may be easier to learn, more importantly (I think) it offers benefits in automatic/compile-time optimization.

While in college, I took a high performance computing class where we learned all manner of ways to exploit architectural differences in various platforms as well as ways to exploit code structures to gain an increasing number of performance enhancements from particular pieces of code. We did most of our work in C and would use all the compile time options for optimizing compililation that the compiler offered. Generally we got pretty good results. However, when the problem was rewritten in Fortran using the same techniques and compile time options, it was much much faster. The reason being that Fortran's data typing and control structures require that they are strictly adhered to. Because of there being exactly one way to do it, the compiler can make optomizing assumptions that it just can't do in C (having to cover all of its potential bases).

I love Perl and I think its benefits outwiegh any problems. In fact, I am happy with its performance, finding it to be a lot faster than I expected. It just seems that TIMTOWTDI may hamper its ultimate performance.

On the other hand, writing a C program that can do the same complex manipulations that the average Perl program does can be very time consuming. Seen in that light, Perl gains its optimization benefits on the front end of a project.

Then again, I could be wrong -- cascadefx

[reply]