You absolutely do not need a computer telling you what types you can put in a collection. Put an assert, write some unit tests, if you aren’t sure where data sources come from and can’t write a one-line comment.
Dynamic typing makes you fast, it’s empowering. Try it and quit being so scared.
No matter how many unit tests or comments you write, it’s impossible to “prove” type correctness in a dynamically typed language - and it will eventually blow up in your face when you have to refactor. There’s a reason for the adage “testing can’t prove the absence of bugs.”
People like static typing because it offers strong guarantees and eliminates entire classes of bullshit bugs, not because they’re “weak minded.”
Incorrect. Static typing can prove many things, depending on the quality of the type system.
At the very least, it proves that your data is organized, stored, passed around and used in a logically valid and consistent manner. Make that proof impossible, and the compiler complains. (And with good reason - it doesn’t matter how good your program logic is if you’re feeding it bad data. Garbage in, garbage - or a runtime error - out.)
In a dynamically typed language, your program logic still implicitly depends on that proof holding - it’s just that you, the fallible human, has to make sure everything checks out. Python added type hints for precisely this reason.
Additionally, with more advanced static type systems, it becomes possible to issue guarantees beyond simple type safety. Patterns like typestate (found in TS, Haskell and Rust, off the top of my head) can be used to make illegal states unrepresentable at compile time. Try to write to a closed file or make an invalid state machine transition? The compiler will see it and say no.
It just creates bugs and crashes.
In what universe are runtime errors turned compile-time errors a source of bugs and crashes? A statically-typed program won’t blow up in production because some poor intern wasn’t able to keep the implicit type bounds of every single function parameter in his head.
There’s some math & CS papers you should read, Gödel’s incompleteness theorem, Turing’s halting problem. YOU CANNOT prove your way out of logic errors. You cannot make a universal type system. All you’re doing is wasting time with false confidence.
I agree, strong typing is for weak minds. I work with a weak mind so I want strong typing.
There’s no difference in speed between typing disciplines. In point of fact, there cannot be. You must know the structure of your data to program against it. Whether you write it down explicitly or implicitly changes nothing but the location you wrote it down.
All my career. They can’t program, they have no valid opinion about programming, as long as we finish the user stories. Which is several times faster in a nice dynamic language than a bondage language.
Strong typing is for weak minds.
You absolutely do not need a computer telling you what types you can put in a collection. Put an assert, write some unit tests, if you aren’t sure where data sources come from and can’t write a one-line comment.
Dynamic typing makes you fast, it’s empowering. Try it and quit being so scared.
No matter how many unit tests or comments you write, it’s impossible to “prove” type correctness in a dynamically typed language - and it will eventually blow up in your face when you have to refactor. There’s a reason for the adage “testing can’t prove the absence of bugs.”
People like static typing because it offers strong guarantees and eliminates entire classes of bullshit bugs, not because they’re “weak minded.”
Typing can’t prove anything, either. It just creates bugs and crashes.
Your program logic is the part that will not be fixed by it.
Incorrect. Static typing can prove many things, depending on the quality of the type system.
At the very least, it proves that your data is organized, stored, passed around and used in a logically valid and consistent manner. Make that proof impossible, and the compiler complains. (And with good reason - it doesn’t matter how good your program logic is if you’re feeding it bad data. Garbage in, garbage - or a runtime error - out.)
In a dynamically typed language, your program logic still implicitly depends on that proof holding - it’s just that you, the fallible human, has to make sure everything checks out. Python added type hints for precisely this reason.
Additionally, with more advanced static type systems, it becomes possible to issue guarantees beyond simple type safety. Patterns like typestate (found in TS, Haskell and Rust, off the top of my head) can be used to make illegal states unrepresentable at compile time. Try to write to a closed file or make an invalid state machine transition? The compiler will see it and say no.
In what universe are runtime errors turned compile-time errors a source of bugs and crashes? A statically-typed program won’t blow up in production because some poor intern wasn’t able to keep the implicit type bounds of every single function parameter in his head.
There’s some math & CS papers you should read, Gödel’s incompleteness theorem, Turing’s halting problem. YOU CANNOT prove your way out of logic errors. You cannot make a universal type system. All you’re doing is wasting time with false confidence.
I never said that static typing stops all logic errors or fully proves program correctness, but go off I guess…
I agree, strong typing is for weak minds. I work with a weak mind so I want strong typing.
There’s no difference in speed between typing disciplines. In point of fact, there cannot be. You must know the structure of your data to program against it. Whether you write it down explicitly or implicitly changes nothing but the location you wrote it down.
How is dynamic typinf faster? Is typing
num = 1instead ofint num = 1really that much faster?Plus, most statically typed languages either do type inference by default or let you opt in somehow.
Even Java, which is probably the reason everyone hated static typing for the first decade of the century or so, now has
var.Until you’re oboarded on a codebase that’s heavy on tech debt and that also doesn’t have proper documentation of the data being used.
Terrible projects are terrible because of the developers, not because of the language.
I find dynamic projects easier to refactor and fix, just write some tests and if it’s green bar before and after, you’re fine.
…did you ever work with business/product people?
All my career. They can’t program, they have no valid opinion about programming, as long as we finish the user stories. Which is several times faster in a nice dynamic language than a bondage language.