7 ms·

This seems very positive to me - specifically that a sizeable population recognise they really don't need it. Used correctly - i.e. you’re leaning on structura

This seems very positive to me - specifically that a sizeable population recognise they really don't need it. Used correctly - i.e. you’re leaning on structural typing, so you invest your time in Protocols that go “quack” rather than hard-to-test, brittle, nominatively typed Ducks who quack - which incidentally is exactly the path the mypy getting started docs seems to focus on, why?! - that’s just setting people up for failure, i digress. Mypy, pyright etc are fantastic tools in the toolbox, sure to save time but Cargo culting is a pain to deal with. See for example 2 decades of empty getters / setters in Java “in case we ever want to add some behaviour in future”. Gradual typing of the structural variety is fantastic, you’ll know if you’re doing it right because you’ll spend surprisingly little time thinking about types, you won’t spend any time wrestling with mypy to convince it of your idea and when it does complain your reaction will be a legitimate “aha, yeah ok fair shout, you got me” not “oh ffs!” :-) One really cool thing about gradual typing - if you get it wrong and i have to take over your code, i can at least turn it off. One of the reasons i love tests so much - I don’t have to accept yours if they’re a bear to maintain, i can easily bring along my own instead.

skohan 6y ago
I find it hard to imagine cases where gradual typing would have any advantages over a language with decent, modern type inference. In the latter case, you're still not typing type specifiers very often, but you get unambiguous function signatures, and can eliminate whole classes of runtime errors.
- pansa2 6y ago
  What might “Python, but with modern type inference” look like? Are there other existing languages that come close to matching that description?
  - ipaddr 6y ago
    Possible referring to php and the auto type casting? He couldn't possible mean javascript or rust. Perhaps golang because of the limited subset of types.
    - skohan 6y ago
      Swift/kotlin are better examples of languages which allow you to stay very high level with types to keep you honest
  - nicoburns 6y ago
    Nim?
  - joshuamorton 6y ago
    Python, with a few type annotations and pytype.
  - ojbyrne 6y ago
    I'm going to take a guess and say that the OP is referring to languages that implement the Hindley-Miner algorithm. According to Wikipedia: "Some languages that include type inference include C++11, C# (starting with version 3.0), Chapel, Clean, Crystal, D, F#,[1] FreeBASIC, Go, Haskell, Java (starting with version 10), Julia,[2] Kotlin, ML, Nim, OCaml, Opa, RPython, Rust, Scala, Swift,[3] TypeScript,[4] Vala, Dart,[5] and Visual Basic (starting with version 9.0)." https://en.wikipedia.org/wiki/Type_inference#Types_in_programming_languages https://en.wikipedia.org/wiki/Type_inference#Types_in_progra...
  - nimmer 6y ago
    You described Nim: https://nim-lang.org https://nim-lang.org
