3 ms·
> 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 fir
by lisper 1y ago
> 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.
- bpshaver 1y agoWhat 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 1y agoNot 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 1y ago> 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 1y agoThanks for clarifying that compilers don't have free will. I was being facetious, sorry.
- steveklabnik 1y agoHaskell 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...
- static_void 1y agoIn 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 1y agoI'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 1y agoNo, 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 1y ago> 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 1y agoIf 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.