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

Why Type Systems Matter

matthias-endler.de

Post reply on HN
Print view View original

41–50 of 103 posts

Re: Why Type Systems Matter

#41

Post by ardit33 »

blauditore wrote: post #32

I thought this was quite clear, and it's what I've always been missing in languages like Python or JS. Yet I meet many devs, especially coming from such languages, making fun of Java for its verbosity and clumsiness. On the other hand, it leads to some people abusing the static type system: They just randomly change types until it somehow compiles, without thinking about what their doing.

Java is notorious as it has very clumsy syntax. Simple arraylist of dictionaries declaration looks like this:

ArrayList> myArrayList = new ArrayList>();

Could have been just:

ArrayList> myArrayList = new();

or even better:

ArrayList = new(); <- if you don't care what the type of map is.

Re: Why Type Systems Matter

#42

Post by JamesBarney »

rocky1138 wrote: post #2

Strong typing is great when I've already made sense of how the logic should flow and I'm ready to solidify my work into something stable and extensible over time. It's not so great when I'm trying something new and am still trying to work out if what I want to do is even possible, since I find myself trying to identify the right type to use in a given situation rather than proving that I'm even able to do it. A lot o…

When I'm still prototyping I usually pick the part of the project I am the most uncertain about, then write a big function with lots of anonymous types. Once I feel more familiar with it I refactor into types.

But types can also be really useful when you are in the process of learning your domain. If I'm using javascript and I realize I could better represent my code if I did some refactorings I usually don't touch it because I fear breaking something. On the other hand if I'm using a statically typed language I feel free to refactor to my hearts content with the knowledge that the chance I break something is far smaller.

Re: Why Type Systems Matter

#43

Post by ORioN63 »

gertef wrote: post #26
willtim wrote: post #4

Earlier quoted context omitted.

There's no reason why static type errors can't be deferred until runtime, GHC Haskell can do this. Personally I find types invaluable when prototyping. I often fill in the implementations after I work out the types.

> I often fill in the implementations after I work out the types. OK, but that's the opposite of deffering type errors until runtime. Using "undefined"/bottom as the implemenation of a function is how we wrote Haskell before GHC added support for deferring type-errors.

Oops. I still use undefined everywhere, while my code isn't complete.

Also, typed holes. Typed holes are awesome for building implementations based on types.

Re: Why Type Systems Matter

#44

Post by Others »

shalabhc wrote: post #6
willtim wrote: post #4

Earlier quoted context omitted.

There's no reason why static type errors can't be deferred until runtime, GHC Haskell can do this. Personally I find types invaluable when prototyping. I often fill in the implementations after I work out the types.

I wish this was adopted more broadly, e.g. by Rust and other newer languages.

If I'm understanding what you want correctly, Rust kinda will get that once the `!` type is stable/used in type inference correctly.

Re: Why Type Systems Matter

#45

Post by conwaysgame »

ardit33 wrote: post #41
blauditore wrote: post #32

I thought this was quite clear, and it's what I've always been missing in languages like Python or JS. Yet I meet many devs, especially coming from such languages, making fun of Java for its verbosity and clumsiness. On the other hand, it leads to some people abusing the static type system: They just randomly change types until it somehow compiles, without thinking about what their doing.

Java is notorious as it has very clumsy syntax. Simple arraylist of dictionaries declaration looks like this: ArrayList > myArrayList = new ArrayList >(); Could have been just: ArrayList > myArrayList = new(); or even better: ArrayList = new(); <- if you don't care what the type of map is.

Note in Java8, you could just use:

ArrayList> myArrayList = new ArrayList();

Re: Why Type Systems Matter

#46

Post by naasking »

kmill wrote: post #24
naasking wrote: post #12

Earlier quoted context omitted.

> It's not so great when I'm trying something new and am still trying to work out if what I want to do is even possible, since I find myself trying to identify the right type to use in a given situation rather than proving that I'm even able to do it. Finding the right type is solving most of the problem. If you can find the right type, you can solve the problem. If you're having trouble finding the right type, then…

> What makes you think being able to run such half-specified programs for part of the problem will actually help with answering this question? Perhaps rocky1138 thinks this because they have experience answering this question by doing so? I've found it can be hard to find the right type before I've written partial solutions to a problem. Just to be clear, I'm talking about recognizing the monads or functors or what h…

