http://qs321.pair.com?node_id=160308


in reply to Griping about Typing

Says ovid:
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 typing
Paul 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.

--
Mark Dominus
Perl Paraphernalia

Replies are listed 'Best First'.
Re: Re: Griping about Typing
by Ovid (Cardinal) on Apr 18, 2002 at 20:34 UTC

    I have never missed Perl's lack of strong typing.

    Yuck. I totally blew it on that one by not putting in the proper context. It's about as intelligent as saying "I've never missed not having a third eye." (how many negatives can I pack into one sentence?) I suppose I should have prefaced that statement by pointing out that I have worked with languages with stronger typing mechanisms, so I might be able to make a justification for stating that I am not totally unfamiliar with them, but the typing mechanisms for those other languages fall prey to the same arguments you put forward in your article about typing. Thus, I'm hard-pressed to sound intelligent about saying that I don't miss the broken and cumbersome type mechanisms of those other languages.

    ...if you can put a micro-optimization into Perl itself that will make every program one percent faster, you should do it.

    And following my comments regarding whether or not I care about a loop control variable being typed:

    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.

    Thank you! That was exactly the sort of rebuttal that I was looking for. I hadn't given much thought (well, duh) to the speed of an individual program vis-a-vis the speed of Perl itself.

    I am curious, though, about the potential merits of my drawing an analogy between Perl's type system and the benefits of object oriented programming. The obvious trade off is performance. An optional strong typing mechanism to take advantage of performance, when needed, could coexist nicely with the OO-like behavior of the classic Perl variables. In fact, one OO behavior that I didn't mention, but that chromatic once pointed out to me, was tie. With tie, I can subclass the variable objects which seems to improve the analogy.

    The only reason that I came up with this is because I got rather tired of the "Perl's not typed" arguments. Frankly, I prefer to avoid language wars because they aren't terribly productive, but I was looking for a good way of explaining that Perl is not only typed -- around data structures instead of data types (is that equivocating?) -- but that its type mechanism has benefits that even OO afficionados could love.

    Side note: now that I stop to think about it, I think one might reasonably make the argument that C is not typed. If you take away the compiler warnings, the only thing (I think) that C really does is ensure that the amount of memory that a programmer asks for is allocated. After that, it will cheerfully try to stuff your float into the int. So, barring the warnings in the compiler, there's nothing built in to C to really support typing. Hmm... stuff for me to think about.

    Time passes... now that I've thought about it, the ability to cast data types within the program shows (amongst other examples) there is some typing being done. /me was stupid.

    Cheers,
    Ovid

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

[reply]
Re: Re: Griping about Typing
by Anonymous Monk on Apr 19, 2002 at 07:26 UTC
    I don't think it's a matter of ignorance rather a matter of flexibility. If they could co-exist, I would have no problem with it. As far as 'blub', I know Paul a bit and in my experience he is a really brilliant guy but he is certainly TOOWTDIAIM (There Only One Way To Do It And It's Mine.) so I'll take that comment with a little bit of salt :)

    If type casting could be done without losing anything, great. I'm sure I would make good use for it as I have everything in Perl I've seen so far but if it were not an option, I'd find something else to program in.
[reply]

In Section Meditations