7 ms·

My experience: I don't get how in a project with several developers and maybe even teams dynamic types work at all. If a colleague writes a function/method tha

My experience: I don't get how in a project with several developers and maybe even teams dynamic types work at all. If a colleague writes a function/method that returns something, in JS, how do I know what it is? I have to read the function or its tests. With a statically typed language I immediately know the structure of the returned "thing" (don't want to say object) and can infer how to work on it.

jshen 10y ago
I've worked on a lot of big projects with both dynamic and static languages. I think what a lot of people that are used to static languages don't realize is that dynamic langauge users typically live inside of some kind of repl. The repl gives you immediate access to the thing returned and lets you inspect it and play with it. This serves the same purpose, albeit in a different way, as the IDE for a langauge like java or c#.
- mschulze 10y ago
  That's a good explanation, thank you. My experience in big projects with dynamic languages boils down to Angular which I didn't find very REPL friendly. BTW, with IntelliJ and its debug mode for Java we almost have some sort of weird REPL. By pressing Alt+F8 one can, during a breakpoint evaluate an arbitrary Java expression while accessing the values in scope. I use it a lot, despite having my types.
  - jshen 10y ago
    I use that in Intellij all the time, but it's very limited to something like pry in ruby.
  - qwertyuiop924 10y ago
    Angular was a Bad Idea. For so many reasons. I'm barely acquainted with it, but I could already go on about all the problems I had, which other, more experienced people also had. And I do a lot of Lisp programming in Emacs, where the support for REPLs and livecoding is ungodly. Really, really good.
  - Roboprog 10y ago
    Install Batarang in Chrome. the "$scope" objects are attached to the browser DOM, and the tool adds another tab to element inspection that shows you the data attached to each level, as well as references back up to enclosing levels.
jeremiep 10y ago
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.
BinaryIdiot 10y ago
> If a colleague writes a function/method that returns something, in JS, how do I know what it is? Typically you have a set of standards for how things get returned. 'isSomething()' returns boolean, 'getSomething()' returns an object, 'getSomethingClassName()' gets a model representing that, etc. Overall it's really the same as static: you usually have something in the function definition that makes it intuitive what it returns. The fallback is documentation directly above the function's implementation that should describe it. When you run into the "well what does the object contain that gets returned?" situation then dynamic and static have the same issue: you have to go to the definition to get that information.
- Roboprog 10y ago
  Free your mind. Drop all that getXXX setXXX Java-esque noise. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/set https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... http://es6-features.org/#Proxying http://es6-features.org/#Proxying Otherwise, yeah, I can hardly make heads or tails of most "self documenting" (i.e. - undocumented, per SOP) static typed code.
  - BinaryIdiot 10y ago
    > Free your mind. Drop all that getXXX setXXX Java-esque noise[...] You confuse my statement. I was not referring to things that should be meant as synchronous properties. These are methods that do more like make an AJAX call to a server. Those that return promises or take in callbacks would be awkward or impossible to force into a property or proxy. I was merely referring to the act of making code as obvious as possible for its intended outcome.
    - Roboprog 10y ago
      Gotcha. Sorry about the tangent, as you were primarily discussing grokking what the names of things were doing anyway.
