Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Static typing is mostly a waste of time

by johnnywang (Priest)
on Apr 12, 2005 at 06:21 UTC ( [id://446865]=perlmeditation: print w/replies, xml ) Need Help??

I spent the last few weeks, part time, developing a web application using java (Struts/Hibernate/Spring). For the first time, I consciouly took note of how much time I spent converting types, e.g., the number 100, some wants it to be long, some String, some Long, and then the dreaded "List/Vector of Long" to long[], or Long[]. In perl, one hardly ever needs to do these.

Furtheremore, in java, it's not often that I make a ClassCastException during runtime. One can argue that's because the compiler caught most for me, but even during compilation, the most often occured error of this type for me is forgetting to cast to an concrete object when doing iterator.next() or List.get(), but in that case, the compiler isn't really helping me in any way: I'm already assigning to the right type. Similarly, in perl, without static typing, I don't remember making many "ClassCastException" type of errors. So I'm claiming that at least this asepct of static typing is mostly a waste of time as pratical programming goes.

Replies are listed 'Best First'.
Re: Static typing is mostly a waste of time
by dragonchild (Archbishop) on Apr 12, 2005 at 12:41 UTC
    Perl's type system is both static and very strong. It just contains very few types - scalar, hash, array, filehandle, code. (And format, but no-one uses it anymore.) You cannot convert between them and they're set at compile time.

    Now, the big reply is "But scalars are strings and numbers and Perl implicitly converts between them." Yes, it does. However, look at it this way - there is a type called scalar. There are dozens of operators that work on scalars. Some of them work with the scalar one way and some work with it another way. The fact they treat the scalar differently is both consistent and documented. It doesn't change the fact that it's still a scalar and it was typed as a scalar at compile time and it will never change what it is. Static and strong typing.

    Another reply is "But when you do @foo + $bar, @foo gets converted to a scalar." Well, yes, that's what it looks like. But, + is defined differently for @foo than it is for $bar. It's not conversion - it's polymorphism. :-)

      Neither does @foo get converted to a scalar, nor is + defined differently for @foo than it is for $bar.

      The value of @foo is a number in scalar context, but it's not a conversion - @foo doesn't change. Nor is + internally a huge dispatch table, doing all kinds of different things depending on the types of its arguments. Binary + always gets two scalars as arguments, and isn't doing anything before the scalar values are known.

        I said: + is defined differently for @foo than it is for $bar. It's not conversion - it's polymorphism.

        How that polymorphism is achieved is irrelevant. '+' will do the right thing when handed varying types. The fact that '+' imposes scalar context upon its operands and @foo in scalar context is "$#foo + 1" doesn't change the fact that it's '+' which is the agent of the context conversion.

      Perl's type system is both static and very strong. It just contains very few types - scalar, hash, array, filehandle, code. (And format, but no-one uses it anymore.) You cannot convert between them and they're set at compile time.
      That's an interesting assertion...
      @a=("abc",1,"42","dolphin"); %b=@a; print "$_,$b{$_}\n" for keys %b;
        Assignment is also polymorphic. %b (or @b, for that matter) forces '=' to impose list context upon @a. In other words, '=' changes behavior depending on the LHS. It's not type-casting, which is what I meant to say.
      So is assembly language strongly/statically typed?
      The Assembly language type system is both static and very strong. It just contains only one type - bytes. (And octets, but no-one uses them anymore.)

      Now, the big reply is "But bytes can be strings and numbers and Assembly language implicitly converts between them." Yes, it does. However, look at it this way - there is a type called bytes. There are dozens of operators that work on bytes. Some of them work with the bytes one way and some work with it another way. The fact they treat the bytes differently is both consistent and documented. It doesn't change the fact that it's still a byte and it was typed as a byte at compile time and it will never change what it is. Static and strong typing.

        A type system with just one type is both static and strong. It's just not very useful as a type system.
Re: Static typing is mostly a waste of time
by Anonymous Monk on Apr 12, 2005 at 10:24 UTC
    Don't confuse "typing done badly" (by the language) with "static typing is a waste of time". If you (often) need manual conversion of types, the typing system of the language is done badly. There are languages, often functional languages, Haskell for instance, that are strict and statically typed, but it's the language itself that does most of the mapping of types to variables by deriving what the type would be.
Re: Static typing is mostly a waste of time
by merlyn (Sage) on Apr 12, 2005 at 14:31 UTC
      "I thought I had a problem with static typing once. Then I poured fabric softner on my keyboard. Now I have two problems." <rimshot>
Re: Static typing is mostly a waste of time
by hardburn (Abbot) on Apr 12, 2005 at 13:37 UTC

    In that case, can you tell me what the square root of a string is?

    There are basically two ways of solving that:

    • It is an error to apply a numerical operator on a string (Strong type system)
      • And since it's an error, it should error at compile time if possible (Static type system)
    • A string gets converted to a number in some well-defined way (latent type system)

    If C/Java/etc. were the state-of-the-art in type systems, I would be for latent types all the way. But C wasn't the state-of-the-art when it was designed (Hindley and Milner were already playing with type inferencing systems at the time), and type systems have been developed a lot since then.

    It's OK for C to not reflect the state-of-the-art at the time, since it's a practical language to solve practical problems. Using brand new and unproven concepts in language design is not conductive to solving practical problems. But type inferencing has come a long way, so modern languages no longer have an excuse.

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

      sqrt("four") eq "two"

      Seriously, it's a question of being willing to pay the price of validating the input yourself. In many cases you have to do it anyway; for example, for square roots even if you can trust the compiler that you are getting a number, you have to make sure that it is not negative (unless your sqrt function deals with complex numbers).

        Type systems don't concern themselves with what data you can put into the variable. They concern themselves with what you're allowed to do with that variable. Mathmatically, it makes no sense to take the square root of a string, or call an insert() method on an object that only runs selects, or give a background the color of laptop.

        The holy grail is a program that is proven correct just by the fact that you compiled it without errors. Good, strong type systems are a major step in that direction. I'm not sure we'll ever actually reach that point, but it's good to try.

        "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

        Or unless you have a type "Non-negative number".
        ...for square roots even if you can trust the compiler that you are getting a number, you have to make sure that it is not negative (unless your sqrt function deals with complex numbers).
        Even if your sqrt doesn't do complex numbers, you'll still get an exception for negative answers. Which seems like a better alternative than returning a garbage answer.

        $a = ["abc",123]; $b = -1; print sqrt($a); print sqrt($b);
        Actually, sqrt("four") eq "0". Try it if you don't believe me! :-)
      You're arguing that Perl has a latent type system. I would argue that it has polymorphic built-ins. Are we in violent agreement?

        From what I saw of your arguments in this thread, you focus more on container types (scalar/list), whereas I'm focusing on value types (numbers/strings/etc.). Perl isn't latently typed for its container types--it has some very strong and static rules for what you're allowed to do with a scalar and a list:

        perl -e '$foo = 1; push $foo, 2' Type of arg 1 to push must be array (not scalar dereference) at -e lin +e 1, at EOF Execution of -e aborted due to compilation errors.

        I'm arguing that value types are latent in Perl, and this isn't a good thing considering the advances in type systems over the last 30 years.

        Then again, mathmatics has a whole branch dedicated to finding the square roots of negative numbers, which would be impossible without a similar hack . . .

        "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

      In that case, can you tell me what the square root of a string is?
      Not a string, but this is one of my personal favorites...
      print sqrt([42,"abc"]);

        Interesting. It seems to be taking the square root of MAXINT (2**32 on my platform), with some floating-point storage error in the answer.

        While lacking strong typing might be detrimental in practical programs, it sure is fun to play with sometimes :)

        "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Re: Static typing is mostly a waste of time
by gjb (Vicar) on Apr 12, 2005 at 09:09 UTC

    Strong typing makes writing good development tools easier. Eclipse in combination with FindBugs or PMD gives one sensible feedback on errors related to casting. Providing similar support for a language like Perl would be much harder if not impossible.

    Just my 2 cents, -gjb-

      But the question is, are those kinds of tools needed for Perl? Different languages tend to lead to different kinds of bugs, and different methods and tools to solve them.
        Of course, you'll have to explain to us what the practial difference is between classes and types.
Re: Static typing is mostly a waste of time
by tilly (Archbishop) on Apr 12, 2005 at 20:56 UTC
    I'm surprised that nobody has brought up Dominus' wonderful talk on Strong Typing and Perl. There is a lot more to strong typing than is obvious, and implementations of it do not have to look like they do in Java or C.
Re: Static typing is mostly a waste of time
by JanneVee (Friar) on Apr 12, 2005 at 13:31 UTC
    I wouldn't go so far in claiming that static typing is a waste of time. I'm claiming though that you are pointing out a weakness in the design of the Java Language.
Re: Static typing is mostly a waste of time
by Errto (Vicar) on Apr 13, 2005 at 02:08 UTC
    I agree that Perl's typing system is easier to work with and, in some ways, more intuitive then Java's (with exceptions like the value of a hash in scalar context). But don't just dismiss static typing unless you've tried a language that does it right and you still don't like it. I personally recommend Haskell, because it so plainly illustrates that static typing does not necessarily prevent polymorphism, code reuse, etc. For example, in Haskell there's a builtin function called sum whose signature is:
    sum :: Num a => [a] -> a
    This means that this single function can be passed a list of any type, so long as that type is numeric (specifically meaning that the operator `+' is defined on it), and return a value of that same type. And you (or the compiler) can "prove" that the types are the same through static analysis - no runtime casting or other ugliness required.
Re: Static typing is mostly a waste of time
by Anonymous Monk on Apr 12, 2005 at 15:31 UTC
    Might as well dredge up a previous discussion on typing.
A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://446865]
Approved by friedo
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (6)
As of 2024-03-28 11:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found