> Perhaps rocky1138 thinks this because they have experience answering this question by doing so?

They have experience with their problem solving style, they don't have experience with every problem solving style, or even necessarily with my problem solving style. You can't infer much from that, and certainly not that typing is "not great when prototyping".

> Just to be clear, I'm talking about recognizing the monads or functors or what have you. Even the general mathematician doesn't start by drawing the right diagram.

Absolutely. But you define the type that seems to match part of the problem, then realize it doesn't fit another aspect, and you refactor it until it covers all of the properties you need. Sometimes this involves writing some code to ensure you've captured the right properties for the problem when there's an algorithmic part, certainly, but to think you've captured anything meaningful or coherent without type checking is bizarre.

Like you later say, "abstracting partial solutions" is probably a pretty common approach, but those partial solutions only come together in a coherent whole if they're typed. Otherwise they likely won't mesh well, and you're left with a mishmash of partial solutions, not a solution.

Re: Why Type Systems Matter

#47

Post by naasking »

Veedrac wrote: post #23
naasking wrote: post #12

Earlier quoted context omitted.

> It's not so great when I'm trying something new and am still trying to work out if what I want to do is even possible, since I find myself trying to identify the right type to use in a given situation rather than proving that I'm even able to do it. Finding the right type is solving most of the problem. If you can find the right type, you can solve the problem. If you're having trouble finding the right type, then…

> If you can find the right type, you can solve the problem. Do you actually believe this?

Absolutely. It's little different than asking whether you can solve a problem once you have the appropriate data structure. Solving the problem when the right data structure is available becomes almost trivial -- most of the difficult of programming is recognizing what data structures are needed.

Very few of the problems we encounter in every day programming don't fall when the right data structure is available.

Re: Why Type Systems Matter

#48

Post by shock »

conwaysgame wrote: post #45
ardit33 wrote: post #41

Earlier quoted context omitted.

Java is notorious as it has very clumsy syntax. Simple arraylist of dictionaries declaration looks like this: ArrayList > myArrayList = new ArrayList >(); Could have been just: ArrayList > myArrayList = new(); or even better: ArrayList = new(); <- if you don't care what the type of map is.

Note in Java8, you could just use: ArrayList > myArrayList = new ArrayList ();

The diamond operator is available since Java 7. Tripped me up too.

Re: Why Type Systems Matter

#49

Post by [deleted] »

ardit33 wrote: post #41
blauditore wrote: post #32

I thought this was quite clear, and it's what I've always been missing in languages like Python or JS. Yet I meet many devs, especially coming from such languages, making fun of Java for its verbosity and clumsiness. On the other hand, it leads to some people abusing the static type system: They just randomly change types until it somehow compiles, without thinking about what their doing.

Java is notorious as it has very clumsy syntax. Simple arraylist of dictionaries declaration looks like this: ArrayList > myArrayList = new ArrayList >(); Could have been just: ArrayList > myArrayList = new(); or even better: ArrayList = new(); <- if you don't care what the type of map is.

[deleted]

Re: Why Type Systems Matter

#50

Post by rocky1138 »

seanwilson wrote: post #11
rocky1138 wrote: post #2

Strong typing is great when I've already made sense of how the logic should flow and I'm ready to solidify my work into something stable and extensible over time. It's not so great when I'm trying something new and am still trying to work out if what I want to do is even possible, since I find myself trying to identify the right type to use in a given situation rather than proving that I'm even able to do it. A lot o…

Can you give an example? I don't find this personally. I find static strong typing speeds me up because I don't have to restart the app, click some buttons etc. to figure out some code was wrong. This is true even for prototypes. Most of the time any type declarations you need are straightforward and once you know your code better you can start introducing more exotic types to capture more errors later.

A really basic example would be the "as GameObject" part of this statement in C#: `GameObject gameObject = GameObject.Instantiate(MyGameObject, Vector3.zero, Quaternion.Identity) as GameObject;".

It's annoying to have to type "as GameObject" when very clearly I am creating a GameObject type (the first thing in the entire statement). Programming languages should be smart enough to figure out that's what I'm trying to do rather than require me to type that out.

Post reply on HN