5 ms·

I'm not a very good developer, though I do have plenty of released-and-working-well things out in the world. I will say, it seems to me like static typing would

I'm not a very good developer, though I do have plenty of released-and-working-well things out in the world. I will say, it seems to me like static typing would reduce my creativity and flow and require me to spend more time planning stuff, which is not fun, and would make updates take more time as I patch stuff in all over the codebase. It's sort of the polar opposite of Ruby-style "duck typing". Do they really help enough to be worth it?

dunefox 8y ago
Well, I remember times when my program crashed because I tried to add a dictionary and an integer - so, yeah, they do help.
- dictum 8y ago
  The problem lies on enough: the overhead of static typing has to be lower, in the lifespan of a project, to the time spent fixing bugs like this one. (Other things, like liability from bugs and crashes, may give an edge to static typing. The age-old debate is how much)
  - mannykannot 8y ago
    If you know what sorts of data your variables denote and your functions take and return, being explicit about it is not much of a burden for the benefits it brings.
SatvikBeri 8y ago
I regularly work in a statically typed language (Scala) and a dynamic/gradually typed language (Python.) I never find that static types force me to plan more – it's pretty easy to change them on the fly. I frequently find that static types let the IDE highlight an error the second I write it, instead of waiting until running tests. And every codebase I've worked with has taken at least a few minutes to run tests (and sometimes much longer), so this is a pretty substantial savings. Or in other words, static types free me up to be more creative, by requiring me to spend less energy & attention on certain types of errors that were common before.
- cm2187 8y ago
  In fact with the right IDE, static typing makes refactoring much easier. Right click on a parameter, rename, and it will rename anywhere where it is relevant (as opposed to a replace all).
  - SatvikBeri 8y ago
    To be fair, you can do that with dynamically typed Python and a good IDE too. I've used PyCharm on Python 2.7 for years and never really had any issues with refactoring.
hectormalot 8y ago
I’ve been programming in Ruby for years (as a hobby / small passive income project), and about a year ago decided to reimplement a small part of it in Go. Both for learning and because it was a bottleneck in the application. Recently I needed to fix some things in the original Ruby code, and it felt like freeclimbing after getting used to ropes... I called a function and started wondering how I could have any guarantees that it returned something useful. Benefits of static typing really ‘clicked’ for me at that moment. I still love ruby though
mannykannot 8y ago
You could probably become a better developer if you did more thinking ahead (or 'planning', as you put it.) If you are writing a bunch of variables, and you don't have a good idea of precisely what data they hold, there is very little chance that your program will work properly first time (not that thinking ahead guarantees it, of course, but it improves your odds.) For every programmer, there comes a point where you cannot effectively track how everything needs to fit together to work, unless you are doing some sort of planning. Duck typing only works when it works, which is not as trivial a statement as it might first seem.
- core-questions 8y ago
  Respectfully, do I care if my program works the first time, or by the deadline? I don't care if the first ten times I run it, it just bombs out with interpreter errors. Doesn't seem to result in my having slower output than anyone else I'm working with.
  - ecnahc515 8y ago
    If you truly knew what you were doing when you started, then everything would work the first time you tried it. Since that's not the case, you're clearly making mistakes, so why wait until running it to find mistakes when you could find them before even running the program? Think of it this way: you only ran it 10 times, are you sure you found all the bugs? What about 11 times? Are you sure you found all the problems? Numerically speaking, if the first 9 attempts didn't work, then 90% of the time you ran it after coding, it was still broken. The fact that the program was broken a majority of the time you developed it should make you skeptical if it's even "correct' after you've determined it to be "finished". I understand you picked random examples, but this is still relevant. It seems to me like you're arguing a common argument about picking tools which is "I've always done it this way, and it works for me, so why look for anything better?"
    - adrianhel 8y ago
      I agree with the sentiment, but types don't guarantee correctness. I would put such a developer on "TDD-duty", be thorough about code reviews and do some pair programming.
