5 ms·

Everyone needs types. Here's one of my favorite quotes: > "Dynamic typing" The belief that you can't explain to a computer why your code works, but you can ke

Everyone needs types. Here's one of my favorite quotes: > "Dynamic typing" The belief that you can't explain to a computer why your code works, but you can keep track of it all in your head. — Chris Martin (https://chris-martin.org/2015/dynamic-typing https://chris-martin.org/2015/dynamic-typing)

pdonis 6y ago
> Here's one of my favorite quotes Here's my response to that quote: "Static typing": The belief that if your code type-checks correctly, it will do exactly what you intended. (A variant of the belief that if your code compiles correctly, it will do exactly what you intended.) Of course, taken literally, that's unfair, but so is the quote you gave. Everything you add to your code has a cost. Time you spend writing type specifications is time you're not spending doing something else that might add more value. Sometimes writing type specifications is the best use you can make of that time; sometimes it isn't. Python at least gives you both options: use type annotations if you want, but you don't have to if you don't want to.
- IgorPartola 6y ago
  This. Can also be applied to unit testing: the belief that if your code passes its unit tests, it will do exactly what you intend. I see way too many code bases that test things that are easy and xfail things that are hard because it turns out that you can’t just test your way to a complex product, but you sure can make yourself feel good by testing the fact that a dict acts like a dict.
- benrbray 6y ago
  I see your point, but I do think the amount of time spent writing type specifications is (usually) negligible, in return for an extremely large benefit whenever the code needs to be read by you or someone else later. I would certainly argue that anyone who writes a library, whose public API will be consumed by hundreds or thousands of people, should always include type annotations. After working in a TypeScript codebase for so long, it's jarring to return to Python or even vanilla JavaScript where I no longer have breadcrumbs to help me keep track of how the code is organized. Python's type annotations leave something to be desired, in terms of how easy they are to include in code and how well the tooling supports them. I'd almost rather see something like "Typethon" with better syntax+soundness that compiles-to-Python. Types are an optional tool, sure, but they're one of the most valuable tools we have to catch (not eliminate entirely) bugs and hasten development (without introducing errors).
- aranchelk 6y ago
  > The belief that if your code type-checks correctly, it will do exactly what you intended. With a little care and a sufficiently strong type system it’s surprising how often this is actually true.
  - pmontra 6y ago
    This is the last bug I had to fix. Scenario: a credit transfer marketplace. When we auction an invoice, we snapshot the data about all the involved parties and show those data in all the screens about the invoice. However some of those screens didn't show the stored data, they showed the current ones, which is useless and very wrong. I know which tests can catch that bug but I wonder what type system could catch it at compile time. To make it worthwhile it must be easier than writing the test. We can stop at the JSON generation. No need to look into the React frontend.
    - KMag 6y ago
      Depending on how your code is structured, phantom types might work for your use case. They're useful for tracking metadata about the values being passed around, even though the methods and fields don't differ between your use cases.
      - pmontra 6y ago
        I googled phantom types Haskell: https://wiki.haskell.org/Phantom_type https://wiki.haskell.org/Phantom_type Python: https://phantom-types.readthedocs.io/en/stable/ https://phantom-types.readthedocs.io/en/stable/ Elm: https://dmalashock.com/elm-phantom-types/ https://dmalashock.com/elm-phantom-types/ Purescript: https://qiita.com/kimagure/items/b576b5bfe370180599f8 https://qiita.com/kimagure/items/b576b5bfe370180599f8 I'll give them a read. Thanks
    - aranchelk 6y ago
      That sounds like a pretty frustrating bug to try to find and fix. No type-level feature that I'm aware of could prevent this issue directly. What you're describing is pretty high-level business logic. While I've seen some pretty impressive demos with dependent types, nothing that I know of could handle this. I don't know much at all about the structure of your application, and it's hard to speculate, but what strikes me is your live and snapshotted data have the same shape/type and seem to be interchangeable for the compiler/interpreter, but are very different to you and your customers. The engineer creating that screen may have had the forethought at the outset to say "this should never deal with live data, only snapshots", so that warning probably gets put in a comment, but there's very little to stop someone from later passing in the live data that you definitely don't want. There's a feature in Haskell (and similar languages e.g. PureScript) called newtype declarations. They're a lightweight way you can tag and optionally limit access to your data. You essentially tell the compiler "this is a new and distinct type that can wrap the original one". The original and newtype are not interchangeable, and an attempt to do so won't compile. Having that feature I'm in the habit whenever I recognize overloaded meanings encoded with the same type (e.g. live/snapshot) of wrapping one of them in a newtype, and before I even implement application logic, I write out the signatures and specify which type I actually want. They add a bit of tediousness, but they have saved me many times, and I've never regretted using them.
- lmm 6y ago
  > "Static typing": The belief that if your code type-checks correctly, it will do exactly what you intended. No-one claims that typechecking solves 100% of problems. But it has a higher cost-benefit than anything else that's been tried. > Time you spend writing type specifications is time you're not spending doing something else that might add more value. So is time you spend thinking about the behaviour of the code in your head - the main difference is that it's slower and more error-prone. Occasionally you really can do the calculation about what kinds of expressions are valid in which places better than the computer. But that's a rare case that gets rarer every day. > Python at least gives you both options: use type annotations if you want, but you don't have to if you don't want to. Not really: your code will almost always be silently unsound. E.g. libraries you're using will usually have incorrect type annotations (because their type annotations aren't checked, and the checker is unsound even if they were). In contrast if you use say Haskell you genuinely do have both options: you can write code and have it be safely typed, or you can call unsafeCoerce at any point where you don't want typechecking to happen.
  - pdonis 6y ago
    > it has a higher cost-benefit than anything else that's been tried I would want to see a lot of data, for a lot of different kinds of programs, to back up this claim. > So is time you spend thinking about the behaviour of the code in your head You have to do this anyway; static typing doesn't write your code for you. Even Haskell, which I will freely admit is probably the closest thing to an AI that I've ever seen in a programming language, can't do that. :-) > your code will almost always be silently unsound Code that has type annotations has this same problem. That was the point of my response: static typing != sound code. > libraries you're using will usually have incorrect type annotations They can't be incorrect if they aren't there. The comparison I'm making is not between code with correct type annotations and code with incorrect ones. It's between code with type annotations and code without any of them at all.
    - valenterry 6y ago
      > > So is time you spend thinking about the behavior of the code in your head > You have to do this anyway; static typing doesn't write your code for you. Even Haskell, which I will freely admit is probably the closest thing to an AI that I've ever seen in a programming language, can't do that. :-) I think what he meant to say is that you spent 95% of your time to think about: "what is the kind of think I can from this method call and how can and should I use it and what should I return in the end". Writing down the result of your thoughts takes almost no time in comparison. Not only that, in good statically typed languages, you don't have to write down the types explicitly most of the time (but you can still have your IDE show them to you if you want to see them). And in addition to that, you certainly have to think _less_ in many cases. A good example are functions that return lists. Often you always have an element in the list. Using a good type-system, it will be indicated, so when I get the list, I know that I don't have to handle the case that the list is empty. In python I would often have to think _more_ about it and look into the documentation or maybe even the implementation to understand if it could return an empty list or not.
