Hard disagree. One of the reasons I fell in love with F# was the succint code one can write, specifically due to the compilers ability to infer types.
Type Inference Was a Mistake
21–30 of 133 posts
Re: Type Inference Was a Mistake
#22This is not good. One of the author's arguments is that type inference in an IDE is bad because sometimes I read code in a book where I don't have type inference... I don't know about other folks, but the vast majority of code I read is in my editor, where the type inference saves me a ton of time and pain.
But also when printing code in a book I would annotate with types, inference or not.
Re: Type Inference Was a Mistake
#23This SOUNDS like “types are bad”. The author’s message (towards the end of the article) is “I don’t want to infer types from my code. I’d rather infer the code from the types. Types are the spec…” Yes. Always annotate types. Keep inference, it tells you when your annotations are inconsistent with tour code.
> Keep inference, it tells you when your annotations are inconsistent with tour code. Isn't that plain type checking, rather than type inference? Type checking detects inconsistencies, type inference assigns types in ways that avoid inconsistencies.
Right. I guess I meant annotate most of the things. (Top level things, complicated inner functions …) A few temporary values (next = current + 1) might go un-explicitly-typed. Anonymous functions will go untyped.
I should have said “ensure your intentions with regards to types are clear”.
Re: Type Inference Was a Mistake
#24Explicit typing is great until your code is littered with shared_ptr >>> everywhere.
If you're using a type like that repeatedly then it probably deserves an alias.
Re: Type Inference Was a Mistake
#25I admit, I like to use `auto` more than I like to read it
Re: Type Inference Was a Mistake
#26> languages that use it too much are harder to write. It’s a false economy whereby you save unobservable milliseconds of typing today and make everything else worse.
I enjoyed this reference to a false dichotomy while making one itself. Languages don't make programmers leave out annotations where it aids readability.
Re: Type Inference Was a Mistake
#27Bullocks. I wrote thousands if not hundred thousandths lines of untyped Python code in over 15 years, for critical systems and thousands of users.
It works for me. I'm not confused about the code, I can code and debug quicker than many of my typed-language colleagues and even now that python supports type hints I often only use them in bigger projects or in places where they're actually convenient.
It's simply the way of working that a developer is used to.
Re: Type Inference Was a Mistake
#28This is not good. One of the author's arguments is that type inference in an IDE is bad because sometimes I read code in a book where I don't have type inference... I don't know about other folks, but the vast majority of code I read is in my editor, where the type inference saves me a ton of time and pain.
I also find myself reading code in a browser, for example in GitHub or any other system for source control, issue management, code review etc.
Re: Type Inference Was a Mistake
#29> Type inference is bad. It makes code harder to read, and languages that use it too much are harder to write.
If inference is bad, maybe the second sentence shouldn't leave it up to the reader to infer what "it" means. Surely it would be much easier to read as "Type inference [...] type inference [...] type inference".
Re: Type Inference Was a Mistake
#30Explicit typing is great until your code is littered with shared_ptr >>> everywhere.
When trying to figure out something's type is the same as trying to fully comprehend a regex pattern, you know things have gone too far.