Hacker News Reader

Comment by thesz | Hacker News Reader

I should note that author added some unneccessary cons to static types.

He said that metaprogramming is hard. The area of metaprogramming is partially covered by higher-order functions. The coverage is big, in my opinion, I haven't missed metaprogramming in Haskell for ten years, at least (I missed it for first two weeks with Haskell).

He also said that there's no mechanism to compensate for the absence of duck typing. In Haskell, at least, there are type classes which allow you to make your types as duck as you would wish, maybe slightly less. I think that some Scala mechanisms provide that power.

View on HN

> He also said that there's no mechanism to compensate for the absence of duck typing.

Whereas, in reality, there's a whole class of static type systems which do the same thing, except statically: structural type systems (example: OCaml's object types).

Much as duck typing, they only make sense for object-oriented languages. Structural type systems treat (concrete) objects and object types as method sets (where a method is a triple of name, argument types and return types), where, given the types A and B with A a structural subtype of B, A's methodset will be a superset B's methodset.

> I think that some Scala mechanisms provide that power.

Scala provides structural types (via type refinements) since 2.6.0: http://programming-scala.labs.oreilly.com/ch12.html#Structur... http://scala.sygneca.com/patterns/duck-typing-done-right

"He also said that there's no mechanism to compensate for the absence of duck typing. In Haskell, at least, there are type classes which allow you to make your types as duck as you would wish, maybe slightly less."

I think that type classes are the way to go.

Duck typing is mostly popular because multiple inheritance sucks, and because inherting a class to only overload a method sucks.

Languages like Ruby, Python or Perl are so popular because they are less verbose than Java or C++, with the disadvantage, that the compiler can't help you that much.

Haskell is a language that combines the advantages, less verbosity with a helping compiler, and a static type system that rocks.

While this is a statement in some ways of preference it is a reasonable comment; not sure why it's getting downvoted.

However, can you clarify why you would argue for type classes over duck/structural typing? You indicate that 'type classes are the way to go' but don't explain why.

Scala of course does have a form of Type Classes and while they tend to be what I reach for more often than Structural Types in Scala, it doesn't obviate Structural Types completely and I'd be interested in analysis of the diffs.

With dynamic duck typing you just have to hope the object actually quacks. With type classes, the compiler proves it quacks.

"However, can you clarify why you would argue for type classes over duck/structural typing? You indicate that 'type classes are the way to go' but don't explain why."

Like kscaldef said, you know at compiletime if something can quack, and the overhead for doing this is quite small.

Haskell: instance Quacker MySpecialDuck where quack = "qqquuuuuuaaaaaakkkkk"

"Scala of course does have a form of Type Classes and while they tend to be what I reach for more often than Structural Types in Scala, it doesn't obviate Structural Types completely and I'd be interested in analysis of the diffs."

In which cases do you need duck typing? Adding dynamically a method to a class?

The only thing missing for some metaprogramming issues in haskell, in my limited understanding, is the ability to have dynamically created names (function/methods or types).

But that may be orthogonal to static/dynamic typing (e.g. scala 2.9 has this ability, and javascript doesn't)

Reply on news.ycombinator.com