Re: Haskell is our first choice for building production soft...
by wtetzner on Monday January 11, 2021 @11:27AM
(#25731172)
> Is it really that painful to write "String" each time?
I find it more painful to read code that has too many type annotations. I also find it painful to read code that has too few, so I'd argue there's a bit of an art to it.
But languages that have type inference but allow type annotations at least allow you to try to hit that balance.
Re: Haskell is our first choice for building production soft...
by leshow on Monday January 11, 2021 @12:11PM
(#25731980)
> I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.
Type inference doesn't make these errors go away.
And about your other point, it's unfair to look at just a simple case of writing "string" or not as the only thing inference provides. Although I'd argue that leaving out types where possible helps readability-- it's really the more elaborate cases or intermediate steps during a longer transformation that inference helps with. Not to mention the fact that inference in closures is also really nice.
Re: Haskell is our first choice for building production soft...
by silluk on Monday January 11, 2021 @11:25AM
(#25731130)
To me it's not the trivial cases like this that make type inference useful. It's when you get longer types like `Arc<Mutex<HashMap<String, String>>>`. Granted, that could be solved with a `type` declaration (or `typedef` in C++) but it's still convenient to be able to say: `let mut x = Arc::new(Mutex::new(HashMap::new()));` and let the compiler figure out the rest based on usage.
I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.