That's one way, or you could write clear unambiguous code such that the types are reasonably self evident.

(Remember, don't mash up "Java and C++" with "static typing". Java and C++ are not worth mentioning when discussing type systems; they have type systems that get in the way and make it harder to code.)

Do you know of any good resource to read up about a better type system and its benefits, but without having to learn a whole new language? (I don't have time to learn a new language, but this sounds important enough to read up on).

http://en.wikipedia.org/wiki/Type_inference

What I mean is, when I write a function to do something with files, I don't want to have to decide whether I'm going to accept a "FILE" class or not. This isn't laziness: it's realizing that I will one day want to use a different class which looks like a file, but isn't part of the "file" hierarchy.

This situation comes up far more often than one might think, and it saves a lot of headaches up-front (designing complicated hierarchies to prevent future use-cases you'll want).

From what I've read, Type inference doesn't help with that. (But I haven't read much, so I could be wrong).

Experience may help you change your mind. Reading papers and advocacy from people who've used it should provide limited influence.

As an aside, there are solutions to programming problems I would've never come up with if it weren't for experience in other programming languages, so I read "don't have time to learn a new programming language" as "don't have time because I haven't learned a new programming language."

Social networking web sites? Yes. Video games? Definitely.

Business applications (or anything dealing w/money)? You sure had better fail and roll back any transactions.

But I think your point stands when you consider that the cases where it's ok to keep going after something wrong happens are the exception, and not the rule (most software is automating boring business practices).

  * Something returned null when I assumed it would return a value/object.
  * I used the wrong variable.
  * I made a typo in an assignment that implicitly created an unused variable
    (this is easy to catch with static analysis even in dynamically typed
    languages, admittedly).

I'm not particularly experienced with Haskell, but my understanding is that the static typing will usually catch the second one and that more advanced static analysis (more advanced than type checking) can easily catch the third one.

Most important, though, is the case of the first and most common error. Here, the language will very explicitly require you to handle the case that "Nothing" will potentially be returned.

So, most of the sorts of errors that would have caused failed execution in a dynamically typed language will be caught at compile time. This means that when the program runs, it will usually be closer to being correct than it would be if it were written in a dynamically typed language and failed in the middle of execution.

Using the wrong variable, I just never seem to have that problem as well named variables make the code just look wrong when it happens and secondly because I'm writing the code while the code is running in a live environment. I see immediately when it does work because the first thing I do is execute it on a live object to make sure it does what it's supposed to do. This handles the null issue as well. Incremental live development just side steps about all of these issues, and is something static languages just don't let me do.

More often than not, I've found type systems to prevent me from expressing what I want to express even when the code would work perfectly fine simply because polymorphism isn't granular enough. In dynamic type systems, polymorphism is based on method signature alone and is not bound to any kind of class/interface/type class which gives me the most flexibility in expressing myself. I prefer that flexibility and incremental live development over any gain any static type system might give me.

Well, actually no. Consider:

    divide :: Int -> Int -> Maybe Int
    divide x 0 = Nothing
    divide x y = Just $ x / y

    printResult :: Maybe Int -> IO ()
    printResult (Just x) = print x

    main = do
      putStr "Type a number: "
      x <- readLn
      divide 42 x >>= printResult

Anyway, my usual error is not null or using the wrong variable or typoing something. It's usually failing type checks because I forgot a coercion, or just plain wrong code. Exceptions prevent null returns, and I am lucky with respect to the other two.

    import System.IO

    divide :: Int -> Int -> Maybe Int
    divide x 0 = Nothing
    divide x y = Just $ x `div` y

    printResult :: Maybe Int -> IO ()
    printResult (Just x) = print x

    main = do
        putStr "Type a number: "
        hFlush stdout
        x <- readLn
        printResult $ divide 42 x

    : kragen@inexorable:~/mail ; ocaml
            Objective Caml version 3.10.2

    # let divide x = function 0 -> None | y -> Some (x / y) ;;
    val divide : int -> int -> int option = <fun>
    # let printResult = function Some x -> print_int x ;;  
    Warning P: this pattern-matching is not exhaustive.
    Here is an example of a value that is not matched:
    None
    val printResult : int option -> unit = <fun>
    # printResult (divide 9 3) ;;
    3- : unit = ()
    # printResult (divide 10 0) ;;
    Exception: Match_failure ("", 1, 18).
    #

If there was a "jrockway award for explaining type systems", this statement would qualify you for one. I am glad I'm not the only person that thinks this :)

Remember, most of your time is spent with a broken program rather than with a working program. Once it works, you don't think about it anymore. Getting to that working state is what programming is.

Dynamic typing is an answer to the problem that getting types right in a program is as difficult as getting anything else right in a program, especially given the limitations of type systems. I can write a trivial Haskell program which will not halt (due to trivial mathematical properties of negative numbers) but which the type checker will allow by allowing the compiler to infer the wrong type.