4 ms·

I actually find strong typing speeds up green-field development rather than hampering it, because it cuts down on the little avoidable things that inevitably cr

I actually find strong typing speeds up green-field development rather than hampering it, because it cuts down on the little avoidable things that inevitably creep in when you're trying to architect and evaluate and code all at the same time. The kinds of things that make you smack yourself in the face for an hour wasted by the most trivial mistakes. In addition to my own personal experience this has been incredibly well illustrated to me because I'm overseeing two junior JS devs right now where one starts any new code with "any" types and tries to make Flow happy later and the other starts with real types. The former has a LOT more "this isn't working and I have no idea why, help" moments.

reificator 8y ago
> I actually find strong typing speeds up green-field development rather than hampering it, because it cuts down on the little avoidable things that inevitably creep in when you're trying to architect and evaluate and code all at the same time. The kinds of things that make you smack yourself in the face for an hour wasted by the most trivial mistakes. I want to agree with you on this statement, but I don't think your anecdote supports it. > In addition to my own personal experience this has been incredibly well illustrated to me because I'm overseeing two junior JS devs right now where one starts any new code with "any" types and tries to make Flow happy later and the other starts with real types. The former has a LOT more "this isn't working and I have no idea why, help" moments. To me it just sounds like the second junior has a stronger understanding of the language/type system. Some people come into junior positions because they've learned enough to pass a CS course. Some come into junior positions because they've spent their whole life programming in some way or another and want to get some professional experience on their resume. (And everything inbetween of course) Now, trying to push the Any dev toward specifying types upfront and watching the results might give you better evidence, and better performance to boot.
tsimionescu 8y ago
I don't have a problem with strong types, I agree with you. Dynamic types are usually too much hassle even for prototypes. I was talking more about stuff like Rust's borrow checker or dependent type systems.

reificator 8y ago

> I actually find strong typing speeds up green-field development rather than hampering it, because it cuts down on the little avoidable things that inevitably creep in when you're trying to architect and evaluate and code all at the same time. The kinds of things that make you smack yourself in the face for an hour wasted by the most trivial mistakes. I want to agree with you on this statement, but I don't think your anecdote supports it. > In addition to my own personal experience this has been incredibly well illustrated to me because I'm overseeing two junior JS devs right now where one starts any new code with "any" types and tries to make Flow happy later and the other starts with real types. The former has a LOT more "this isn't working and I have no idea why, help" moments. To me it just sounds like the second junior has a stronger understanding of the language/type system. Some people come into junior positions because they've learned enough to pass a CS course. Some come into junior positions because they've spent their whole life programming in some way or another and want to get some professional experience on their resume. (And everything inbetween of course) Now, trying to push the Any dev toward specifying types upfront and watching the results might give you better evidence, and better performance to boot.

tsimionescu 8y ago

I don't have a problem with strong types, I agree with you. Dynamic types are usually too much hassle even for prototypes. I was talking more about stuff like Rust's borrow checker or dependent type systems.