shados 10y ago
Unless you're working with a strict sound type system, you only have a little more information: you know the properties and methods of what is returned, but you don't know what state its in. So you won't typo a method name, but you still might be dealing with errors from shit that cost cast incorrectly, nulls (even with strict null, since it wasn't there from the start you will still deal with it), arrays not containing what you thought they did, etc. Anything but the most trivial program will still require you to investigate. Once you're familiar with a piece of code you can start making assumptions, and the types get you a little closer to that a little faster. I've worked on multi million line mono-repo pure javascript with zero tests with hundreds of devs working on it, and it worked fine (in fact, we were moving more stuff from the Java/C# code into JavaScript to reduce overhead and friction). If you have tests on top, or if your devs are actually good, its just easier/better. Now, I'm not saying a proper type system doesn't add value. Thats a whole different argument. But any team who can build good software in a static type language can do so in a dynamic one. Its just a different set of tradeoffs. And aside for strict sound type systems, you need (almost) t he exact same amount of unit tests either way. If you don't have tests you're not writing good software either way.
- mercurial 10y ago
  > Unless you're working with a strict sound type system, you only have a little more information: you know the properties and methods of what is returned, but you don't know what state its in. So you won't typo a method name, but you still might be dealing with errors from shit that cost cast incorrectly, nulls (even with strict null, since it wasn't there from the start you will still deal with it), arrays not containing what you thought they did, etc. You're throwing out (or, rather considering the tricks you can pull in Typescript, hugely reducing) entire classes of issues when using a simple type system. > I've worked on multi million line mono-repo pure javascript with zero tests with hundreds of devs working on it, and it worked fine (in fact, we were moving more stuff from the Java/C# code into JavaScript to reduce overhead and friction). If you have tests on top, or if your devs are actually good, its just easier/better. I've worked on a huge PHP codebase once, with 10 developers working on it and no tests. I would have given somebody else's right hand to have a type system back then. > Now, I'm not saying a proper type system doesn't add value. Thats a whole different argument. But any team who can build good software in a static type language can do so in a dynamic one. Its just a different set of tradeoffs. The point is, the cost of adopting Typescript is frankly, very low, from my point of view, considering the huge benefits it has over raw JS, it's all win.
westoncb 10y ago
I completely agree. Learning new code without types is way slower for me. Example: you have a function that takes a 'file' parameter, and you need to modify the function, so you need to know what the properties on the file object are. Is it some custom File class, or just a poor name choice, or the browser File interface? In a statically typed language it would be marked explicitly and I could probably just CMD+click on it in my IDE and be done. In, e.g., javascript what recourse do I have? No 'File' module is explicitly imported, and the function is invoked somewhere in library code so I never see the file object constructed. So, let's say it turns out to be this 'File': https://developer.mozilla.org/en-US/docs/Web/API/File https://developer.mozilla.org/en-US/docs/Web/API/File —how do I discover this? So far it's been time-wasting, unsystematic trial-and-error sorts of things. It's not as big a deal as I thought when first switching to JS—but if you believe writing readable code is important, you're lose a major tool without being able to label types.

jshen 10y ago

I've worked on a lot of big projects with both dynamic and static languages. I think what a lot of people that are used to static languages don't realize is that dynamic langauge users typically live inside of some kind of repl. The repl gives you immediate access to the thing returned and lets you inspect it and play with it. This serves the same purpose, albeit in a different way, as the IDE for a langauge like java or c#.

mschulze 10y ago
That's a good explanation, thank you. My experience in big projects with dynamic languages boils down to Angular which I didn't find very REPL friendly. BTW, with IntelliJ and its debug mode for Java we almost have some sort of weird REPL. By pressing Alt+F8 one can, during a breakpoint evaluate an arbitrary Java expression while accessing the values in scope. I use it a lot, despite having my types.
- jshen 10y ago
  I use that in Intellij all the time, but it's very limited to something like pry in ruby.
- qwertyuiop924 10y ago
  Angular was a Bad Idea. For so many reasons. I'm barely acquainted with it, but I could already go on about all the problems I had, which other, more experienced people also had. And I do a lot of Lisp programming in Emacs, where the support for REPLs and livecoding is ungodly. Really, really good.
- Roboprog 10y ago
  Install Batarang in Chrome. the "$scope" objects are attached to the browser DOM, and the tool adds another tab to element inspection that shows you the data attached to each level, as well as references back up to enclosing levels.

jeremiep 10y ago

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.

BinaryIdiot 10y ago

> If a colleague writes a function/method that returns something, in JS, how do I know what it is? Typically you have a set of standards for how things get returned. 'isSomething()' returns boolean, 'getSomething()' returns an object, 'getSomethingClassName()' gets a model representing that, etc. Overall it's really the same as static: you usually have something in the function definition that makes it intuitive what it returns. The fallback is documentation directly above the function's implementation that should describe it. When you run into the "well what does the object contain that gets returned?" situation then dynamic and static have the same issue: you have to go to the definition to get that information.

Roboprog 10y ago
Free your mind. Drop all that getXXX setXXX Java-esque noise. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/set https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... http://es6-features.org/#Proxying http://es6-features.org/#Proxying Otherwise, yeah, I can hardly make heads or tails of most "self documenting" (i.e. - undocumented, per SOP) static typed code.
- BinaryIdiot 10y ago
  > Free your mind. Drop all that getXXX setXXX Java-esque noise[...] You confuse my statement. I was not referring to things that should be meant as synchronous properties. These are methods that do more like make an AJAX call to a server. Those that return promises or take in callbacks would be awkward or impossible to force into a property or proxy. I was merely referring to the act of making code as obvious as possible for its intended outcome.
  - Roboprog 10y ago
    Gotcha. Sorry about the tangent, as you were primarily discussing grokking what the names of things were doing anyway.

shados 10y ago

Unless you're working with a strict sound type system, you only have a little more information: you know the properties and methods of what is returned, but you don't know what state its in. So you won't typo a method name, but you still might be dealing with errors from shit that cost cast incorrectly, nulls (even with strict null, since it wasn't there from the start you will still deal with it), arrays not containing what you thought they did, etc. Anything but the most trivial program will still require you to investigate. Once you're familiar with a piece of code you can start making assumptions, and the types get you a little closer to that a little faster. I've worked on multi million line mono-repo pure javascript with zero tests with hundreds of devs working on it, and it worked fine (in fact, we were moving more stuff from the Java/C# code into JavaScript to reduce overhead and friction). If you have tests on top, or if your devs are actually good, its just easier/better. Now, I'm not saying a proper type system doesn't add value. Thats a whole different argument. But any team who can build good software in a static type language can do so in a dynamic one. Its just a different set of tradeoffs. And aside for strict sound type systems, you need (almost) t he exact same amount of unit tests either way. If you don't have tests you're not writing good software either way.

mercurial 10y ago
> Unless you're working with a strict sound type system, you only have a little more information: you know the properties and methods of what is returned, but you don't know what state its in. So you won't typo a method name, but you still might be dealing with errors from shit that cost cast incorrectly, nulls (even with strict null, since it wasn't there from the start you will still deal with it), arrays not containing what you thought they did, etc. You're throwing out (or, rather considering the tricks you can pull in Typescript, hugely reducing) entire classes of issues when using a simple type system. > I've worked on multi million line mono-repo pure javascript with zero tests with hundreds of devs working on it, and it worked fine (in fact, we were moving more stuff from the Java/C# code into JavaScript to reduce overhead and friction). If you have tests on top, or if your devs are actually good, its just easier/better. I've worked on a huge PHP codebase once, with 10 developers working on it and no tests. I would have given somebody else's right hand to have a type system back then. > Now, I'm not saying a proper type system doesn't add value. Thats a whole different argument. But any team who can build good software in a static type language can do so in a dynamic one. Its just a different set of tradeoffs. The point is, the cost of adopting Typescript is frankly, very low, from my point of view, considering the huge benefits it has over raw JS, it's all win.

westoncb 10y ago

I completely agree. Learning new code without types is way slower for me. Example: you have a function that takes a 'file' parameter, and you need to modify the function, so you need to know what the properties on the file object are. Is it some custom File class, or just a poor name choice, or the browser File interface? In a statically typed language it would be marked explicitly and I could probably just CMD+click on it in my IDE and be done. In, e.g., javascript what recourse do I have? No 'File' module is explicitly imported, and the function is invoked somewhere in library code so I never see the file object constructed. So, let's say it turns out to be this 'File': https://developer.mozilla.org/en-US/docs/Web/API/File https://developer.mozilla.org/en-US/docs/Web/API/File —how do I discover this? So far it's been time-wasting, unsystematic trial-and-error sorts of things. It's not as big a deal as I thought when first switching to JS—but if you believe writing readable code is important, you're lose a major tool without being able to label types.