The advantages of static typing, simply stated • Hacker News Board

Re: The advantages of static typing, simply stated

#121

Post by JamesBarney » Sat, Sep 17, 2016, 5:53 AM UTC

StefanKarpinski wrote: post #36

Interestingly, most of these advantages are not specific to static typing, but derive from having a language that talks about types – even a dynamic one. For example, most of these advantages apply to Julia as well, a dynamic language that has type declarations, which: - Lets you create typed collections so that if you insert the wrong kind of value, you get an error immediately, albeit only when code runs, not befor…

In my opinion there is a huge difference between I get an error in my compiler, and my user has a hard to reproduce error in a month when they are in the middle of a business critical task.

Re: The advantages of static typing, simply stated

#122

Post by petre » Sat, Sep 17, 2016, 7:52 AM UTC

oblio wrote: post #104

lallysingh wrote: post #61

Earlier quoted context omitted.

> A language created 33 years ago now with no intention of being used as it is today. You know that they update the language regularly, and have a games sig? https://groups.google.com/a/isocpp.org/forum/#!forum/sg14

Yeah, but C++ has so much baggage with it. It could really use profiles. Strict mode or something, where the code should only use N "good practice" features.

D managed to fix most of the C++ annoyances and interfaces quite well with C and C++

https://dlang.org/spec/cpp_interface.html

Re: The advantages of static typing, simply stated

#123

Post by wz1000 » Sat, Sep 17, 2016, 10:16 AM UTC

xapata wrote: post #114

the_af wrote: post #110

Earlier quoted context omitted.

> First, when most people talk about static typing, they're talking about the near-useless version -- just types like Int and String. I think we agree there, so I won't mention it further. I don't agree. Who is "most people"? Certainly not PL designers and not most of what I've seen here in HN. More importantly, it's also not what the article under discussion is saying, either. > Static typing errs on the side of saf…

> you can have your cake and eat it, too. Like a dynamic language with optional type hints? As I said, both techniques can mimic each other, with the corresponding tradeoffs. As you use more generics in a statically typed language, you're sacrificing safety. As you use more type hints in a dynamically typed language, you're increasing syntax clutter and decreasing flexibility.

> As you use more generics in a statically typed language, you're sacrificing safety

Actually, in languages like Haskell, the more generic your type, the more "safe" you can expect it to be.

As an example, consider a function that gives you the first element of the tuple you pass to it.

The most generic type of this function is

    fst :: (a,b) -> a

However, it can also have the type

    fst1 :: (Int, Int) -> Int

Now, you can be sure of the behaviour of fst immediately by looking at its type, but that doesn't hold for fst1

Pretty much the only definition of fst that the compiler will accept is

    fst (x,y) = x

However, the compiler will accept all the following definitions of fst1

    fst1 (x,y) = x+y
    fst1 (x,y) = x*y
    fst1 (x,y) = 2^x
    fst1 (x,y) = 7
    ...

Re: The advantages of static typing, simply stated

#124

Post by tome » Sat, Sep 17, 2016, 12:51 PM UTC

xapata wrote: post #76

Koshkin wrote: post #72

Earlier quoted context omitted.

Let's say, "there is high probability that my code will work correctly right away". (This is especially true for Haskell.) [Edit] To be fair, this is not only, and even perhaps not so much, due to the static typing per se but also due to the mental discipline the particular programming language may require from the programmer even to write code that can be successfully compiled.

> there is high probability that my code will work correctly right away I'll bet my Python code has a similar probability of working correctly on the first run, conditioned on the complexity of the task.

> I'll bet my Python code has a similar probability of working correctly on the first run, conditioned on the complexity of the task.

Having developed professionally in both Python and Haskell, the probability for me was significantly higher in Haskell.

Re: The advantages of static typing, simply stated

#125

Post by hepta » Sat, Sep 17, 2016, 2:50 PM UTC

TheAceOfHearts wrote: post #109

hepta wrote: post #97

Earlier quoted context omitted.

Even though that may be factually correct, it doesn't seem to be related to static typing. Haskell has guards but they are slightly different.

I figured it was relevant, since it relates to types as a whole. Consider the following: I have a "rating" type, which is a whole number from 0 to 5. If you try rendering a view with a number outside of that range, that's a bug! Which means you probably made a mistake somewhere. I want software to help me catch bugs. If something can't be confirmed with a linter or compiler, getting a good error message during runtim…

It relates to typing as a method of encoding invariants, yes. I was trying to say that it is unrelated to which "type" of typing. That is, I can perfectly imagine a statically typed language where you could encode such restrictions as easily as you do with Elixir and you would get the same result, a runtime error.

Regarding your rating example, you could encode that restriction in a type (or class in OO) and have a guarantee that once you have an instance of that type you no longer need to check for it's validity. Rendering a Rating would never fail at runtime, you'd get a type error first.

Re: The advantages of static typing, simply stated

#126

Post by jdmichal » Sat, Sep 17, 2016, 3:42 PM UTC

xapata wrote: post #116

jdmichal wrote: post #99

Earlier quoted context omitted.

A type checker is a formal proof system. A test determines correctness for a given input. A formal proof system determines correctness for all inputs.

The are limits to what a formal proof system can do (eg. The halting problem). I also have never met someone who claimed to never need tests because of a powerful type system.

I'm not claiming to not write tests. I am claiming that there's a class of tests that do not need to be written if a formal proof system is guaranteeing the results. I don't need to write a test to see that `Math.sin("banana")` behaves properly, because the type system can guarantee that this doesn't happen.

Re: The advantages of static typing, simply stated

#127

Post by the_af » Mon, Sep 19, 2016, 1:49 PM UTC

xapata wrote: post #114

the_af wrote: post #110

Earlier quoted context omitted.

> First, when most people talk about static typing, they're talking about the near-useless version -- just types like Int and String. I think we agree there, so I won't mention it further. I don't agree. Who is "most people"? Certainly not PL designers and not most of what I've seen here in HN. More importantly, it's also not what the article under discussion is saying, either. > Static typing errs on the side of saf…

> you can have your cake and eat it, too. Like a dynamic language with optional type hints? As I said, both techniques can mimic each other, with the corresponding tradeoffs. As you use more generics in a statically typed language, you're sacrificing safety. As you use more type hints in a dynamically typed language, you're increasing syntax clutter and decreasing flexibility.

No, not like a dynamic language with optional hints. "Optional" here is a huge disadvantage. For example, if a function lacks a hint which would indicate it's pure, is this because it's meant to be impure or because the programmer forgot to add the hint? No, in order to be useful, static typing must be on by default.

Like the other commenter says, generics actually increase safety: there are fewer assumptions (and therefore, incorrect assumptions, aka bugs) you can make when your functions are generic. Also, modern statically typed languages do not increase clutter by much, and can be very elegant and brief.