- momentoftop 6y ago
  Chris Martin is a Haskeller, and so will spend hardly any time writing type specifications. He'll let the compiler infer them. I'm very enthusiastic about static types with global type inference, where I don't have to write a single type annotation if I don't want to. My enthusiasm degrades pretty quickly the more annotations I have to manually clutter my code.
deleted 6y ago
[deleted]
dehrmann 6y ago
I can't seem to find the exact quote, but > Dynamically typed languages are actually statically typed with precisely one type: hash table.
- Spivak 6y ago
  This doesn't describe Python at all though. In Python objects have some data structure (usually a dict but not necessarily with __slots__) that hold the object's attributes but that's not the whole identity of the object. Because by this definition makes C++ and Java look dynamic with vtables.
  - dehrmann 6y ago
    True; it's a better description of Javascript.
coldtea 6y ago
He should stick to songwriting...
Spivak 6y ago
Dynamic typing is just "objects have types but variables don't" which is far less controversial.

pdonis 6y ago

> Here's one of my favorite quotes Here's my response to that quote: "Static typing": The belief that if your code type-checks correctly, it will do exactly what you intended. (A variant of the belief that if your code compiles correctly, it will do exactly what you intended.) Of course, taken literally, that's unfair, but so is the quote you gave. Everything you add to your code has a cost. Time you spend writing type specifications is time you're not spending doing something else that might add more value. Sometimes writing type specifications is the best use you can make of that time; sometimes it isn't. Python at least gives you both options: use type annotations if you want, but you don't have to if you don't want to.

