7 ms·

I feel this is just a myth. I'm constantly looking at the source even with static types. Unless you're having a Haskell-like type-system the function's signatu

I feel this is just a myth. I'm constantly looking at the source even with static types. Unless you're having a Haskell-like type-system the function's signature will still miss most of what the function is actually doing. How do I know if a function does a network call? Saves a file? Changes the DOM? These are really important things to know when calling code and the type-system is completely oblivious about them. What I usually see however is that projects using static types frequently have at least twice the team size as the equivalent projects using dynamic types. Communication overhead follows, ownership fades and debt creeps in quickly. After a few month they usually have no traces of agility left.

mschulze 10y ago
I agree (from my experience). That's mostly the fault that even with static types interface design (e.g. in Java: public methods and public classes) is still hard and most developers are not good at it. For me, a lot of the Spring classes are designed very well. When working with them I don't often need to look into the source code. Very often just looking at the methods (by using autocompletion) is enough.
tqkxzugoaupvwqr 10y ago
I think mschulze means he cannot even be sure what the function returns without having to read the source code. There could be comments but they may be outdated or incomplete. In statically typed languages you can look at the function signature or rely on the compiler errors.
- jeremiep 10y ago
  Yes but my point was that this is very incomplete information to do engineering with. You're still going to look at the source to learn what side-effects are present or how your arguments are used. Not taking these details into account will be the source of most bugs :)
  - trobertson 10y ago
    A good type system will expose the existence of side effects. However, it is true that good type systems are very rare in industry.
