Python is DOOMED! Again!

[Paul Rubin]

Devin Jeanpierre <jeanpierreda at gmail.com> writes:
> That said, Haskell (and the rest) do have a sort of type coercion, of
> literals at compile time (e.g. 3 can be an Integer or a Double
> depending on how you use it.)

That's polymorphism, not coercion.  The compiler figures out at compile
time what type of 3 you actually mean: there is never an automatic
runtime conversion.  sqrt(3) works because sqrt expects a floating
argument so the compiler deduces that the 3 that you wrote denotes a
float.  sqrt(3+length(xs)) has to fail because length returns an int, so
3+length(xs) is an int, and you can't pass an int to sqrt.

> BTW it's weird that in this thread, and in the programmer community at
> large, int->string is considered worse than int->float

Hehe, though int->string leads to plenty of weird bugs.

>> Haskell's idiomatic substitute for a null pointer is a Nothing value
> For that matter, how is this (first part) different from, say, Java?

In Java, functions expecting to receve sensible values can get null by
surprise.  In Haskell, if a term can have a Nothing value, that has to
be reflected in its type.  Haskell's bug-magnet counterpart to Java's
null values is Bottom, an artifact of lazy evaluation.  E.g. you can
write
   x = 3 / 0
someplace in your program, and the program will accept this and run
merrily until you try to actually print something that depends on x,
at which point it crashes.