IgorPartola 6y ago
This. Can also be applied to unit testing: the belief that if your code passes its unit tests, it will do exactly what you intend. I see way too many code bases that test things that are easy and xfail things that are hard because it turns out that you can’t just test your way to a complex product, but you sure can make yourself feel good by testing the fact that a dict acts like a dict.
benrbray 6y ago
I see your point, but I do think the amount of time spent writing type specifications is (usually) negligible, in return for an extremely large benefit whenever the code needs to be read by you or someone else later. I would certainly argue that anyone who writes a library, whose public API will be consumed by hundreds or thousands of people, should always include type annotations. After working in a TypeScript codebase for so long, it's jarring to return to Python or even vanilla JavaScript where I no longer have breadcrumbs to help me keep track of how the code is organized. Python's type annotations leave something to be desired, in terms of how easy they are to include in code and how well the tooling supports them. I'd almost rather see something like "Typethon" with better syntax+soundness that compiles-to-Python. Types are an optional tool, sure, but they're one of the most valuable tools we have to catch (not eliminate entirely) bugs and hasten development (without introducing errors).
aranchelk 6y ago
> The belief that if your code type-checks correctly, it will do exactly what you intended. With a little care and a sufficiently strong type system it’s surprising how often this is actually true.
- pmontra 6y ago
  This is the last bug I had to fix. Scenario: a credit transfer marketplace. When we auction an invoice, we snapshot the data about all the involved parties and show those data in all the screens about the invoice. However some of those screens didn't show the stored data, they showed the current ones, which is useless and very wrong. I know which tests can catch that bug but I wonder what type system could catch it at compile time. To make it worthwhile it must be easier than writing the test. We can stop at the JSON generation. No need to look into the React frontend.
  - KMag 6y ago
    Depending on how your code is structured, phantom types might work for your use case. They're useful for tracking metadata about the values being passed around, even though the methods and fields don't differ between your use cases.
    - pmontra 6y ago
      I googled phantom types Haskell: https://wiki.haskell.org/Phantom_type https://wiki.haskell.org/Phantom_type Python: https://phantom-types.readthedocs.io/en/stable/ https://phantom-types.readthedocs.io/en/stable/ Elm: https://dmalashock.com/elm-phantom-types/ https://dmalashock.com/elm-phantom-types/ Purescript: https://qiita.com/kimagure/items/b576b5bfe370180599f8 https://qiita.com/kimagure/items/b576b5bfe370180599f8 I'll give them a read. Thanks
  - aranchelk 6y ago
    That sounds like a pretty frustrating bug to try to find and fix. No type-level feature that I'm aware of could prevent this issue directly. What you're describing is pretty high-level business logic. While I've seen some pretty impressive demos with dependent types, nothing that I know of could handle this. I don't know much at all about the structure of your application, and it's hard to speculate, but what strikes me is your live and snapshotted data have the same shape/type and seem to be interchangeable for the compiler/interpreter, but are very different to you and your customers. The engineer creating that screen may have had the forethought at the outset to say "this should never deal with live data, only snapshots", so that warning probably gets put in a comment, but there's very little to stop someone from later passing in the live data that you definitely don't want. There's a feature in Haskell (and similar languages e.g. PureScript) called newtype declarations. They're a lightweight way you can tag and optionally limit access to your data. You essentially tell the compiler "this is a new and distinct type that can wrap the original one". The original and newtype are not interchangeable, and an attempt to do so won't compile. Having that feature I'm in the habit whenever I recognize overloaded meanings encoded with the same type (e.g. live/snapshot) of wrapping one of them in a newtype, and before I even implement application logic, I write out the signatures and specify which type I actually want. They add a bit of tediousness, but they have saved me many times, and I've never regretted using them.
