3 ms·

Thanks! I'm glad you think so. I couldn't agree more re: strong, statically typed languages. The more information you give your compiler, the more it can help y

by samwho 9y ago

Thanks! I'm glad you think so. I couldn't agree more re: strong, statically typed languages. The more information you give your compiler, the more it can help you Do The Right Thing. :)

throwayawnotime 9y ago
If only it were that simple. You may be mixing up (1)"do the thing right" and (2)"do the right thing". Static typing does help on (1), some may think it's an hinderance on (2).
mads_ravn 9y ago
Found it nice as well, but one could argue that a couple of boxes are missing to the left: Requirements and Design. See for instance https://www.experimentus.com/itm/W_06_00055_The_Cost_of_Defects.htm https://www.experimentus.com/itm/W_06_00055_The_Cost_of_Defe... (love linking to "waterfall methodology" pages - makes me feel old :))
- samwho 9y ago
  Ahh, great point about design and requirements. If I do a revision of this post I’ll be sure to include them. Thank you :)
andybak 9y ago
Just as a counterpoint: Number of hours I've spent fixing type-related bugs in Python code = n Number of hours I've spent figuring out how to make the compiler happy in C# ~= n * 5 I'm not being altogether serious (I've written a lot more Python than C# so it's not a fair comparison) - but you're ignoring a lot of useful debate about static vs dynamic, explicit vs implicit, type inference, languages for teams vs languages for hackers etc etc. It's fine to not go down the rabbit hole but at least acknowledge there is some debate on this topic. Otherwise you give the impression that you think those of us who prefer dynamic languages are deluded oafs we are going to wake up one day, slap our foreheads and exclaim "Doh! It's only just occurred to me how useful explicit typing is. Silly me..." EDIT - I've always enjoyed this post to python-dev by Cory Benfield explaining why he disliked the idea of introducing type annotation to the requests library. https://lwn.net/Articles/643399/ https://lwn.net/Articles/643399/ Whilst it's not an indictment of all possible type systems it does give some flavour of how the mind sets differ in static and dynamic language communities. There is a genuine cost in expressiveness that surely can't be entirely dismissed out of hand.
- nerdponx 9y ago
  What they really want is "pattern matching on interfaces", aka Structural Typing. This is coming to MyPy soon in the form of "protocols": http://mypy.readthedocs.io/en/latest/class_basics.html http://mypy.readthedocs.io/en/latest/class_basics.html
- gnl 9y ago
  That's a refreshingly nuanced comment in a debate where people tend to be very quick to pick a side and stick with it no matter what. You also make a very good point regarding languages for teams vs hackers - this is overlooked very often. I'd just to like to point out that grouping together dynamically typed languages and comparing them to statically typed ones as a whole is really not useful at all due to the huge variations within each group in terms of correctness and expressiveness. When people compare dynamic vs static languages they generally compare the languages they're familiar with and often assume that they are representative of the group to a sufficiently high degree. They're not. Using Clojure for example is a very different experience from using Python and not just cosmetically. Clojure with spec is a very different experience from plain Clojure. Haskell is very different from C#. I'd encourage anyone with an interest in using the best tool for the job and increasing their effectiveness as developers to at least dabble in what I would consider to be the state of the art in practically usable, more or less mainstream languages in both camps - Haskell and Clojure (with an extensive use of spec). You are likely to realise that statically typed languages can be way more expressive and less bend-over-backwards-for-no-good-reason-to-make-the-compiler-happy than C# or Java and dynamic languages can be significantly more capable of ensuring correctness and 'moving bugs to the left' than Python and JavaScript.

by samwho 9y ago

Thanks! I'm glad you think so. I couldn't agree more re: strong, statically typed languages. The more information you give your compiler, the more it can help you Do The Right Thing. :)

throwayawnotime 9y ago

If only it were that simple. You may be mixing up (1)"do the thing right" and (2)"do the right thing". Static typing does help on (1), some may think it's an hinderance on (2).

mads_ravn 9y ago

Found it nice as well, but one could argue that a couple of boxes are missing to the left: Requirements and Design. See for instance https://www.experimentus.com/itm/W_06_00055_The_Cost_of_Defects.htm https://www.experimentus.com/itm/W_06_00055_The_Cost_of_Defe... (love linking to "waterfall methodology" pages - makes me feel old :))

samwho 9y ago
Ahh, great point about design and requirements. If I do a revision of this post I’ll be sure to include them. Thank you :)

andybak 9y ago

Just as a counterpoint: Number of hours I've spent fixing type-related bugs in Python code = n Number of hours I've spent figuring out how to make the compiler happy in C# ~= n * 5 I'm not being altogether serious (I've written a lot more Python than C# so it's not a fair comparison) - but you're ignoring a lot of useful debate about static vs dynamic, explicit vs implicit, type inference, languages for teams vs languages for hackers etc etc. It's fine to not go down the rabbit hole but at least acknowledge there is some debate on this topic. Otherwise you give the impression that you think those of us who prefer dynamic languages are deluded oafs we are going to wake up one day, slap our foreheads and exclaim "Doh! It's only just occurred to me how useful explicit typing is. Silly me..." EDIT - I've always enjoyed this post to python-dev by Cory Benfield explaining why he disliked the idea of introducing type annotation to the requests library. https://lwn.net/Articles/643399/ https://lwn.net/Articles/643399/ Whilst it's not an indictment of all possible type systems it does give some flavour of how the mind sets differ in static and dynamic language communities. There is a genuine cost in expressiveness that surely can't be entirely dismissed out of hand.

nerdponx 9y ago
What they really want is "pattern matching on interfaces", aka Structural Typing. This is coming to MyPy soon in the form of "protocols": http://mypy.readthedocs.io/en/latest/class_basics.html http://mypy.readthedocs.io/en/latest/class_basics.html
gnl 9y ago
That's a refreshingly nuanced comment in a debate where people tend to be very quick to pick a side and stick with it no matter what. You also make a very good point regarding languages for teams vs hackers - this is overlooked very often. I'd just to like to point out that grouping together dynamically typed languages and comparing them to statically typed ones as a whole is really not useful at all due to the huge variations within each group in terms of correctness and expressiveness. When people compare dynamic vs static languages they generally compare the languages they're familiar with and often assume that they are representative of the group to a sufficiently high degree. They're not. Using Clojure for example is a very different experience from using Python and not just cosmetically. Clojure with spec is a very different experience from plain Clojure. Haskell is very different from C#. I'd encourage anyone with an interest in using the best tool for the job and increasing their effectiveness as developers to at least dabble in what I would consider to be the state of the art in practically usable, more or less mainstream languages in both camps - Haskell and Clojure (with an extensive use of spec). You are likely to realise that statically typed languages can be way more expressive and less bend-over-backwards-for-no-good-reason-to-make-the-compiler-happy than C# or Java and dynamic languages can be significantly more capable of ensuring correctness and 'moving bugs to the left' than Python and JavaScript.