- mumblemumble 6y ago
  Data science. Static typing is a complete PITA when you're doing exploratory data work. Type inference only fixes things on a superficial level. For data engineering, I haven't had a chance to try this due to lack of language options, but I strongly suspect that structural typing would be much more useful than nominal typing.
  - skohan 6y ago
    Yeah but even then you can usually deserialize a CSV or json into “plain” data structures like arrays and dicts to explore it, and then switch over to a more rhobist, automatically serializable one when you have a better idea what the data looks like
    - mumblemumble 6y ago
      You can, but, IME, the practical benefit of doing so generally isn't proportional to the cost. It's just something you do if you have strong feelings about type discipline and are willing to sink a bunch of time into soothing them. It may have to do with the types you're using. When I'm doing EDA, I'm usually zooming past the arrays and dicts as quickly as I can, and making a beeline for something like Pandas that lets me manipulate the data more easily. Pandas is fairly pretty resistant to static typing, and getting over to something that does play nicer with static typing tends to also necessitate a lot of wheel reinvention. Tends to also bring a performance cost, too, since I'm often losing a lot of nice fast multithreaded C++ implementation for a mess of pointer chasing and GIL.
  - exdsq 6y ago
    I’m not sure I really get this argument - you need to know something about the type you’re getting to explore it, so why does specifying that type slow things down more than any gains you would with run time errors from hacking around?
    - PeterisP 6y ago
      You're often reading and processing a data source that's explicitly not "well typed" (heterogenous 'columns', heterogenous deep nested json structures, null values in places where they shouldn't be, garbage rows, etc), where getting them to fit any reasonable type assertions would be a lot of work in correcting and/or filtering that data, which is something that you would write after your exploration is done. Also, it's not uncommon to not be sure about anything in the data structure you're getting; it's so often that the schema or documentation of that data is wrong or outdated or simply missing, so understanding the properties of the data types is a key part of that exploration. You start with eyeballing the data with your code; making some assumptions, and making code to process and analyze the data that doesn't meet your type assumptions, instead of throwing a runtime error as soon as your assumptions are wrong and conflict with the data.
- CraigJPerry 6y ago
  Time to market? Type inference solves a different problem - it doesn’t help you here. For example type Money { amount: Amount, currency: Currency } Money(USD, 10) + Money(EUR, 10) # what type should be inferred here? A runtime exception maybe? (There’s no “best” answer here, a runtime exception might be the pragmatic choice but i like the Map<Currency, Amount> solution to this).
  - skohan 6y ago
    Unless your application is implemented in under 100 lines, types will save you time in general
    - CraigJPerry 6y ago
      This is obviously false, it’s just too general a statement. Type errors are such a small time loss as a developer - when i think of the things that lose me time, it’s things like domain complexity, misunderstood requirements, not “ooops i passed a string instead of list of string”. I wondered if there are any studies that support your assertion? The first few results in Google all refute your idea though, e.g. https://www.researchgate.net/publication/259634489_An_empirical_study_on_the_impact_of_static_typing_on_software_maintainability https://www.researchgate.net/publication/259634489_An_empiri... Or https://www.ics.uci.edu/~jajones/INF102-S18/readings/23_hanenberg.pdf https://www.ics.uci.edu/~jajones/INF102-S18/readings/23_hane... And that intuitively makes sense. When i’m adopting types, time saving isn’t really what i’m buying. It’s the opposite - i’m saying “hey, i want to invest more time into this to help ensure correctness” - i.e. i am happy to wrestle with the type system if it means the delegation frees my brain for solving the problem. And this comes back to what i mentioned earlier about domain complexity - you can use types to help make that easier to manage, often though, it’s better to push harder to eliminate complexity in the first place. Occasionally that’s just not possible, it’s a complex problem domain not another CRUD webapp, in those cases types are fantastic.
      - skohan 6y ago
        > Type errors are such a small time loss as a developer It's not about the errors themselves, it's about the way that having a strong type system improves quality of life in general. For instance, in a duck-typed language, you may have code which runs correctly 99/100 times, but with one specific case it fails due to type issues. These kinds of issues are incredibly frustrating and time-consuming to debug. Also requiring type designations in function signatures makes code self-documenting. You can just look at the code which someone else wrote, and know exactly what the inputs and outputs are. In a dynamically typed setting, there's often guess work involved in exactly what's accepted by a function, and unless it's very well documented you might have to go into the implementation to see exactly what is happening. I didn't read the articles you linked in detail, but at least the first I would take with a grain of salt since they use Java as the exemplar for typed programming. Java is notorious for having a cumbersome type system. In my experience, without types you might get a slightly faster time to first result - but in the long term, once a codebase gets to even medium size, types save you much more time than they cost. Especially since they become automatic after a bit of experience and you don't even think about it anymore. There's a reason Python and Javascript are trying to add types, and why none of the most interesting languages of the past decade have been weekly typed.
- nicoburns 6y ago
  Dynamic types are considerably more flexible than static types. It's not just about typings them out. There are lots of types that you just can't have in static languages (that exist so far), because the language doesn't have the vocabulary to describe them. Code in dynamic languages typically takes advantage of the flexibility to do meta-programming, which can significantly both the amount of code required to complete a task and its complexity.
  - c-cube 6y ago
    I keep hearing that, but in practice one can have macros/code generation in a static language. Maybe meta programming takes a bit more effort, but it's the kind of thing best done in a well tested library. A lot of modern typed languages have got pretty decent meta programming: rust procedural macros, nim, D, crystal, Zig... Where's the equivalent of serde in python? It's mostly runtime type driven deserialization that is orders of magnitudes slower.
    - CraigJPerry 6y ago
      hyperjson? (Python bindings for Rust’s serdes-rs). It’s not really a cheat answer - what if you could iterate quickly and launch 5 startup ideas in the time to launch 1 written in Zig but when one of your 5 turns out to be the next Youtube / Instagram / Facebook / [insert other huge traffic site launched on a “slow” backend here] then you have the freedom to glue in some optimised native code in the hot path? I haven’t gotten to macros yet in my Rust playtime so far but Rust does seem like a really nice complement to Python. Go/Swift strike me as a faster Python - nothing wrong with that, Rust strikes me as a different kind of tool, that appeals. Zig / nim are too bleeding edge for me, when i saw the cool kids start to decry Rust, that was my cue to finally go order the O’Reilly book and dig in (i’ll admit to reading up about comptime to see what the fuss was about - cool idea, i’ll stick with trying Rust for now).
      - c-cube 6y ago
        That's interesting. The recent post about a fast dataframe library in rust (polars, I think) and its python bindings is also telling. Py3O might be a rust+python kind of secret weapon in terms of speed and productivity... And it's based on the procedural macros I was mentioning :-).
