4 ms·

You can do them, as you noted, at a much slower pace. Type systems catch one class of bugs, and if in your experience these are not the bugs you worry about or

by evgen 10y ago

You can do them, as you noted, at a much slower pace. Type systems catch one class of bugs, and if in your experience these are not the bugs you worry about or the bugs that cause you the most pain then slowing down development is a high cost to pay.

winter_blue 10y ago
It goes beyond just catching bugs. Large code bases written in statically typed languages are easier to understand. I've worked on large production codebases in the past, for servers written in both Java (at company [a]), and JavaScript with Node.js (at company [b]). The Java codebase was much easier to read, understand, navigate around, and debug. If a function took an argument "SomeClass foo" I could look up "SomeClass" and know exactly what it was. In the Node codebase, if have argument "foo", you're lost with no easy way to figure out exactly what this "foo" is. You would have to run the code, set a breakpoint, and inspect "foo". In addition, JavaScript encouraged a lot of bad coding practices that almost made me want to cry. In the Java server, we used a JSON library where you would annotate a class, and the library would construct an object for that class. This guaranteed the JSON was well-formed, among other things. In the Node.js codebase, people would pull something out of Mongo, chuck it in a variable "data", and then do "data.foo.bar[1].qux". (Yes, the "[1]" is real.) It was terrible. The company that used Node.js had far less reliable code overall, and their services (written in JavaScript) would crash frequently, most commonly due to type errors. And this is just a tip of the iceberg. There were so many problems that attributable to the choice of JavaScript as the language for a large, complex back-end system, and the failure to use any tool for type checking (like Flow), in addition to bad coding practices. [a] Amplify Education, Inc. https://www.amplify.com/ https://www.amplify.com/ [b] Lifion, a division of ADP. http://www.lifion.com/ http://www.lifion.com/
- qwertyuiop924 10y ago
  That's an example of bad design. You can do that in Java as well, just in different ways. There are trade-offs that you make, and it means that various languages and type systems make different kinds of screw-ups easier.
overgard 10y ago
Honestly I think the bug catching aspect of static typing is its least useful property. (Useful, but not like, amazing -- you can write assertions on a type in a dynamic language). I think the good thing about static typing is it makes a code-base much easier to navigate and much more self documenting. I spend most my time navigating other peoples code. I know you can get most of the reliability of static typing with extensive test suites etc., but that doesn't help my IDE and it doesn't let me look up parameters at a glance. I used to be firmly in the dynamic camp, but having to maintain other people's javascript definitely made me do a 180.
- eyelidlessness 10y ago
  > you can write assertions on a type in a dynamic language You can, but you can't get any guarantee that said assertion will never fail.
- Bahamut 10y ago
  Writing assertions has a runtime cost that isn't present when using something like TypeScript. Granted, that benefit is probably minor, but it is a benefit in TypeScript's favor.
  - mbrock 10y ago
    It does have a compile time cost and that's not negligible... although with all the heavy transpilation going on these days, a bit of type checking might drown that out. At a previous job we tried TypeScript but it took around 20 seconds to build our front end. Since then I hear speed has improved.
saosebastiao 10y ago
Maybe the initial write is faster, but any refactoring strongly favors static type systems in the speed department. Even an extremely well tested dynamic code base will have a significant disadvantage for refactoring because the tools can't catch all the small details and you'll have to iterate over and over again until tests pass.

by evgen 10y ago

winter_blue 10y ago

It goes beyond just catching bugs. Large code bases written in statically typed languages are easier to understand. I've worked on large production codebases in the past, for servers written in both Java (at company [a]), and JavaScript with Node.js (at company [b]). The Java codebase was much easier to read, understand, navigate around, and debug. If a function took an argument "SomeClass foo" I could look up "SomeClass" and know exactly what it was. In the Node codebase, if have argument "foo", you're lost with no easy way to figure out exactly what this "foo" is. You would have to run the code, set a breakpoint, and inspect "foo". In addition, JavaScript encouraged a lot of bad coding practices that almost made me want to cry. In the Java server, we used a JSON library where you would annotate a class, and the library would construct an object for that class. This guaranteed the JSON was well-formed, among other things. In the Node.js codebase, people would pull something out of Mongo, chuck it in a variable "data", and then do "data.foo.bar[1].qux". (Yes, the "[1]" is real.) It was terrible. The company that used Node.js had far less reliable code overall, and their services (written in JavaScript) would crash frequently, most commonly due to type errors. And this is just a tip of the iceberg. There were so many problems that attributable to the choice of JavaScript as the language for a large, complex back-end system, and the failure to use any tool for type checking (like Flow), in addition to bad coding practices. [a] Amplify Education, Inc. https://www.amplify.com/ https://www.amplify.com/ [b] Lifion, a division of ADP. http://www.lifion.com/ http://www.lifion.com/

qwertyuiop924 10y ago
That's an example of bad design. You can do that in Java as well, just in different ways. There are trade-offs that you make, and it means that various languages and type systems make different kinds of screw-ups easier.

overgard 10y ago

Honestly I think the bug catching aspect of static typing is its least useful property. (Useful, but not like, amazing -- you can write assertions on a type in a dynamic language). I think the good thing about static typing is it makes a code-base much easier to navigate and much more self documenting. I spend most my time navigating other peoples code. I know you can get most of the reliability of static typing with extensive test suites etc., but that doesn't help my IDE and it doesn't let me look up parameters at a glance. I used to be firmly in the dynamic camp, but having to maintain other people's javascript definitely made me do a 180.

eyelidlessness 10y ago
> you can write assertions on a type in a dynamic language You can, but you can't get any guarantee that said assertion will never fail.
Bahamut 10y ago
Writing assertions has a runtime cost that isn't present when using something like TypeScript. Granted, that benefit is probably minor, but it is a benefit in TypeScript's favor.
- mbrock 10y ago
  It does have a compile time cost and that's not negligible... although with all the heavy transpilation going on these days, a bit of type checking might drown that out. At a previous job we tried TypeScript but it took around 20 seconds to build our front end. Since then I hear speed has improved.

saosebastiao 10y ago

Maybe the initial write is faster, but any refactoring strongly favors static type systems in the speed department. Even an extremely well tested dynamic code base will have a significant disadvantage for refactoring because the tools can't catch all the small details and you'll have to iterate over and over again until tests pass.