|Perl: the Markov chain saw|
Re: Re: Griping about Typingby Ovid (Cardinal)
|on Apr 18, 2002 at 20:34 UTC||Need Help??|
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.
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.