5 ms·

Why? Static languages ensure type safety (which are uncovered in unit tests anyway) and to ensure this type safety, they need more information from you, the dev

by Skinney 13y ago

Why? Static languages ensure type safety (which are uncovered in unit tests anyway) and to ensure this type safety, they need more information from you, the developer. Clojure allows you to write less code which, depending on who you talk to, equals faster development time. Static languages are also usually faster, so I guess the tradeoff stands between raw performance and code size. There are numerous succesfull projects using dynamic languages. Github, as far as I know, uses Ruby.

happy_dino 13y ago
> Static languages ensure type safety (which are uncovered in unit tests anyway) Wrong. > ... and to ensure this type safety, they need more information from you, the developer. Wrong. Anyway, correlation != causation. If I would claim that there are some projects which are successful, despite being untyped, I could pretty much use the same data points to make my claim.
- Skinney 13y ago
  > Wrong. What? Static languages doesn't ensure type safety? Or errors due to wrong use of types doesn't get uncovered in unit tests? Unit tests runs the code, so when it runs code where wrong types or names are a problem, the code will fail, thus uncovered... Doesn't help for code you don't have tests for though, which instead require manual testing. The type system does need more information from the user to allow the same kind of flexibility in a type safe environment. Polymorphism either through interfaces or class inheritance is basically a way to tell the compiler that "Hey, i know these objects look different, but they do support the function/method I'm calling, so relax ok?". When someone says they don't understand the use of dynamically typed languages in a real world setting, it makes sense to mention that a company like GitHub mainly uses a dynamically typed language in their product. Heck, even Facebook uses a dynamically typed language quite extensively in PHP. Yes, you could make the argument that alot of successfull projects use statically typed languages, and naturally they do. The point is that dynamically typed languages work just fine in a real world setting.
  - happy_dino 13y ago
    > What? I disagree with your notion of equating types with tests. They are fundamentally different. Types provide substantially stronger guarantees without having to execute any code. > The type system does need more information from the user to allow the same kind of flexibility in a type safe environment. Did you have a look at Haskell? Or any other language with type inference? The connection you are trying to establish between "untyped == no need to specify types explicitly" and "typed == necessary to specify types explicitly" is patently wrong. Having a helpful compiler doesn't mean that the language has to suck. I don't want to offend you, but your comments create the impression that you are lacking experience with a modern, statically typed language.
    - Skinney 13y ago
      > I disagree with your notion of equating types with tests. They are fundamentally different. Types provide substantially stronger guarantees without having to execute any code. I'm not equating types with tests. I'm saying that type errors comes to light when a unit test for a given code is run, because you will get unexpected results and/or an exception is thrown. > Did you have a look at Haskell? Or any other language with type inference? The connection you are trying to establish between "untyped == no need to specify types explicitly" and "typed == necessary to specify types explicitly" is patently wrong. I started learning Haskell but stopped when I came to monads. I've also experience with other languages that provide type inference like Go and F#. Go requires you to define interfaces (something you don't need in a dynamic language like, say, javascript). Haskell also has features that require the developer declare something upfront (types and type derivation), as do F# (discriminated unions and/or types). My actual example was regarding class inheritance and implementing interfaces. Polymorphisism through inheritance or interfaces is great in a statically typed language, but not required or even possible in certain dynamic languages. > Having a helpful compiler doesn't mean that the language has to suck. I don't want to offend you, but your comments create the impression that you are lacking experience with a modern, statically typed language. I never said statically typed languages suck. I've developed an app in C# which was a great experience, and at my day job I work in C++ (which IMHO is a sucky language, but not due to being statically typed). Haskell is also a great language, as is Go and C#. What I did say is that statically typed languages often require more code, which (depending on who you talk to) slows down development compared to a dynamically typed language. Statically typed languages does however usually entail better performance and (sometimes) smaller memory footprint than dynamically typed languages. There is a tradeoff, but that doesn't make one more suited for real world applications than the other, which there exists numerous examples of.
zerr 13y ago
Yes, but when it comes to reading/understanding and refactoring/modifying code - this is where things get complicated.
- Skinney 13y ago
  Never really had any problems reading/understanding dynamic code, actually I (and this is highly subjective) think it's easier to read dynamic code because you don't need to read a lot of extra code written to satisfy a compiler. I agree completely when it comes to refactoring/modifying code though. This can become cumbersome, especially if you don't have unit tests.
  - zerr 13y ago
    Well, what you call an extra code to help to satisfy a compile, I call a part of a documentation which helps understanding the code, in addition with some static integrity checking :)
    - Skinney 13y ago
      I understand the argument. In my experience though, documentation and/or tests usually always makes type info redundant. But I'm well aware that people have different views on this. Each to his own.

