I think he means having to implement toString() ten times to handle all the various types that need to be converted to strings. toString() is a trivial example because most languages have that built-in to some degree. But there have been several times where I would have to write the same C/C++ function again and again to support a new type.

In Python, you have to reimplement __repr__ for every class whereas in Haskell you use deriving Show. This has nothing to do with static vs dynamic.

Python's `__dict__` is probably a better example of duplicating Haskell's `derive Show` behavior.

Why? __repr__ (or __str__) is pretty much the "show" method, in Python. It isn't derivable (or rather, the default derivable one is useless), though.

Try "deriving (Show)". And stop using the C/C++/Java straw man as the basis for arguing against static type systems.

But if we exclude C/C++/Java then static typing is just an obscure feature of some academic languages.

I don't know what your first sentence means. As for the second, I was explaining what I thought the author meant by "scaffolding" not making an argument for or against anything. Now here is an argument for you: shouldn't two of most widely used languages be included in an argument about static vs dynamic typing?

The first sentence is a hint toward Haskell's wonderful derivation system which tells the compiler to write the "obvious" code for all kinds of common scaffolds. It's almost always all you need for equality, showing, ordering, hashing. There's also the GeneralizedNewtypeDeriving which allows you to inherit instantiation of types into all kinds of structurally equivalent types.

And while it's valuable to talk about popular languages in terms of the kind of static typing people are likely to encounter... they also have really outdated static type systems. While you can argue that it's likely that you'll bump into Java/C/C++ when working with static types, it's pretty invalid to argue generally about static type systems using them as examples. Things have just come a really long way.

Fair enough.

And my first sentence was explaining why even that interpretation of the author's meaning is an invalid argument. It demonstrates the equivalent of writing toString() in Haskell. And no, the two most widely used languages should most definitely NOT be used in an argument about static typing because the state of the art in static typing has evolved significantly since those languages were created. The fact that you didn't know the meaning of my first sentence tells me that you're arguing from ignorance about what is possible today in a fairly well-established language.

He was referring to Haskell's syntax for derived instances - http://www.haskell.org/tutorial/stdclasses.html#sect8.4

> shouldn't two of most widely used languages be included in an argument about static vs dynamic typing?

No, because the affordances and limitations of static typing are not the same as the affordances and limitations of static typing as implemented in Java/C++. You can't infer very much about static typing from statements made about those languages, and you can't infer much about those languages from statements made about static typing, so it follows that you can't freely substitute one for the other in these discussions.

stop using JavaScript as the basis for arguing against dynamic type systems.

(not necessarily directed at you personally)

Who does that? Dynamic type systems don't actually exist, it is simply a lack of a static type system. Nobody argues about dynamic type systems, they argue about whether or not to have a static type system.

> there have been several times where I would have to write the same C/C++ function again and again to support a new type.

If the function has to handle different types in different ways, you'd have to write it again anyway. Otherwise, you could have used templates.

Why did you have to write the same function again and again? I guess polymorphism would have helped, would it not? Not knowing too much c++ I can't really comment so I guess I am asking for a clarification.

C does not have proper support for polymorphism. It can be simulated with structs in certain cases though. I can't remember a specific instance with C++ off the top of my head. It has been a several years since I touched it. Sorry.

In what language do you not have to implement a conversion-to-string for each type? It's not like the compiler can know what string representation you have in mind for some arbitrary object.

Haskell. It's often not about a specific representation, but rather just some representation that allows you to see a type's internals.

For debug purpose (like you'd use Show in Haskell), Perl gives use Data::Dumper to dump your data structures. Not quite the same as deriving Show, but for most purposes, entirely sufficient.

That is an argument against particular languages that happen to be statically typed. That is not an argument against static typing, which requires nothing of the sort.

One example in the article was the difference between def qsort(a) and public static void ArrayList<Integer> qsort(ArrayList<Integer> a)