|The stupid question is the question not asked|
|( #3333=superdoc: print w/replies, xml )||Need Help??|
I'm wondering if any monks can share problems they have had because of Perl's type system. A counter-point would be nice to hear.A lot of folks, you among them, advise everyone to "always use strict". use strict includes use strict 'refs'. use strict 'refs' is there to detect, at run time, that the programmer has accidentally used a string in a place that expected a reference. That is nothing more than a type error. Therefore you, yourself, have provided the counterpoint.
Frankly, the more I think abou this, the primary benefit of strong typing is generating compiler optimizations -- and if you needed lightning fast speed you wouldn't be using Perl anyway...I think you are confusing speed of programs written in Perl with the speed of Perl itself. People who write programs in Perl are often advised to forget about micro-optimizing, because the gains won't be large compared to the run time of the program. But that has northing to do with whether Perl itself shouldn't try to execute all programs as quickly as possible. I had this same discussion with a guy who wanted to know why the speed of Perl's internal hashing function was of any concern. The answer is that although it probably doesn't matter if any particular program is one percent faster or slower, every Perl program uses hashes, and if you can put a micro-optimization into Perl itself that will make every program one percent faster, you should do it.
It's not even clear that speedup benefits of better type analysis would be so small as one percent. To add two machine integers takes only a few clock cycles. To add two PVIVs requires some tests, a function call or two, a switch, perhaps some memory allocation... I don't know how long it takes, but it might easily be a thousand times as long. There could be a substantial speed benefit if Perl could figure out that you weren't ever going to be storing anything but an integer in that scalar variable.
we can develop so much faster that we find and fix our stupid programmer mistakes before others even write the stupid programmer mistake.That begs the question. You started by asking what the benefits of type checking are, but here you've implicitly assumed that they won't be very great.
Earlier, you said:
In the above, admittedly trivial, example, if the purpose of the loop is to ensure that a particular activity occurred exactly 10 times, you probably wouldn't care what type $i is.But you might care, if this were the innermost loop of your program, and if Perl could have gotten a 20% speed increase for the entire program by using a machine integer for the loop variable, which would have reduce the loop scaffold code to three machine instructions.
It's easy to say "If you want C, you know where to find it", but the point here is that flexibly-typed data can coexist with strictly-typed data so that you don't have to sacrifice anything; you get the flexibility by default but still retain the option to get terrific speed in the parts of the program that need it. Common Lisp does this.
I have never missed Perl's lack of strong typingPaul Graham calls that the 'blub problem'. Sure you don't miss it. TRS-80 BASIC programmers don't miss recursion; that doesn't mean it wouldn't be a benefit to them. C programmers will harangue you at length about how they don't miss automatic memory management; that doesn't mean it wouldn't be a benefit to them. It usually just means they're ignorant.
In reply to Re: Griping about Typing