Zarel 8y ago
I'm actually kind of surprised that programmers, of all people, would oppose guard-rails. At university, it was a meme that no one's C program ever compiled the first time they tried. I can't imagine even the best programmer in the world can avoid that kind of problem, without static analysis and static typing. Maybe you can have a 90% success rate on short programs, I'd believe that (my first-compile success rate on AoC was closer to 50%, and I was like #30 or so on the leaderboard [1]). But to do it perfectly, in real-world code? That I don't believe. The nice thing about static typing is about catching mistakes earlier, and making it easier to figure out what your mistake was. Without the type annotation on the function, when you get a crash a few days later, it's harder to figure out "is the function wrong, or is the code calling the function wrong?" With it, those questions are automatically answered. The best I've heard is that for short scripts, static typing doesn't help _enough_ to be worth the extra time it takes. But with modern type inference, it takes very little extra time at all. And the extra time it does take, to write out interfaces and stuff, you can avoid in TypeScript with type assertions and `any` assertions. But honestly, it's usually worth it: It's not like you _don't_ plan out the interface; you just used to keep them memorized instead of writing them down, and then regret it a few weeks later when you want to make a change. [1] To be fair, it was 50% because I was optimizing for programming speed for the leaderboard rather than accuracy; I'm sure I could have gotten closer to 90% if I were optimizing for accuracy. But anyone who argues that avoiding static types saves time has to accept that you make a lot more mistakes if you're trying to save time.
- _bxg1 8y ago
  > it was a meme that no one's C program ever compiled the first time they tried Ah but see, the compiler is a guard-rail. Technically, it's a static-analyzer. I don't think anyone is against making existing guard rails more helpful via editor integration; the conflict comes with adding new guard rails. Take the following example: let foo = { bar0: 12, bar1: 14, bar2: 16 } // example 1 console.log(foo.bar0); console.log(foo.bar1); console.log(foo.bar2); // example 2 for(let i = 0; i < 3; i++) { console.log(foo['bar' + i]) } Example 1 can be statically verified by a JavaScript type checker. Example 2 can't. There are advantages of being able to do the second thing - more code reuse, possibly less refactoring needed. But it's impossible to verify that those properties exist on that object without running the code. The argument is that oftentimes, the type checking is more valuable than the loss of "creative" freedom. But it does mean limiting the kinds of things you can do.

dunefox 8y ago

Well, I remember times when my program crashed because I tried to add a dictionary and an integer - so, yeah, they do help.

dictum 8y ago
The problem lies on enough: the overhead of static typing has to be lower, in the lifespan of a project, to the time spent fixing bugs like this one. (Other things, like liability from bugs and crashes, may give an edge to static typing. The age-old debate is how much)
- mannykannot 8y ago
  If you know what sorts of data your variables denote and your functions take and return, being explicit about it is not much of a burden for the benefits it brings.

SatvikBeri 8y ago

I regularly work in a statically typed language (Scala) and a dynamic/gradually typed language (Python.) I never find that static types force me to plan more – it's pretty easy to change them on the fly. I frequently find that static types let the IDE highlight an error the second I write it, instead of waiting until running tests. And every codebase I've worked with has taken at least a few minutes to run tests (and sometimes much longer), so this is a pretty substantial savings. Or in other words, static types free me up to be more creative, by requiring me to spend less energy & attention on certain types of errors that were common before.

cm2187 8y ago
In fact with the right IDE, static typing makes refactoring much easier. Right click on a parameter, rename, and it will rename anywhere where it is relevant (as opposed to a replace all).
- SatvikBeri 8y ago
  To be fair, you can do that with dynamically typed Python and a good IDE too. I've used PyCharm on Python 2.7 for years and never really had any issues with refactoring.

hectormalot 8y ago

I’ve been programming in Ruby for years (as a hobby / small passive income project), and about a year ago decided to reimplement a small part of it in Go. Both for learning and because it was a bottleneck in the application. Recently I needed to fix some things in the original Ruby code, and it felt like freeclimbing after getting used to ropes... I called a function and started wondering how I could have any guarantees that it returned something useful. Benefits of static typing really ‘clicked’ for me at that moment. I still love ruby though

mannykannot 8y ago

You could probably become a better developer if you did more thinking ahead (or 'planning', as you put it.) If you are writing a bunch of variables, and you don't have a good idea of precisely what data they hold, there is very little chance that your program will work properly first time (not that thinking ahead guarantees it, of course, but it improves your odds.) For every programmer, there comes a point where you cannot effectively track how everything needs to fit together to work, unless you are doing some sort of planning. Duck typing only works when it works, which is not as trivial a statement as it might first seem.

core-questions 8y ago
Respectfully, do I care if my program works the first time, or by the deadline? I don't care if the first ten times I run it, it just bombs out with interpreter errors. Doesn't seem to result in my having slower output than anyone else I'm working with.
- ecnahc515 8y ago
  If you truly knew what you were doing when you started, then everything would work the first time you tried it. Since that's not the case, you're clearly making mistakes, so why wait until running it to find mistakes when you could find them before even running the program? Think of it this way: you only ran it 10 times, are you sure you found all the bugs? What about 11 times? Are you sure you found all the problems? Numerically speaking, if the first 9 attempts didn't work, then 90% of the time you ran it after coding, it was still broken. The fact that the program was broken a majority of the time you developed it should make you skeptical if it's even "correct' after you've determined it to be "finished". I understand you picked random examples, but this is still relevant. It seems to me like you're arguing a common argument about picking tools which is "I've always done it this way, and it works for me, so why look for anything better?"
  - adrianhel 8y ago
    I agree with the sentiment, but types don't guarantee correctness. I would put such a developer on "TDD-duty", be thorough about code reviews and do some pair programming.

Zarel 8y ago

I'm actually kind of surprised that programmers, of all people, would oppose guard-rails. At university, it was a meme that no one's C program ever compiled the first time they tried. I can't imagine even the best programmer in the world can avoid that kind of problem, without static analysis and static typing. Maybe you can have a 90% success rate on short programs, I'd believe that (my first-compile success rate on AoC was closer to 50%, and I was like #30 or so on the leaderboard [1]). But to do it perfectly, in real-world code? That I don't believe. The nice thing about static typing is about catching mistakes earlier, and making it easier to figure out what your mistake was. Without the type annotation on the function, when you get a crash a few days later, it's harder to figure out "is the function wrong, or is the code calling the function wrong?" With it, those questions are automatically answered. The best I've heard is that for short scripts, static typing doesn't help _enough_ to be worth the extra time it takes. But with modern type inference, it takes very little extra time at all. And the extra time it does take, to write out interfaces and stuff, you can avoid in TypeScript with type assertions and `any` assertions. But honestly, it's usually worth it: It's not like you _don't_ plan out the interface; you just used to keep them memorized instead of writing them down, and then regret it a few weeks later when you want to make a change. [1] To be fair, it was 50% because I was optimizing for programming speed for the leaderboard rather than accuracy; I'm sure I could have gotten closer to 90% if I were optimizing for accuracy. But anyone who argues that avoiding static types saves time has to accept that you make a lot more mistakes if you're trying to save time.

_bxg1 8y ago
> it was a meme that no one's C program ever compiled the first time they tried Ah but see, the compiler is a guard-rail. Technically, it's a static-analyzer. I don't think anyone is against making existing guard rails more helpful via editor integration; the conflict comes with adding new guard rails. Take the following example: let foo = { bar0: 12, bar1: 14, bar2: 16 } // example 1 console.log(foo.bar0); console.log(foo.bar1); console.log(foo.bar2); // example 2 for(let i = 0; i < 3; i++) { console.log(foo['bar' + i]) } Example 1 can be statically verified by a JavaScript type checker. Example 2 can't. There are advantages of being able to do the second thing - more code reuse, possibly less refactoring needed. But it's impossible to verify that those properties exist on that object without running the code. The argument is that oftentimes, the type checking is more valuable than the loss of "creative" freedom. But it does mean limiting the kinds of things you can do.