10 ms·

I really enjoyed how the analysis shows that different developers can have different equally valid opinions on this topic. It's where you place your values and

I really enjoyed how the analysis shows that different developers can have different equally valid opinions on this topic. It's where you place your values and preferences of programming, modified by what you are programming. The failure state of a cat photo sharing web app likely isn't as dramatic or important as that of a financial system or driverless car code. Great article.

continuational 9y ago
Static typing reduces the time you spend on debugging. Automatically reducing errors in code is not just for reducing errors in the resulting program. It also greatly reduces the time you spend on hunting bugs, especially if you have a poorly designed type systems where errors are reported far from their origin. Null, interface{}, NaN etc. propagates errors and thus gives you a stacktrace that is worthless when it finally fails. It's a waste of time.
- hellofunk 9y ago
  In my experience, the time saved from writing in a statically typed language where the compiler catches the bugs for you is made up by having to work more closely with the compiler, typically write more code (type annotations and other things) and in general spend that same time on compile-time rather than run-time bug hunting. Dynamically typed languages typically involve a lot less code, which is time gained. That both forms of languages are popular shows that there are benefits in overall productivity to each; they are just different benefits.
  - whyever 9y ago
    The thing is that errors at compile time get reported almost instantly, but errors at runtime might be reported hours after you started your program if you are unlucky.
    - hellofunk 9y ago
      That's entirely correct, and one of the tradeoffs. However, in a statically-typed language, you must satisfy the type checker for everything, which adds development time. In reality, there might be a small percentage of functions in your code base for which errors (either compile-time or run-time) would likely crop up, yet you must pay that cost for 100% of them. So that's really where the debate comes from. Dynamically typed languages can get around this problem by generative testing (in Clojure's case) which allow very fine-tuned aspects of your system's requirements to be automatically tested before run-time without writing tests, which offers some of the same confidence as a compiler.
  - yawaramin 9y ago
    May I ask what your experience of statically-typed languages has been? I find that most people have had a common experience where they didn't get to work in tandem with a fast compiler and a succinct language which inferred most or all types for them, and so their perceptions are coloured by that.
    - hellofunk 9y ago
      Swift, C++, Haskell (a little), Elm (more than a little)
      - yawaramin 9y ago
        May I recommend giving ReasonML a try? Trust me when I say, you've never seen a faster compiler (except maybe C). Try writing a little experiment in ReasonReact and seeing the speed for yourself: https://reasonml.github.io/reason-react/ https://reasonml.github.io/reason-react/
maxxxxx 9y ago
My theory is that there are different psychologies of developers. I always liked how C++ (now C#) checked a lot of stuff at compile time and I rely heavily on the compiler. On the other hand I know very good devs who hate this and prefer dynamic languages. Their whole style is geared towards dynamic languages where mine is geared towards as strict as possible typing. I think the key is not to confuse both approaches and leverage the strengths of each to the max.

continuational 9y ago

Static typing reduces the time you spend on debugging. Automatically reducing errors in code is not just for reducing errors in the resulting program. It also greatly reduces the time you spend on hunting bugs, especially if you have a poorly designed type systems where errors are reported far from their origin. Null, interface{}, NaN etc. propagates errors and thus gives you a stacktrace that is worthless when it finally fails. It's a waste of time.

hellofunk 9y ago
In my experience, the time saved from writing in a statically typed language where the compiler catches the bugs for you is made up by having to work more closely with the compiler, typically write more code (type annotations and other things) and in general spend that same time on compile-time rather than run-time bug hunting. Dynamically typed languages typically involve a lot less code, which is time gained. That both forms of languages are popular shows that there are benefits in overall productivity to each; they are just different benefits.
- whyever 9y ago
  The thing is that errors at compile time get reported almost instantly, but errors at runtime might be reported hours after you started your program if you are unlucky.
  - hellofunk 9y ago
    That's entirely correct, and one of the tradeoffs. However, in a statically-typed language, you must satisfy the type checker for everything, which adds development time. In reality, there might be a small percentage of functions in your code base for which errors (either compile-time or run-time) would likely crop up, yet you must pay that cost for 100% of them. So that's really where the debate comes from. Dynamically typed languages can get around this problem by generative testing (in Clojure's case) which allow very fine-tuned aspects of your system's requirements to be automatically tested before run-time without writing tests, which offers some of the same confidence as a compiler.
- yawaramin 9y ago
  May I ask what your experience of statically-typed languages has been? I find that most people have had a common experience where they didn't get to work in tandem with a fast compiler and a succinct language which inferred most or all types for them, and so their perceptions are coloured by that.
  - hellofunk 9y ago
    Swift, C++, Haskell (a little), Elm (more than a little)
    - yawaramin 9y ago
      May I recommend giving ReasonML a try? Trust me when I say, you've never seen a faster compiler (except maybe C). Try writing a little experiment in ReasonReact and seeing the speed for yourself: https://reasonml.github.io/reason-react/ https://reasonml.github.io/reason-react/

maxxxxx 9y ago

My theory is that there are different psychologies of developers. I always liked how C++ (now C#) checked a lot of stuff at compile time and I rely heavily on the compiler. On the other hand I know very good devs who hate this and prefer dynamic languages. Their whole style is geared towards dynamic languages where mine is geared towards as strict as possible typing. I think the key is not to confuse both approaches and leverage the strengths of each to the max.