[bpshaver]

That would seem to be begging the question to an extent. Why does dynamic typing lead to lower development effort? I mostly write Python and make heavy use of type hints. With LSP set up, mypy informs me immediately of any potential type errors which makes development way easier for me.

Just saying "dynamic typing is easier" doesn't do it for me without further qualification since that statement doesn't conform to my own experience.

[doug_durham]

How much is maintaining your type system really helping you out? I find I spend more time tracking down irrelevant type warnings than fixing type issues. For example if you declare a type hint on a function parameter as `foo: int = None` you will get a type error. It says that a parameter of type int can't have a None value. This is false. So now I have to update my declaration to be `foo: Optional[int] = None`. This yields no value because when you say `= None` you are saying that this is an optional argument. The more you tighten your type declarations the more you will be chasing non-existent issues.

[dragonwriter]

> For example if you declare a type hint on a function parameter as `foo: int = None` you will get a type error. It says that a parameter of type int can't have a None value. This is false.

No, it is correct. The value None is not with the domain of type int, a parameter that can take the value None does not in fact have type int.

> This yields no value because when you say `= None` you are saying that this is an optional argument.

When you provide any default value, you are making the argument optional, but that's an orthogonal concern to the Optional[T] type, which doesn't mean “optional argument", it is simply a more convenient way of expressing Union[T, None], though with the modern type syntax, T | U is generally more convenient than either Union[T, U] or Optional[T] for U=None.

[bpshaver]

No offense, but this sounds like user error. I rarely have irrelevant type warnings. If I do, it suggests something is wrong with my design.

If you declare a function parameter as `foo: int = None`... that is just an incorrect declaration. Of course a variable annotated as `int` can take a `None` value, but that is because any variable can take any type in Python. Within the Python type (annotation) system it is simply the case that an `int` and an `int | None` are two different things, as they are in other languages (eg Rust's `T` vs `Option<T>` types).

Mypy used to support the "implicit optional" feature you describe but now you must make nullable arguments explicitly optional. This is in line with Python's "explicit is better than implicit" design philosophy. In any case, how long does it take you to just type `foo: int | None = None`? Or you could re-enable the old behavior to allow implicit optionals with `--implicit-optional` or the corresponding config file option. It seems like you just need to configure mypy to match your preferences rather than fighting with its defaults.

To return to the broader point, I'm unsure what an "irrelevant type warning" is, but I suspect that has something to do with my lack of appreciation for dynamic typing. Can you give an example that isn't just a complaint about typing an extra 6 characters or about mypy being misconfigured for your preferences?

[doug_durham]

No offense taken. I've had a long career with many different phases. I had a phase where I built palaces of types bordering on DSLs. I ended up building myself a straight jacket. I wasn't solving the customer problem, and I was only slowing myself down. Software is an engineering discipline. Every situation needs to be critically evaluated. Building a life-critical single point of failure component is much different than building a road over a culvert. In early languages you needed to specify types so the compiler knew how much space to allocate for storage. In languages like Python, type hints are more like documentation. It helps the reader understand how to use your code. It can be used for correctness. However if correctness is a primary criteria driven by engineering requirements I'd probably consider another language and accept that it is going to cost more and be slower to develop.

[igouy]

>That would seem to be begging the question …

Please excuse my pedantry: That would seem to lead to the question …

[bpshaver]

No, I was correct. Briefly, my question was "why is static typing good?" and the answer given was "static typing is good because it makes development easier." To the extent that "good" here just means "makes development easier" (and I think that is a lot of what "good" means in this context) then the answer I received was question begging to precisely that extent. Which is why I said "... to an extent." The conclusion was not quite assumed but a pretty similar conclusion was.

I can see how it appeared that I was using the phrase in the incorrect way! That usage bothers me too, and I am attentive to it.

[igouy]

Yes, you were correct. Apologies.

[lisper]

> Why does dynamic typing lead to lower development effort?

Because you can run your program to see what it does without having to appease the type checker first.

There is nothing wrong with presenting type hints or type errors as warnings. The problems arise when the compiler just flat-out refuses to run your code until you have finished handling every possible branch path.

[static_void]

In Rust, the `todo!()` macro will fill in type holes without needing to be finished.

Surely you can't be against putting a TODO in an unfinished part of the code?

[lisper]

I'm against anything that adds cognitive load without a compelling reason, anything makes me do unnecessary work. Typing "todo!()" is not a huge burden, but it's not zero, and if the Rust compiler is smart enough to fill in the hole it should be smart enough to do it without my having to explicitly tell it.

[kibwen]

No, because 99.9999% of the time, you explicitly do not want the compiler implicitly filling in a hole like that, and do want the compiler to tell you that you've forgotten an entire branch of control flow. Typing `todo!()` to make your intent explicit is among the least obtrusive things imaginable.

[lisper]

> No, because 99.9999% of the time, you explicitly do not want the compiler implicitly filling in a hole like that

Who are you to tell me what I want? You are making all manner of tacit assumptions about the kind of work I do and what my requirements are. I absolutely do want the compiler filling in every hole it possibly can. For me, that's the whole point of using a high-level language in the first place. For the kind of work I do, what matters most is getting things done as quickly as possible. Correctness and run-time efficiency are secondary considerations.

[kibwen]

If correctness is a secondary consideration, then you'll be happy to learn that LLMs will let you code in plain English, so there's no need to bother with using a programming language at all. The LLM will happily fill in all the holes it encounters, more eagerly than any compiler would ever dream of.

But for people who prioritize precision and correctness, that's what programming languages were invented for.

[bpshaver]

What is an example of a compiler that flat out refuses to run (compile) your code? Obviously Python is not an example. The other language I know best is Rust, where as I understand the compiler doesn't refuse to compile your code, it cannot compile your code. Is there a language where the compiler could compile your code but refuses to do so unless the types are all correct?

[Jtsummers]

Not that you should ever write this in any language, but as an illustration:

  fn main() {
    let x: i32 = if true {1} else {"3"};
    println!("{}", x);
  }

This will not compile even though if it were allowed to execute it would, correctly, assign an integer to x. Python will happily interpret its equivalent:

  x = 1 if True else "3"
  print(x)

Even giving the if-expression an explicit `true` constant for the condition, Rust won't accept that as a valid program even though we can prove that the result of the expression is always 1.

[lisper]

> the compiler doesn't refuse to compile your code, it cannot compile your code

"Can not" and "will not" are kind of the same thing in this context. It's not like compilers have free will and just decide to give you a hard time. It's the language design that makes it (im)possible to run code that won't type-check.

[bpshaver]

Thanks for clarifying that compilers don't have free will. I was being facetious, sorry.

[steveklabnik]

Haskell has -fdefer-type-errors, which makes any type error fail at runtime.

This means you can only really rely on the parts of your program which are type correct, so...