[deleted]
Type Inference Was a Mistake
91–100 of 133 posts
Re: Type Inference Was a Mistake
#92Earlier quoted context omitted.
What's a "book"? Seriously, that argument is like saying that long variable names are bad because sometimes you have to write code on punched cards. The solution to the drawbacks of obsolete technology is to not use obsolete technology.
Books are definitely not obsolete technology, you can consider them old or even traditional but they aren't obsolete by any means.
Books are those things you load on your kindle right? I mean, ya, they aren’t obsolete, but it’s not the main way I absorb information anymore.
Re: Type Inference Was a Mistake
#93Bullocks. 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 wa…
Man I wish I could somehow convince developers to learn the difference between "dynamically typed", "statically typed", and "gradually typed" languages. An "untyped" language nearly doesn't make any sense semantically: when you have more than one type of value, you have types.
In Python's case, there are probably thousands of types in the standard library alone.
Re: Type Inference Was a Mistake
#94I think this article makes some really valid points. Many languages try to address the spooky action at a distance type errors by requiring explicit annotation of types at certain boundary type conditions like function argument and return arguments -- which can help but can still also being annoying when the type system knows the types you want to write but you still have to figure them out and type them in yourself.…
Do you have any sources or links where you or others expand on these ideas? I daydream about something like this every so often.
Re: Type Inference Was a Mistake
#95Sometimes you'll read something and think "I'm not taking the bait".
It's not even factual. > In Rust and Haskell you have to at least annotate the parameter types and return type of functions. Type inference is only for variable bindings inside the function body. This is false for Haskell. Can't speak for Rust.
it's technically false for Haskell, but is considered mostly good practice. It would be true for Idris.
Re: Type Inference Was a Mistake
#96I agree with the idea that function return types should be explicit rather than inferred, but not the rest. In a lot of situations, inference makes it so you only have to spell the type once, instead of multiple times. That is valuable and doesn't reduce legibility.
Re: Type Inference Was a Mistake
#97This 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.
The author does have a good point about the readability of code snippets, but the right approach is to render code with type annotations when outputting these formats, similar to syntax highlighting. I do not miss having to change in32_t to int64_t at every location in my code when I changed my mind about types.
> I do not miss having to change in32_t to int64_t at every location in my code when I changed my mind about types.
A good reason to use logical typedefs, though.
Re: Type Inference Was a Mistake
#98vscode just writes the type next to the auto variable. It also prints parameter names, initializer fields and even array initializer indexes.
All this visual help makes a lot of pet arguments obsolete.
Re: Type Inference Was a Mistake
#99This 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.
Bruce Eckel (Thinking in Java) gave a presentation to the Seattle Java User’s Group sometime around 2008. I thought he would talk about Java things but he surprised us by talking about how annoying it is to get code snippets into books. He had interns writing a tool to extract live code and plop it into the book. It was something very similar to the tool I would find in jcite a few years later when my team had a bullseye on our back for being the only team close to on schedule (because we were using dev processes that were industry standard but not company standard and that pissed some people off).
They pointed out every place we weren’t following The Rules and one of those was that we weren’t creating a developer manual for people to use our library. Which was somewhat fair except I’d already walked people on every team through it, in person with a sequence diagram for doing their part of the workflow. But that was going to take me days of busy work every release and suck all of the joy out of my life. It was a clever chess move.
So what I did instead was fix our functional tests to be compatible with JCite, mash the printed form javadoc and some wiki pages together, and shoehorned them into a template of the corporate document format, programmatically. I couldn’t quite get the footers and indexes right, but I asked our less senior tech writer if she would be okay having to spend an hour fixing typesetting problems every release and she agreed. So instead of two developer days it was one hour of typesetting, by a tech writer. It took almost a year to break even on the time investment but it was well worth it in the long run.
To draw this curvy line back into a circle, I would think it perfectly reasonable not to utilize type inference in a functional or integration test. For the reason that you’d want something to break that tells you that you have a breaking change in this release.
Re: Type Inference Was a Mistake
#100Earlier quoted context omitted.
But also when printing code in a book I would annotate with types, inference or not.
Bruce Eckel (Thinking in Java) gave a presentation to the Seattle Java User’s Group sometime around 2008. I thought he would talk about Java things but he surprised us by talking about how annoying it is to get code snippets into books. He had interns writing a tool to extract live code and plop it into the book. It was something very similar to the tool I would find in jcite a few years later when my team had a bull…
Generating documentation from working code – as long as it's not at the expense of quality descriptions – is by far the superior way to make documentation. Every time I have not done that, the examples have become outdated within a year.