mumblemumble 6y ago
What seems positive to me is that there's a good mix. It speaks to the eminent pragmatism of the way Python decided to handle typing and type hints. I've found that there is no one best typing discipline. Different approaches work better for different problem domains. And I'm currently using Python in so many different problem domains that I find it convenient that Python now allows me to choose the best typing discipline for the job. It's true that this means that Python isn't the best at any particular way of doing typing. But that also seems appropriate. Being a jack of all trades and master of none is sort of Python's thing nowadays.

skohan 6y ago

I find it hard to imagine cases where gradual typing would have any advantages over a language with decent, modern type inference. In the latter case, you're still not typing type specifiers very often, but you get unambiguous function signatures, and can eliminate whole classes of runtime errors.

pansa2 6y ago
What might “Python, but with modern type inference” look like? Are there other existing languages that come close to matching that description?
- ipaddr 6y ago
  Possible referring to php and the auto type casting? He couldn't possible mean javascript or rust. Perhaps golang because of the limited subset of types.
  - skohan 6y ago
    Swift/kotlin are better examples of languages which allow you to stay very high level with types to keep you honest
- nicoburns 6y ago
  Nim?
- joshuamorton 6y ago
  Python, with a few type annotations and pytype.
- ojbyrne 6y ago
  I'm going to take a guess and say that the OP is referring to languages that implement the Hindley-Miner algorithm. According to Wikipedia: "Some languages that include type inference include C++11, C# (starting with version 3.0), Chapel, Clean, Crystal, D, F#,[1] FreeBASIC, Go, Haskell, Java (starting with version 10), Julia,[2] Kotlin, ML, Nim, OCaml, Opa, RPython, Rust, Scala, Swift,[3] TypeScript,[4] Vala, Dart,[5] and Visual Basic (starting with version 9.0)." https://en.wikipedia.org/wiki/Type_inference#Types_in_programming_languages https://en.wikipedia.org/wiki/Type_inference#Types_in_progra...
- nimmer 6y ago
  You described Nim: https://nim-lang.org https://nim-lang.org
mumblemumble 6y ago
Data science. Static typing is a complete PITA when you're doing exploratory data work. Type inference only fixes things on a superficial level. For data engineering, I haven't had a chance to try this due to lack of language options, but I strongly suspect that structural typing would be much more useful than nominal typing.
- skohan 6y ago
  Yeah but even then you can usually deserialize a CSV or json into “plain” data structures like arrays and dicts to explore it, and then switch over to a more rhobist, automatically serializable one when you have a better idea what the data looks like
  - mumblemumble 6y ago
    You can, but, IME, the practical benefit of doing so generally isn't proportional to the cost. It's just something you do if you have strong feelings about type discipline and are willing to sink a bunch of time into soothing them. It may have to do with the types you're using. When I'm doing EDA, I'm usually zooming past the arrays and dicts as quickly as I can, and making a beeline for something like Pandas that lets me manipulate the data more easily. Pandas is fairly pretty resistant to static typing, and getting over to something that does play nicer with static typing tends to also necessitate a lot of wheel reinvention. Tends to also bring a performance cost, too, since I'm often losing a lot of nice fast multithreaded C++ implementation for a mess of pointer chasing and GIL.
