Adoption of Mypy for Python type checking: 45% already use it, 40% don't plan to

I think the type systems are simple enough that this is probably a theoretical concern, and won't come up often in practice.

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.

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.

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_empiri...

Or 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.

    >>> class Money:
    ...   def __init__(self, currency, amount):
    ...     self.m = Counter({currency: amount})
    ...   def __add__(self, other):
    ...     self.m += other.m
    ...   
    >>> Money("USD", 10) + Money(10, "EUR”)
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "<string>", line 5, in __add__
      File "/var/containers/Bundle/Application/F8EBA093-47B6-4538-A3A5-553C9C2234FA/Pythonista3.app/Frameworks/Py3Kit.framework/pylib/collections/__init__.py", line 805, in __iadd__
        self[elem] += count
     TypeError: unsupported operand type(s) for +=: 'int' and 'str'

In all seriousness though, how far do such mistakes survive? Not past compile here, but in other cases it could. Could it pass tests? Unlikely. Could it pass casually running the code, not impossible but again seems unlikely.

How many PRs on Github for projects written in dynamically typed languages are things that would be caught by static types? Some, it’s non-zero, it’s not anywhere close to a significant proportion though.

    use std::ops::Add;

    fn main() {
        let usd = Money {
            currency: String::from("USD"),
            amount: 10
        };
        let eur = Money {
            currency: String::from("EUR"),
            amount: 10
         };
         dbg!(usd + eur);
     }

     #[derive(Debug)]
     struct Money {
      currency: Currency,
      amount: Amount
    }

    impl Add for Money {
        type Output = Money;
  
        fn add(self, other: Money) -> Money {
          Money {
            currency: self.currency,
            amount: self.amount + other.amount
          }
      }
    }

    type Currency = String;
    type Amount = i32; // i know :-)

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).

I love Emacs for its extensibility and the capability to make changes to the system and see them immediately. Until programming languages like Mun catch up, I doubt it would be possible to replace Emacs Lisp with a statically typed language and retain the same amount of extensibility. Part of the requirements would be having the ability to replace the implementation of any function in the system at runtime, and that's the kind of thing you have no choice but to design your language from the ground up to include.

I guess what I mean to say is that it's not static languages that make me miss dynamic language features, it's that there's no statically typed language that supports the runtime hotloading that I can accomplish with a few Lua scripts (and has enough community traction to support something like LÖVE 2D).

Steve Yegge wrote an article related to this. He suggests that people who use static type systems are mostly trying to catch errors at compile time, errors which have no relevance after the typechecking is over with and the code is run (in the sense that machine code has no understanding of types). Static and dynamic languages will both ultimately output machine code that does the same thing, but one language incurs a massive penalty to flexibility of change. It's a rant, but it made me think that maybe you could have the type checking to catch errors at the time you're specifically looking for errors, and use the dynamism of the underlying implementation later on.

http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.ht...