Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The advantages of static typing, simply stated

pchiusano.github.io

Post reply on HN
Print view View original

11–20 of 127 posts

Re: The advantages of static typing, simply stated

#11

Post by empath75 »

sidlls wrote: post #3
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…

Have you considered the possibility instead that JSON is not an appropriate serialization protocol or storage mechanism for the problem to be solved? Or that it isn't being used effectively/correctly (that is, it isn't being parsed correctly, e.g. with a library or some other mechanism that makes checking underlying types less cumbersome)? I noted in a comment downstream from here that plenty of C and C++ JSON librar…

Have you worked with a public api in the last few years that didn't depend on json?

Re: The advantages of static typing, simply stated

#12

Post by empath75 »

jomamaxx wrote: post #9
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…

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.

Re: The advantages of static typing, simply stated

#14

Post by tmhedberg »

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…

Haskell's aeson library, which is probably the most popular way to use JSON in that language, doesn't require any of this complexity or typecasting ugliness. It can derive a typechecking parser for a particular JSON format from an ordinary Haskell data type. Your type becomes a JSON schema, and as long as the JSON you're parsing conforms to that schema, the parsing just works with a single function call.

The problem you're pointing out is not a problem with statically typed languages. It's a problem with bad languages.

Re: The advantages of static typing, simply stated

#15

Post by mamon »

susan_hall wrote: post #5
sidlls wrote: post #3

Earlier quoted context omitted.

Have you considered the possibility instead that JSON is not an appropriate serialization protocol or storage mechanism for the problem to be solved? Or that it isn't being used effectively/correctly (that is, it isn't being parsed correctly, e.g. with a library or some other mechanism that makes checking underlying types less cumbersome)? I noted in a comment downstream from here that plenty of C and C++ JSON librar…

We have no control over the API that we draw from. We are drawing from the API of a different company. I wish they didn't use JSON. If they have to use JSON, I wish they at least enforced a consistent schema. But they don't. And that is why static type checking fails: because the real world is chaotic, and when you have to interact with that real world, you are often forced to do so dynamically, because of the mistak…

Ok, so they created a problem by using JSON without schema.

Now, instead of fixing problem by enforcing some schema you propose to use dynamically typed programming language which won't solve the problem but instead will make it spread thorough the whole codebase.

At least static typing limits the damage to the code that directly deals with parsing JSON.

Re: The advantages of static typing, simply stated

#16

Post by crdoconnor »

gaius wrote: post #13

Why are we even still having this debate in 2016? The question is not if strong types are better but how to migrate existing codebases to those languages. I'm an OCaml guy myself but Swift looks pretty nice...

Partly because people still get mixed up between strong typing (something without any clear definition) and static typing...

Re: The advantages of static typing, simply stated

#17

Post by ashark »

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…

There's casting happening all over in the dynamic code in this scenario. It's implicitly handling what would be error conditions or explicit casting in a static language. Whether that's a good thing or not is what's at issue (generally, no, it's not).

Re: The advantages of static typing, simply stated

#18

Post by tigershark »

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…

Your example is non-sensical. It has nothing to do with a comparison between static types vs dynamic types, it is only the usage of an awful JSON library in a not so nice language. In F# you even have Type Providers for JSON that give you auto-completion in the IDE:

    type Simple = JsonProvider
    let simple = Simple.Parse(""" { "name":"Tomas", "age":4 } """)
    simple.Age
    simple.Name
and most importantly you don't have nulls.

Re: The advantages of static typing, simply stated

#19

Post by noelwelsh »

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…

You don't need to have these issues. If you have a field that is optional, you can model that with the Optional type in Java 8. So I would model your dataList as Option>. If I cared that a list is definitely not empty I would create a type called NonEmptyList to model that. This is very typical is Scala, which is the language I use most often.

Re: The advantages of static typing, simply stated

#20

Post by the_af »

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…

You seem to be focusing just on the (admittedly problematic) problem of parsing outside and possibly invalid input. This is hard, especially if the API is poorly defined.

But this is hard with any typing system. Using dynamic typing will just hide the problems under the rug, and they will explode in your face later on. Static typing just made those problems explicit.

There are many benefits to static typing, beyond the external boundaries of the system, where it definitely lives up to its promises.

Post reply on HN