LeanderK 10y ago
maybe its just what your used to. Most of my time I code in Java (and a bit of Scala) and i only look at the source code as a last resort. This is not really possible with JS. But i imagine with a lot of background in dynamic languages you instinctively look at the source-code and therefore not use the types that much.
- jeremiep 10y ago
  I looked at SO much Java sources because the method signatures weren't complete enough. I would never have been able to integrate netty into our game servers that optimally with only the docs as reference for one. Yet its documentation is really, really good. I still wanted to know its internals in order to hit the fast paths. Whether you're using static or dynamic types, the very same holds true to build robust software: understand what you're doing. Managing complexity and reducing state will always be the biggest factors to quality, regardless or type systems.
  - mercurial 10y ago
    Well, considering the number of dependencies a typical web project has, I can tell that I'm far from understanding the internals of every library used in our codebase. I mean, of course you'll want to do that in some cases where performance is really important, but generally speaking type signatures and docs should be enough.
  - LeanderK 10y ago
    i din't say that i don't look at source code, but not intuitively. I look at it when the method is very confusing, or i have to optimise one path, it is undocumented and important etc. What i wanted to say is that types give you a pretty good first intuition to what the method does and how (including exceptions). They help me navigate my way through the code, especially with DSL like the excellent jooq (http://www.jooq.org http://www.jooq.org)
- qwertyuiop924 10y ago
  ...And I hate java (for perverting OO, and being annoyongly verbose), and come from a highly dynamic background. It's ultimately a matter of preference, though.
spion 10y ago
> How do I know if a function does a network call? Saves a file? It returns Promise<T> > Changes the DOM? It doesn't. React does that. ;) Basically, TypeScript + React + a mostly purely functional style with a sprinkle of side-effecting IO is a really, really good combination. Also, I find the argument a bit silly. "This cycling helmet doesn't protect your knees and elbows and spine, so its completely useless and you can remove it!"
- leshow 10y ago
  React is not "functional". You extend the Component type just to make a view, you can encapsulate local state, you can inherit functions, yadda yadda. Calling it a "component" doesnt make it any less OO
  - spion 10y ago
    In terms of DOM manipulation, yes it is. The render function is pure.
    - leshow 10y ago
      No, you can choose to write it purely, but it's not pure by default. You can see that here: https://facebook.github.io/react/docs/pure-render-mixin.html https://facebook.github.io/react/docs/pure-render-mixin.html "IF your React component's render function is "pure"" nothing stops you from writing impure rendering functions. You can delete and manipulate elements at will.
      - spion 10y ago
        Yes, but thats not how the render function is supposed to work. Its a function from state/props to a VDOM tree. In contrast, direct DOM manipulation is meant to be stateful. For some reason, everyone always likes dealing with absolutes. Thats not how things work * "Tests wont exhaustively check everything!" Yes but they exercise the common cases, and the cases where the code will trip-up in real use are rare if the code is decently covered with tests. Yes, its still possible to encounter edge cases. If it looks like that might be the case, add fuzz testing and property testing too. Pick the tool. * "Types wont detect all errors!" - Yes but detecting some errors is still useful. They mostly track dependencies between parts of the codebase: they determine how modules talk to eachother. This is useful, especially when I'm reorganizing code. Also, its exactly where unit test fail to help, due to mocks: if I change module M, i don't know whether its dependencies are affected or not without looking at all of them and checking their mocks of module M. The situation gets even worse for second-level dependencies, and so on. * "Unsound type systems are useless!" - No they are not. Not if its possible to isolate unsound usage and "hand-prove" it by carefully checking it. There is still value there: you can write things that the type system doesn't know are sound and hand-check them (by paying with more effort), or you can write things that it does know are sound, and enjoy the type system's ability to help you avoid errors. * "Soundness isn't very important" - It depends. Is this unsoundness pervasive, like the null/undefined unsoundness? Maybe its useful to fix it then. There are no absolutes.

mschulze 10y ago

I agree (from my experience). That's mostly the fault that even with static types interface design (e.g. in Java: public methods and public classes) is still hard and most developers are not good at it. For me, a lot of the Spring classes are designed very well. When working with them I don't often need to look into the source code. Very often just looking at the methods (by using autocompletion) is enough.

tqkxzugoaupvwqr 10y ago

I think mschulze means he cannot even be sure what the function returns without having to read the source code. There could be comments but they may be outdated or incomplete. In statically typed languages you can look at the function signature or rely on the compiler errors.

jeremiep 10y ago
Yes but my point was that this is very incomplete information to do engineering with. You're still going to look at the source to learn what side-effects are present or how your arguments are used. Not taking these details into account will be the source of most bugs :)
- trobertson 10y ago
  A good type system will expose the existence of side effects. However, it is true that good type systems are very rare in industry.

LeanderK 10y ago

maybe its just what your used to. Most of my time I code in Java (and a bit of Scala) and i only look at the source code as a last resort. This is not really possible with JS. But i imagine with a lot of background in dynamic languages you instinctively look at the source-code and therefore not use the types that much.

jeremiep 10y ago
I looked at SO much Java sources because the method signatures weren't complete enough. I would never have been able to integrate netty into our game servers that optimally with only the docs as reference for one. Yet its documentation is really, really good. I still wanted to know its internals in order to hit the fast paths. Whether you're using static or dynamic types, the very same holds true to build robust software: understand what you're doing. Managing complexity and reducing state will always be the biggest factors to quality, regardless or type systems.
- mercurial 10y ago
  Well, considering the number of dependencies a typical web project has, I can tell that I'm far from understanding the internals of every library used in our codebase. I mean, of course you'll want to do that in some cases where performance is really important, but generally speaking type signatures and docs should be enough.
- LeanderK 10y ago
  i din't say that i don't look at source code, but not intuitively. I look at it when the method is very confusing, or i have to optimise one path, it is undocumented and important etc. What i wanted to say is that types give you a pretty good first intuition to what the method does and how (including exceptions). They help me navigate my way through the code, especially with DSL like the excellent jooq (http://www.jooq.org http://www.jooq.org)
qwertyuiop924 10y ago
...And I hate java (for perverting OO, and being annoyongly verbose), and come from a highly dynamic background. It's ultimately a matter of preference, though.

spion 10y ago

> How do I know if a function does a network call? Saves a file? It returns Promise<T> > Changes the DOM? It doesn't. React does that. ;) Basically, TypeScript + React + a mostly purely functional style with a sprinkle of side-effecting IO is a really, really good combination. Also, I find the argument a bit silly. "This cycling helmet doesn't protect your knees and elbows and spine, so its completely useless and you can remove it!"

leshow 10y ago
React is not "functional". You extend the Component type just to make a view, you can encapsulate local state, you can inherit functions, yadda yadda. Calling it a "component" doesnt make it any less OO
- spion 10y ago
  In terms of DOM manipulation, yes it is. The render function is pure.
  - leshow 10y ago
    No, you can choose to write it purely, but it's not pure by default. You can see that here: https://facebook.github.io/react/docs/pure-render-mixin.html https://facebook.github.io/react/docs/pure-render-mixin.html "IF your React component's render function is "pure"" nothing stops you from writing impure rendering functions. You can delete and manipulate elements at will.
    - spion 10y ago
      Yes, but thats not how the render function is supposed to work. Its a function from state/props to a VDOM tree. In contrast, direct DOM manipulation is meant to be stateful. For some reason, everyone always likes dealing with absolutes. Thats not how things work * "Tests wont exhaustively check everything!" Yes but they exercise the common cases, and the cases where the code will trip-up in real use are rare if the code is decently covered with tests. Yes, its still possible to encounter edge cases. If it looks like that might be the case, add fuzz testing and property testing too. Pick the tool. * "Types wont detect all errors!" - Yes but detecting some errors is still useful. They mostly track dependencies between parts of the codebase: they determine how modules talk to eachother. This is useful, especially when I'm reorganizing code. Also, its exactly where unit test fail to help, due to mocks: if I change module M, i don't know whether its dependencies are affected or not without looking at all of them and checking their mocks of module M. The situation gets even worse for second-level dependencies, and so on. * "Unsound type systems are useless!" - No they are not. Not if its possible to isolate unsound usage and "hand-prove" it by carefully checking it. There is still value there: you can write things that the type system doesn't know are sound and hand-check them (by paying with more effort), or you can write things that it does know are sound, and enjoy the type system's ability to help you avoid errors. * "Soundness isn't very important" - It depends. Is this unsoundness pervasive, like the null/undefined unsoundness? Maybe its useful to fix it then. There are no absolutes.