I do too but I'm finding that a lot of the time there are so many untyped inputs to a system that the static typing doesn't buy you that much. There always seems to be a ton of xml configuration data, incoming JSON from web services, databases with different type schemes etc.

As soon as you receive an untyped input, make it conform to a typed data structure, and throw some kind of error if you can't. That way you catch any issues in your input data long before it bubbles through your app and causes a problem which is super-hard to track down.

See e.g. DictShield for Python (https://github.com/j2labs/dictshield), Jackson for JVM (http://jackson.codehaus.org/), Swiz for node.js (https://github.com/racker/node-swiz)...

I don't know about other environments, but on iOS I just create a class that I store the e.g. JSON data in.

I'm also starting to find that a language with static typing and generally an enforced structure is easier to deal with.

With dynamic languages, you have to hold a lot in your head. Having an enforced structure offloads some things off your brain so you have more mental space to think clearly and not panic or get burned.

Static typing also makes overloading your f.unctions on return type instead of just arguments types possible. Not a lot of languages do this, though. I only know of one, but it's invaluable there.

Perl's a dynamic language, but return type can vary based on context. I once saw this really bite someone where the presence of parentheses on the left-hand side of the expression changed the behavior of the function being called on the right-hand side. Not fun to debug that one.

Exactly. Duck typing sucks. I don't know why it was invented...

It only "sucks"(causes problems rarely, and can be quite useful regardless) in dynamic languages. Languages like Go, Rust, and Haskell provide the same flexibility with static guarantees. All you must do is define type specific implementations to satisfy the interface(or typeclass). For example in Haskell, I can so something like:

    class Stream s where
      read :: s -> (a, s)
      write :: a -> s -> s

and extend it to any type:

    instance Stream [Int] where
      read s = ...
      write a s = ...

    instance Stream File where
      ...

and so on, and I can now pass any type that is a member of Stream, to a function that expects one.

The haskell code is — as far as I can see anyway — nominative typing. It can be post-implemented, but you still need your type to be explicitly made into a Stream instance.

Contrast OCaml, an object type is represented as a set of (method, types) tuples and type-checking is a subset check (if type A has all the methods of type B, then it's a subtype of B regardless of anything else from visibility to semantics):

    # let x =
          object
              method foo = 42
          end;;
    val x : < foo : int > = <obj>
    # let y =
          object
              method foo = 63
              method bar = 12
          end;;
    val y : < bar : int; foo : int > = <obj>
    # x = y;;
    Error: This expression has type < bar : int; foo : int >
           but an expression was expected of type < foo : int >
           The second object type has no method bar
    # type simple = < foo : int >;;
    type simple = < foo : int >
    # (y :> simple) = x;;
    - : bool = false
    #

You're comparing ad-hoc polymorphism with subtype polymorphism. Doing so will lead you to the expression problem:

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

Anyway, there's been quite a few proposals to add extensible records to Haskell, which would allow row polymorphism, similar to what you just showed in OCaml:

http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords

Too bad that it has gone nowhere in a long time.

> You're comparing ad-hoc polymorphism with subtype polymorphism.

No, I'm comparing structural typing, which is what Go implements, to nominative typing.

But that may very well be due to me having stayed in context of an other sub-thread where this was the subject, and using that as a filter for the current one.

I really wish more languages had the option of using a Haskell style type system.

Or even just plain Hindley-Milner.

The above is not an example of duck typing.

Even if it was, one example of a difficult bug in one system does not invalidate a whole concept.

And duck typing is almost as old as programming itself...

Yes. I can't agree more. One example to backup: Eclipse makes Java fun.

Is this sarcasm? =)

If you want to know how real auto-complete works, try out IntelliJ. Auto-complete on Eclipse is like slowly being pecked to death by ducks.

A more accurate statement in my mind is "Eclipse makes Java palpable, IntelliJ makes Java fun."

I am downloading IntelliJ. I've use Eclipse for years, It works for me.

I will give Eclipse a try.

IntelliJ is the best IDE out there. It might be pricy, but it will save you so much time in the long run. Since time is money, you will end up saving money too. :)

The Community Edition is free of cost. The choice depends on what you need: http://www.jetbrains.com/idea/features/editions_comparison_m...

yeah free version supports Java SE, with a really nice Scala plugin for download via the plugin manager.

I think the counter-argument here would be that dynamically-typed languages let the person behind the keyboard run the show, as opposed to the IDE.

Alas, nobody has written a really good IDE for Haskell, yet. So we still have to run the show for that statically typed language manually.

If I ever develop a program language, the first action I will take is the clang approach and make it a library based architecture. That way, people can build tools for the language including IDE integration without having to reinvent the wheel.

Yes, this has been invaluable for us in Rust. One cool thing we've been able to do with this architecture is to write a fuzzer -- a tool that uses the Rust compiler itself to generate random Rust programs to test the compiler's correctness.

I think GHC does something like that. At the very least, it exposes an API that lets you do all sorts of fun things. There are projects like Scion[1] that let you integrate that into an editor.

[1]: https://github.com/nominolo/scion/

However, there is simply less drive to develop tooling like that for Haskell than there is for Java. Haskell is a much easier language to use given just a moderately intelligent text editor and a REPL than most others. Java, on the other hand, it verbose and annoying even with a very good IDE.

So Haskell can have good support, but since it isn't terribly necessary it isn't anything like a top priority.

Indeed, “the architecture of GHC” mentions some uses of GHC as a library: http://www.aosabook.org/en/ghc.html

Compiler As A Service. Microsoft are pushing this with Roslyn.

http://www.infoworld.com/d/application-development/microsoft...

What do you think of leksah?

I know of it, but haven't used it, yet. That's why my comment was a bit more guarded than it would have otherwise been. (Though re-reading that line, it doesn't come across as such to me now.)

IDEs are just another potentially-useful (some of them are better done than others) form of abstraction to let you focus on the important parts.

You run the show by architecting your software. Not by counting the number of key strokes you typed.

IntelliJ's Python module (Pycharm) does a as decent job as you might expect based on code and your type annotations (i.e. if your docstring says that foobar is a BlahManager, it will complete foobar methods based on that and warn you if you are calling something foobar doesn't have).

Which IDE do you use with Go?

I use Sublime Text 2 with GoSublime.

http://www.sublimetext.com/ https://github.com/DisposaBoy/GoSublime

Vim with gocode https://github.com/nsf/gocode