Scripting languages are for writing scripts. Production code is much better served by typed languages.
Use a Ferrari on a racetrack, use a fortified tank on the battlefield.
Use a Ferrari on a racetrack, use a fortified tank on the battlefield.
The same with something like JIT vs compiling, I don't want to find out that some edge case a quadrillion loops in has some simple error a compiler could have found.
I’m a much faster developer in languages that are able to produce decent documentation about their typed interfaces, than I am in languages that are much more loosely defined.
There’s an amount of uncertainty in interpreted languages that always leaves me questioning the code—uncertain that it handles the cases I think it does.
If you had to write this as a feature in a maintainable way, that's when python would start to suck
All languages are typed in one way or another. Unless you write a generic function, you cannot evaluate (+ 2 "a") in scheme. Here is racket's error message:
> (+ 2 "a")
; +: contract violation
; expected: number?
; given: "a"
; argument position: 2nd
; [,bt for context]
>
If the code wasn't so obvious as the above example, you'd have a hard time mentally working out the correctness. E.g., given both (shoot camera person) and (shoot gun dummy), you'd not want to accidentally pass in the wrong arguments like (shoot gun person).