lmm 6y ago
> "Static typing": The belief that if your code type-checks correctly, it will do exactly what you intended. No-one claims that typechecking solves 100% of problems. But it has a higher cost-benefit than anything else that's been tried. > Time you spend writing type specifications is time you're not spending doing something else that might add more value. So is time you spend thinking about the behaviour of the code in your head - the main difference is that it's slower and more error-prone. Occasionally you really can do the calculation about what kinds of expressions are valid in which places better than the computer. But that's a rare case that gets rarer every day. > Python at least gives you both options: use type annotations if you want, but you don't have to if you don't want to. Not really: your code will almost always be silently unsound. E.g. libraries you're using will usually have incorrect type annotations (because their type annotations aren't checked, and the checker is unsound even if they were). In contrast if you use say Haskell you genuinely do have both options: you can write code and have it be safely typed, or you can call unsafeCoerce at any point where you don't want typechecking to happen.
- pdonis 6y ago
  > it has a higher cost-benefit than anything else that's been tried I would want to see a lot of data, for a lot of different kinds of programs, to back up this claim. > So is time you spend thinking about the behaviour of the code in your head You have to do this anyway; static typing doesn't write your code for you. Even Haskell, which I will freely admit is probably the closest thing to an AI that I've ever seen in a programming language, can't do that. :-) > your code will almost always be silently unsound Code that has type annotations has this same problem. That was the point of my response: static typing != sound code. > libraries you're using will usually have incorrect type annotations They can't be incorrect if they aren't there. The comparison I'm making is not between code with correct type annotations and code with incorrect ones. It's between code with type annotations and code without any of them at all.
  - valenterry 6y ago
    > > So is time you spend thinking about the behavior of the code in your head > You have to do this anyway; static typing doesn't write your code for you. Even Haskell, which I will freely admit is probably the closest thing to an AI that I've ever seen in a programming language, can't do that. :-) I think what he meant to say is that you spent 95% of your time to think about: "what is the kind of think I can from this method call and how can and should I use it and what should I return in the end". Writing down the result of your thoughts takes almost no time in comparison. Not only that, in good statically typed languages, you don't have to write down the types explicitly most of the time (but you can still have your IDE show them to you if you want to see them). And in addition to that, you certainly have to think _less_ in many cases. A good example are functions that return lists. Often you always have an element in the list. Using a good type-system, it will be indicated, so when I get the list, I know that I don't have to handle the case that the list is empty. In python I would often have to think _more_ about it and look into the documentation or maybe even the implementation to understand if it could return an empty list or not.
momentoftop 6y ago
Chris Martin is a Haskeller, and so will spend hardly any time writing type specifications. He'll let the compiler infer them. I'm very enthusiastic about static types with global type inference, where I don't have to write a single type annotation if I don't want to. My enthusiasm degrades pretty quickly the more annotations I have to manually clutter my code.

deleted 6y ago

[deleted]

dehrmann 6y ago

I can't seem to find the exact quote, but > Dynamically typed languages are actually statically typed with precisely one type: hash table.

Spivak 6y ago
This doesn't describe Python at all though. In Python objects have some data structure (usually a dict but not necessarily with __slots__) that hold the object's attributes but that's not the whole identity of the object. Because by this definition makes C++ and Java look dynamic with vtables.
- dehrmann 6y ago
  True; it's a better description of Javascript.

coldtea 6y ago

He should stick to songwriting...

Spivak 6y ago

Dynamic typing is just "objects have types but variables don't" which is far less controversial.