by Skinney 13y ago

happy_dino 13y ago

> Static languages ensure type safety (which are uncovered in unit tests anyway) Wrong. > ... and to ensure this type safety, they need more information from you, the developer. Wrong. Anyway, correlation != causation. If I would claim that there are some projects which are successful, despite being untyped, I could pretty much use the same data points to make my claim.

Skinney 13y ago
> Wrong. What? Static languages doesn't ensure type safety? Or errors due to wrong use of types doesn't get uncovered in unit tests? Unit tests runs the code, so when it runs code where wrong types or names are a problem, the code will fail, thus uncovered... Doesn't help for code you don't have tests for though, which instead require manual testing. The type system does need more information from the user to allow the same kind of flexibility in a type safe environment. Polymorphism either through interfaces or class inheritance is basically a way to tell the compiler that "Hey, i know these objects look different, but they do support the function/method I'm calling, so relax ok?". When someone says they don't understand the use of dynamically typed languages in a real world setting, it makes sense to mention that a company like GitHub mainly uses a dynamically typed language in their product. Heck, even Facebook uses a dynamically typed language quite extensively in PHP. Yes, you could make the argument that alot of successfull projects use statically typed languages, and naturally they do. The point is that dynamically typed languages work just fine in a real world setting.
- happy_dino 13y ago
  > What? I disagree with your notion of equating types with tests. They are fundamentally different. Types provide substantially stronger guarantees without having to execute any code. > The type system does need more information from the user to allow the same kind of flexibility in a type safe environment. Did you have a look at Haskell? Or any other language with type inference? The connection you are trying to establish between "untyped == no need to specify types explicitly" and "typed == necessary to specify types explicitly" is patently wrong. Having a helpful compiler doesn't mean that the language has to suck. I don't want to offend you, but your comments create the impression that you are lacking experience with a modern, statically typed language.
  - Skinney 13y ago
    > I disagree with your notion of equating types with tests. They are fundamentally different. Types provide substantially stronger guarantees without having to execute any code. I'm not equating types with tests. I'm saying that type errors comes to light when a unit test for a given code is run, because you will get unexpected results and/or an exception is thrown. > Did you have a look at Haskell? Or any other language with type inference? The connection you are trying to establish between "untyped == no need to specify types explicitly" and "typed == necessary to specify types explicitly" is patently wrong. I started learning Haskell but stopped when I came to monads. I've also experience with other languages that provide type inference like Go and F#. Go requires you to define interfaces (something you don't need in a dynamic language like, say, javascript). Haskell also has features that require the developer declare something upfront (types and type derivation), as do F# (discriminated unions and/or types). My actual example was regarding class inheritance and implementing interfaces. Polymorphisism through inheritance or interfaces is great in a statically typed language, but not required or even possible in certain dynamic languages. > Having a helpful compiler doesn't mean that the language has to suck. I don't want to offend you, but your comments create the impression that you are lacking experience with a modern, statically typed language. I never said statically typed languages suck. I've developed an app in C# which was a great experience, and at my day job I work in C++ (which IMHO is a sucky language, but not due to being statically typed). Haskell is also a great language, as is Go and C#. What I did say is that statically typed languages often require more code, which (depending on who you talk to) slows down development compared to a dynamically typed language. Statically typed languages does however usually entail better performance and (sometimes) smaller memory footprint than dynamically typed languages. There is a tradeoff, but that doesn't make one more suited for real world applications than the other, which there exists numerous examples of.

zerr 13y ago

Yes, but when it comes to reading/understanding and refactoring/modifying code - this is where things get complicated.

Skinney 13y ago
Never really had any problems reading/understanding dynamic code, actually I (and this is highly subjective) think it's easier to read dynamic code because you don't need to read a lot of extra code written to satisfy a compiler. I agree completely when it comes to refactoring/modifying code though. This can become cumbersome, especially if you don't have unit tests.
- zerr 13y ago
  Well, what you call an extra code to help to satisfy a compile, I call a part of a documentation which helps understanding the code, in addition with some static integrity checking :)
  - Skinney 13y ago
    I understand the argument. In my experience though, documentation and/or tests usually always makes type info redundant. But I'm well aware that people have different views on this. Each to his own.