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

Re: The advantages of static typing, simply stated

#71

Post by staticassertion » Fri, Sep 16, 2016, 3:00 PM UTC

xapata wrote: post #45

> Is it safe to call f(x)? The author asserts that static typing allows the compiler to answer this question, but this only allows the compiler to spot type errors in advance. There are many other kinds of errors that are completely invisible to the compiler. In a dynamically typed language, if I don't spot the error from reading the code, I must wait until runtime/testing to discover the error. This is also true for…

"Type errors" go way further than "Damn, I passed a string in where I expected an integer". Types are a way of expressing aspects of your code. You can avoid race conditions, you can ensure a program's state is always expected, you can avoid race conditions, you can avoid design errors by encoding the contracts of your design into your types.

I think if you're used to a language like Java or C++ you may not see what types can really buy you, but that's because most languages have bad type systems.

Re: The advantages of static typing, simply stated

#72

Post by Koshkin » Fri, Sep 16, 2016, 3:01 PM UTC

xapata wrote: post #49

kbanman wrote: post #43

I've recently joined a team writing primarily in Clojure, whose proponents often tout repl-driven programming as a unique benefit to the language. In a statically typed language (the stronger the better), aided by a good IDE, I don't need to be constantly executing my code against data during development; My editor is constantly validating my code, and when it stops complaining, my code will work. And months later wh…

> my code will work You mean your code will compile and run. Whether it behaves as desired is completely unknown without testing.

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.

Re: The advantages of static typing, simply stated

#73

Post by jomamaxx » Fri, Sep 16, 2016, 3:01 PM UTC

tdb7893 wrote: post #69

jomamaxx wrote: post #27

Earlier quoted context omitted.

"Java is fine at decoding Json " It does the job but it's not nearly as nice as javascript or python. It's about double the code in Java and it doesn't read nicely. I think it depends on what you're doing.

Java definitely makes it harder to work with json but the only problem I run in to is that I need classes (which I just autogenerate) for every json object. Serializing and deserializing json is a one liner once you have classes set up for them to deserialize into. Again, it is definitely harder than in Python and Javascript but I work with Java and json every day and it's generally only a huge difficulty if you need…

Ah, yeah, if you have known-entities ahead of time it's no problem via serialization.

Developing/experimenting/scripting is where it's painful.

Re: The advantages of static typing, simply stated

#74

Post by jblow » Fri, Sep 16, 2016, 3:03 PM UTC

StefanKarpinski wrote: post #51

tigershark wrote: post #44

Earlier quoted context omitted.

How can you define throwing an error at runtime instead of compile time an advantage?

I didn't claim it was. That's one of the tradeoffs you make in exchange for a simpler, more forgiving programming model (and the ability to do serious work in a REPL or notebook). However, given that Julia programs can be mostly type inferred before execution, it is possible to check for this kind of error before running a program. There have been some projects to do exactly that [1] [2], and I suspect that once Juli…

Being able to get these errors without running the code is almost all the benefit.

It enables a whole class of highly effective program manipulations that are just unavailable to a non-statically-checked language.

Re: The advantages of static typing, simply stated

#75

Post by RussianCow » Fri, Sep 16, 2016, 3:07 PM UTC

susan_hall wrote: post #2

My disagreement starts with the beginning of this: "A large class of errors are caught, earlier in the development process, closer to the location where they are introduced." I would re-state this as: "A large class of errors are introduced, which otherwise would not exist." Consider dealing with JSON in Java. Every element, however deeply nested, needs to be cast, and miscasting leads to endless errors, elsewhere in…

Every element, however deeply nested, needs to be cast, and miscasting leads to endless errors, elsewhere in the code.

But these aren't needless errors. If something is not of the type that you expect, there should be an error, and static typing makes this more explicit. The verbosity is more to do with that particular implementation, not anything inherent to static type systems.

Re: The advantages of static typing, simply stated

#76

Post by xapata » Fri, Sep 16, 2016, 3:10 PM UTC

Koshkin wrote: post #72

xapata wrote: post #49

Earlier quoted context omitted.

> my code will work You mean your code will compile and run. Whether it behaves as desired is completely unknown without testing.

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.

Re: The advantages of static typing, simply stated

#77

Post by barrkel » Fri, Sep 16, 2016, 3:12 PM UTC

noelwelsh wrote: post #32

barrkel wrote: post #25

Newbie starts with C++, moves on to Haskell after a very brief dabbling in some dynamic languages, and comes out thinking expressive static type systems are great. No great surprise, no real insight. The purpose of programming languages is to bridge the gap between ideas and execution. The purpose of a type system is to prove something about the code; astute readers will notice that this is an orthogonal concern. Sta…

The arrogance (and inaccuracies) in your first paragraph are unnecessary

The chap's lack of experience makes him unqualified to expound in the way that he does. I'm sorry I read the article. I wanted to warn other people away.

Re: The advantages of static typing, simply stated

#78

Post by zzalpha » Fri, Sep 16, 2016, 3:15 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.

Actually, based on my experience, what I found most remarkable about writing code in Haskell (which I admit I haven't done much of) is that I'd spend an enormous out of time wrestling with the compiler, but once I finally got all the type errors to clear out, the odds were surprisingly high that the code would "just work", which is not an experience I had with even other compiled languages (Java, C#, etc).

'course, it probably wouldn't work fast, and it was 50/50 whether I'd introduced space leaks, but...

Re: The advantages of static typing, simply stated

#79

Post by danneu » Fri, Sep 16, 2016, 3:15 PM UTC

empath75 wrote: post #12

jomamaxx wrote: post #9

Earlier quoted context omitted.

I think the problem in your example is mostly related to the fact that Java syntax is just horrible for dealing with JSON - not really an issue of typing. If Java were conceived of today - I think it might look a little different with respect to this. I'd like to point out that there are many areas wherein fluid typing might help a little bit, especially on the UI. Have to make a class for 'every little thing' gets c…

Elm is similarly awful at decoding json, and was what stopped me from trying to use it. I mean, it'll get the job done, eventually, but it's just so much additional work, compared to just json.loads() in python.

I'd say working with JSON in Elm is pleasant and simple, but it does require familiarity with parser combinators.

It's a common challenge for Elm beginners.

Re: The advantages of static typing, simply stated

#80

Post by Koshkin » Fri, Sep 16, 2016, 3:21 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.

> conditioned on the complexity

Indeed, difference in complexity is the key here.