11 ms·

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

rpedela 13y ago
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?
- tel 13y ago
  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.
  - rpedela 13y ago
    Fair enough.
- dlubarov 13y ago
  He was referring to Haskell's syntax for derived instances - http://www.haskell.org/tutorial/stdclasses.html#sect8.4 http://www.haskell.org/tutorial/stdclasses.html#sect8.4
- mightybyte 13y ago
  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.
- mrbrowning 13y ago
  > 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.
metaphorm 13y ago
stop using JavaScript as the basis for arguing against dynamic type systems. (not necessarily directed at you personally)
- asdasf 13y ago
  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.
  - deleted 13y ago
    [deleted]
wmil 13y ago
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?

tel 13y ago
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.
- rpedela 13y ago
  Fair enough.
dlubarov 13y ago
He was referring to Haskell's syntax for derived instances - http://www.haskell.org/tutorial/stdclasses.html#sect8.4 http://www.haskell.org/tutorial/stdclasses.html#sect8.4
mightybyte 13y ago
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.
mrbrowning 13y ago
> 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.

metaphorm 13y ago

stop using JavaScript as the basis for arguing against dynamic type systems. (not necessarily directed at you personally)

asdasf 13y ago
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.
- deleted 13y ago
  [deleted]

wmil 13y ago

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