3 ms·

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 th

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.

deleted 7y ago
[deleted]
bArray 7y ago
I'd go one step further, I would accept the existence of both typed and non-typed "runtime" versions of Python (i.e. a run-time flag or program argument). Writing a quick script? Reach for the non-typed version. Writing production software? We ought to make sure we're type checking. Default to non-typed to stop beginners breaking their code. 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.
- L0stLink 7y ago
  mypy can be used to achieve the same effect, but I would also like the ability to enforce types at run-time, and it would be great if more tools made use of PEP 484.
bluejekyll 7y ago
I’m not sure what your analogy is getting at. Many typed languages are compiled. A lot of them are faster than interpreted languages—also, because they are typed, they could be referred to as fortified.
- saghm 7y ago
  I think the speed of the Ferrari in this case is referring to the speed of development in a scripting language (not the speed of programs written in the language), and the protection of a tank is referring to the protection from certain classes of errors that static typing gives.
  - bluejekyll 7y ago
    Ah I see. Though that in itself seems to be a matter of opinion/comfort with a language. 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.
    - silentsea90 7y ago
      Yup! I think you may be referring to a more production like usecase here. If you had to parse a csv to convert a column from Fahrenheit to Celsius and output that with the first column in a separate csv (dummy example) - python is so much faster to develop. If you had to write this as a feature in a maintainable way, that's when python would start to suck
tpfour 7y ago
No. 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] > The function absolutely expects its arguments to have a certain shape (type). The difference with C is that variables don't have types set in stone, they can... vary. The compiler/interpreter just takes care of them for you.
- chii 7y ago
  But you cannot tell ahead of time that you cannot evaluate (+ 2 "a"). 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).

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.

deleted 7y ago

[deleted]

bArray 7y ago

I'd go one step further, I would accept the existence of both typed and non-typed "runtime" versions of Python (i.e. a run-time flag or program argument). Writing a quick script? Reach for the non-typed version. Writing production software? We ought to make sure we're type checking. Default to non-typed to stop beginners breaking their code. 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.

L0stLink 7y ago
mypy can be used to achieve the same effect, but I would also like the ability to enforce types at run-time, and it would be great if more tools made use of PEP 484.

bluejekyll 7y ago

I’m not sure what your analogy is getting at. Many typed languages are compiled. A lot of them are faster than interpreted languages—also, because they are typed, they could be referred to as fortified.

saghm 7y ago
I think the speed of the Ferrari in this case is referring to the speed of development in a scripting language (not the speed of programs written in the language), and the protection of a tank is referring to the protection from certain classes of errors that static typing gives.
- bluejekyll 7y ago
  Ah I see. Though that in itself seems to be a matter of opinion/comfort with a language. 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.
  - silentsea90 7y ago
    Yup! I think you may be referring to a more production like usecase here. If you had to parse a csv to convert a column from Fahrenheit to Celsius and output that with the first column in a separate csv (dummy example) - python is so much faster to develop. If you had to write this as a feature in a maintainable way, that's when python would start to suck

tpfour 7y ago

No. 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] > The function absolutely expects its arguments to have a certain shape (type). The difference with C is that variables don't have types set in stone, they can... vary. The compiler/interpreter just takes care of them for you.

chii 7y ago
But you cannot tell ahead of time that you cannot evaluate (+ 2 "a"). 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).