- exdsq 6y ago
  I’m not sure I really get this argument - you need to know something about the type you’re getting to explore it, so why does specifying that type slow things down more than any gains you would with run time errors from hacking around?
  - PeterisP 6y ago
    You're often reading and processing a data source that's explicitly not "well typed" (heterogenous 'columns', heterogenous deep nested json structures, null values in places where they shouldn't be, garbage rows, etc), where getting them to fit any reasonable type assertions would be a lot of work in correcting and/or filtering that data, which is something that you would write after your exploration is done. Also, it's not uncommon to not be sure about anything in the data structure you're getting; it's so often that the schema or documentation of that data is wrong or outdated or simply missing, so understanding the properties of the data types is a key part of that exploration. You start with eyeballing the data with your code; making some assumptions, and making code to process and analyze the data that doesn't meet your type assumptions, instead of throwing a runtime error as soon as your assumptions are wrong and conflict with the data.
CraigJPerry 6y ago
Time to market? Type inference solves a different problem - it doesn’t help you here. For example type Money { amount: Amount, currency: Currency } Money(USD, 10) + Money(EUR, 10) # what type should be inferred here? A runtime exception maybe? (There’s no “best” answer here, a runtime exception might be the pragmatic choice but i like the Map<Currency, Amount> solution to this).
- skohan 6y ago
  Unless your application is implemented in under 100 lines, types will save you time in general
  - CraigJPerry 6y ago
    This is obviously false, it’s just too general a statement. Type errors are such a small time loss as a developer - when i think of the things that lose me time, it’s things like domain complexity, misunderstood requirements, not “ooops i passed a string instead of list of string”. I wondered if there are any studies that support your assertion? The first few results in Google all refute your idea though, e.g. https://www.researchgate.net/publication/259634489_An_empirical_study_on_the_impact_of_static_typing_on_software_maintainability https://www.researchgate.net/publication/259634489_An_empiri... Or https://www.ics.uci.edu/~jajones/INF102-S18/readings/23_hanenberg.pdf https://www.ics.uci.edu/~jajones/INF102-S18/readings/23_hane... And that intuitively makes sense. When i’m adopting types, time saving isn’t really what i’m buying. It’s the opposite - i’m saying “hey, i want to invest more time into this to help ensure correctness” - i.e. i am happy to wrestle with the type system if it means the delegation frees my brain for solving the problem. And this comes back to what i mentioned earlier about domain complexity - you can use types to help make that easier to manage, often though, it’s better to push harder to eliminate complexity in the first place. Occasionally that’s just not possible, it’s a complex problem domain not another CRUD webapp, in those cases types are fantastic.
    - skohan 6y ago
      > Type errors are such a small time loss as a developer It's not about the errors themselves, it's about the way that having a strong type system improves quality of life in general. For instance, in a duck-typed language, you may have code which runs correctly 99/100 times, but with one specific case it fails due to type issues. These kinds of issues are incredibly frustrating and time-consuming to debug. Also requiring type designations in function signatures makes code self-documenting. You can just look at the code which someone else wrote, and know exactly what the inputs and outputs are. In a dynamically typed setting, there's often guess work involved in exactly what's accepted by a function, and unless it's very well documented you might have to go into the implementation to see exactly what is happening. I didn't read the articles you linked in detail, but at least the first I would take with a grain of salt since they use Java as the exemplar for typed programming. Java is notorious for having a cumbersome type system. In my experience, without types you might get a slightly faster time to first result - but in the long term, once a codebase gets to even medium size, types save you much more time than they cost. Especially since they become automatic after a bit of experience and you don't even think about it anymore. There's a reason Python and Javascript are trying to add types, and why none of the most interesting languages of the past decade have been weekly typed.
nicoburns 6y ago
Dynamic types are considerably more flexible than static types. It's not just about typings them out. There are lots of types that you just can't have in static languages (that exist so far), because the language doesn't have the vocabulary to describe them. Code in dynamic languages typically takes advantage of the flexibility to do meta-programming, which can significantly both the amount of code required to complete a task and its complexity.
- c-cube 6y ago
  I keep hearing that, but in practice one can have macros/code generation in a static language. Maybe meta programming takes a bit more effort, but it's the kind of thing best done in a well tested library. A lot of modern typed languages have got pretty decent meta programming: rust procedural macros, nim, D, crystal, Zig... Where's the equivalent of serde in python? It's mostly runtime type driven deserialization that is orders of magnitudes slower.
  - CraigJPerry 6y ago
    hyperjson? (Python bindings for Rust’s serdes-rs). It’s not really a cheat answer - what if you could iterate quickly and launch 5 startup ideas in the time to launch 1 written in Zig but when one of your 5 turns out to be the next Youtube / Instagram / Facebook / [insert other huge traffic site launched on a “slow” backend here] then you have the freedom to glue in some optimised native code in the hot path? I haven’t gotten to macros yet in my Rust playtime so far but Rust does seem like a really nice complement to Python. Go/Swift strike me as a faster Python - nothing wrong with that, Rust strikes me as a different kind of tool, that appeals. Zig / nim are too bleeding edge for me, when i saw the cool kids start to decry Rust, that was my cue to finally go order the O’Reilly book and dig in (i’ll admit to reading up about comptime to see what the fuss was about - cool idea, i’ll stick with trying Rust for now).
    - c-cube 6y ago
      That's interesting. The recent post about a fast dataframe library in rust (polars, I think) and its python bindings is also telling. Py3O might be a rust+python kind of secret weapon in terms of speed and productivity... And it's based on the procedural macros I was mentioning :-).

mumblemumble 6y ago

What seems positive to me is that there's a good mix. It speaks to the eminent pragmatism of the way Python decided to handle typing and type hints. I've found that there is no one best typing discipline. Different approaches work better for different problem domains. And I'm currently using Python in so many different problem domains that I find it convenient that Python now allows me to choose the best typing discipline for the job. It's true that this means that Python isn't the best at any particular way of doing typing. But that also seems appropriate. Being a jack of all trades and master of none is sort of Python's thing nowadays.