Hacker News Reader

Comment by lmm | Hacker News Reader

You can use a function with different types in a way the original programmer didn't think about. Obviously this has good and bad aspects.

My "whoa" moment with python typing came when I implemented euclid's algorithm (for the gcd of two numbers). Shortly later, I wrote a polynomial class, and then I was able to use my original function on polynomials without changing a single character

In some statically typed languages that would be possible if I'd thought to write my original function generically. But at the time I hadn't even thought about calling it with anything other than integers.

View on HN

Playing statically-typed advocate for a moment: in Haskell, you wouldn't have had to put a type down for the function, and the compiler would have inferred the type

    gcd :: Num a => a -> a -> a

which means it is a function that takes 2 a's and returns an a, with the restriction that a is of typeclass[1] Num, that is numbers. So, very much possible and assumed without thinking about it too much.

[1] A typeclass is a like an interface.

Small correction; with the most common implementation of Euclid's algorithm the compiler would infer

    gcd :: Integral a => a -> a -> a

since writing Euclid's algorithm requires using `mod` or `rem`, both of which only work for integral types (NB. there are many integral types beside ints, for example polynomials, formal power series and gaussian integers).

The Integral class captures the mathematical idea of a Euclidean domain, which can loosely be thought of as "number systems for which the Euclidean algorithm works".

Well, pray that the library function is general enough. Unfortunately, this is not the case for your gcd type, as gcd can be generalized to arbitrary commutative rings.

Nevertheless, writing generic code is of course possible with static types.

Well... kind of. You can define a gcd operation on arbitrary commutative rings, but two elements of the ring don't necessarily have a unique gcd. If you want a unique gcd for any pair of elements, you need to specialize your commutative ring to a unique factorization domain.

If in addition you want to write your gcd function using the Euclidean algorithm, you need to specialize again to Euclidean domains (of which polynomials and power series are an example).

The `gcd` function in the Haskell base library operators on Integral types, which are the programmatic representation of Euclidean domains, so I would argue that it is "general enough".

That's pretty trivial to do in C++, which everybody knows is the least useful static language out there. You discovered operator overloading, not dynamic typing.

You also need templates to make it possible to invoke a function on parameters of unrelated types.

Or interfaces.

If the goal is to be able to invoke a method on an object without checking for anything other than whether a method with the correct signature exists, that isn't a feature that's supplied by dynamic typing. It's supplied by duck typing, which is yet another axis (alongside dynamic/static and strong/loose). A popular example of a statically typed language that has had duck typing for a very long time is Objective-C.

There are some nice examples of re-using the same code at successively more interesting types in Conor McBride's ICFP keynote:

http://www.youtube.com/watch?v=XGyJ519RY6Y (video only, the presentation was liveish coding in emacs and I haven't found the source files)

Agda of course pursues the anti-thesis of dynamic typing.

That's what statically typed languages call "templates".

Or "generics". That's what I was trying to say in my last line; you can do that, but only if you think to use them when you originally write the function.

Which is not far-fetched... E.g. when adding type signatures to functions in Haskell, one generally uses the most general possible types/typeclasses.

Reply on news.ycombinator.com