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

Tests aren’t enough: Case study after adding type hints to urllib3

sethmlarson.dev

Post reply on HN
Print view View original

91–100 of 205 posts

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#91

Post by taeric »

Zababa wrote: post #84
taeric wrote: post #74

Earlier quoted context omitted.

Quite the contrary, in my opinion. Lots of what makes various parts of the physical hard are in the infrastructure surrounding them. This is very similar to the complexity in software setups. Take game systems, as an example; far far more effort will be spent in the art and general asset management than is true for many business software setups. Which is why many of the business best practices haven't necessarily mov…

I'm not sure what you're trying to say. Something like "the software world is complex, and so is the physical world, so comparing the two makes sense"? If that's what you meant, you're right, but the problem is that comparing the two doesn't lead to better insight in those. If that's not what you meant, then sorry, I didn't understand. I think that in general we should stop using so much metaphors in the software wor…

I'm claiming that most of the complications that will actually influence many of the intrinsic choices of both, will be dictated by external factors. Static typing being an intrinsic fact of software, I couldn't tell you what most of the software I use, used.

Calling for lack of metaphor is interesting. In many ways, our industry is nothing but metaphors, so it is surprising for me to see them called down.

I agree that no metaphor is perfect. But, by that same logic, I would argue that no specified type is perfect. Especially if done so in a taxonomy that does not admit exceptions. (And again, I'm not against types.)

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#92

Post by Zababa »

taeric wrote: post #91
Zababa wrote: post #84

Earlier quoted context omitted.

I'm not sure what you're trying to say. Something like "the software world is complex, and so is the physical world, so comparing the two makes sense"? If that's what you meant, you're right, but the problem is that comparing the two doesn't lead to better insight in those. If that's not what you meant, then sorry, I didn't understand. I think that in general we should stop using so much metaphors in the software wor…

I'm claiming that most of the complications that will actually influence many of the intrinsic choices of both, will be dictated by external factors. Static typing being an intrinsic fact of software, I couldn't tell you what most of the software I use, used. Calling for lack of metaphor is interesting. In many ways, our industry is nothing but metaphors, so it is surprising for me to see them called down. I agree th…

> Calling for lack of metaphor is interesting. In many ways, our industry is nothing but metaphors, so it is surprising for me to see them called down.

I don't think that's true. There are lots of metaphor because people love using metaphors, but it's not inherent to our industry. Abstraction is, but abstraction and metaphors are different. Metaphors seem to mostly come from blog-post type content, where people want to give you an intuition for something in less than 10 minutes. There's a really good article about this, in the context of monad tutorials, which are some of the most proheminent victims of these metaphors https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti....

> I agree that no metaphor is perfect. But, by that same logic, I would argue that no specified type is perfect. Especially if done so in a taxonomy that does not admit exceptions. (And again, I'm not against types.)

I would call types an abstraction rather than a metaphor, though I agree with you that they are not perfect, in that all abstractions trade precision and exhaustiveness for speed. There are interesting alternatives to this with property-based checking and whatever clojure.spec is, and type systems themsleves are getting better, but we're still not at perfection. And even then, I don't think we will ever reach it. The "best" type systems currently all seem to have some structural parts, and some nominal parts, so there's no silver bullet.

I mostly use types to avoid stupid mistakes (I make lots of typos, and Typescript helps a lot here), and to improve developer tooling. I'd like to try some approach with DDD and types, but my current company isn't big on DDD, so I can't really judge it. I also like using unit and integration tests. All of these make me feel safer when doing changes. But some people are fine with catching errors in production and quickly fixing them.

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#93

Post by novok »

cle wrote: post #46
malfist wrote: post #32

Earlier quoted context omitted.

How in the world does type checking lower the ceiling on excellence?

I"m guessing by rejecting perfectly valid and correct programs that are unable to be type checked. There is a large space of "false negative" programs that a type checker will reject, but that could be perfectly correct. E.g. compare Python-esque duck typing with nominal typing.

You can have that by using Any as your type if you so wish typically and escape the type system for those rare circumstances.

Also C# suffers a similar issue with what I call "unproductive Java bureaucracy", since it's basically Microsoft Java. Bureaucracy is not static typing. You can also have full dynamic dispatch and still have static typing too.

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#94

Post by novok »

fiddlerwoaroof wrote: post #69
arwhatever wrote: post #9

Earlier quoted context omitted.

Is it possible to elaborate in a comment? Honestly I probably wouldn’t take the time to read a lengthy article, but if there’s some elevator pitch then I’m all ears.

What makes CL/Clojure really work is that your editor (emacs usually, but there’s other options now) connects to the live program and has access to the entire runtime environment. So, you can do a lot of the things other languages need static types for via introspection (e.g. autocomplete: CL just asks the running program what functions are available that matches the current pattern and returns a list). Secondly, sin…

I could see a statically typed language that would give you a live reflection system and macros. I think it's more if you have to chose, you'd rather have that than static types.

But I think it is possible to have all 3, it just doesn't exist in any popular language that I am aware of.

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#95

Post by alpaca128 »

handrous wrote: post #18
dado3212 wrote: post #7

Honestly will never go back to languages without type checking, it prevents so many bugs and is a huge help in understanding code you haven’t worked with previously.

> Honestly will never go back to languages without type checking, it prevents so many bugs and is a huge help in understanding code you haven’t worked with previously. I see static types as one of the most powerful communication tools around, as far as code goes. I can't relate at all to people complaining that they waste time. They must work very differently from how I do, is all I can figure. It's that, or they don…

I can remember that in the beginning it felt cumbersome to me because I wasn't all too familiar with that language's type system and so I had all kinds of errors thrown at me.

But it's something you just have to get used to, and now that I understand it much better I feel more productive and have more confidence in my code. And the communication aspect is definitely a great help too. No handwritten documentation can be this consistent, completely independent of who touched the code (though to be fair, it's still difficult to get the naming right).

I can't imagine the people calling it a waste of time got over the hump in the beginning. To me it's obviously a timesaver. It does a tedious, difficult (for humans) task and does it quickly & with perfect accuracy. Beforehand worrying about all the type signatures and interfaces felt like 4D Sudoku across various modules, now I can concentrate on the interesting parts.

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#96

Post by simion314 »

fiddlerwoaroof wrote: post #72
lemper wrote: post #16

Earlier quoted context omitted.

i have a small side project in clojure [1] and i always miss type checking when working on it. not by much because it's a small project but i am tired of iseq is not a function error. [1] https://dactyl.siskam.link

I sort of think there are two mindsets behind this debate: people that miss the guard rails of a static type system and people that enjoy the experience of iterating quickly in a dynamically typed language. I don't really want to say everyone should pick one side or the other, just that my experience doesn't bear out the claim that "statically typed languages produce more maintainable code". And, the little bit of em…

>and people that enjoy the experience of iterating quickly in a dynamically typed language

Programmers spend more time reading code then writing it. So I personally prefer the devs in the team will spend more time typing the code or use a bit more brain energy to think about types so later we can all read the code and understand it and edit faster.

Dynamic works great for write-only scripts.

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#97

Post by tetha »

wvenable wrote: post #34
david422 wrote: post #19

I love static typing/type hints if for only 1 thing - code maintenance. Even code I wrote six months ago. Not having to dig through 6 functions deep to try to figure out whether "person" is a string, or an object, and if it's an object what attributes it has on it etc. is huge. And not to mention that some clever people decide - hey, if you pass a string I'll look up the person object - so you can pass an object or a…

The main argument for dynamic typing is speed in prototyping but I find that's opposite for me. I'm much more comfortable rapid prototyping and ripping stuff apart when I have a strongly static typed environment telling me what I just broke. Doing radical refactoring often involves just making those changes and then fixing all the IDE or compiler errors until it runs again.

Hm, growing somewhat experienced, I find myself adapating an old quote more and more: Sufficiently advanced static typing is indistinguishable from dynamic typing.

Now, I know, it's not true. It's entirely possible to build weird things in python that are provably impossible to typecheck statically. But modern language servers and their type inference capabilities in rust, terraform, or even straight up python are very impressive.

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#98

Post by IshKebab »

tunesmith wrote: post #45
dado3212 wrote: post #7

Honestly will never go back to languages without type checking, it prevents so many bugs and is a huge help in understanding code you haven’t worked with previously.

I've been a types advocate for years, but it wasn't until working with Typescript that I started experiencing some of the downsides... To me, ideally, types are supposed to be a benefit not only in safety, but in understanding the intent of a piece of code more quickly. For an api or library interface, review the types to see what its intentions are. But there's something about the typescript type system, with all th…

Your criticism boils down to "it's possible to overcomplicate things". Sure if you completely remove static typing then you can't overcomplicate static typing. But is that really an argument against static typing?

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#99

Post by karmakaze »

david422 wrote: post #19

I love static typing/type hints if for only 1 thing - code maintenance. Even code I wrote six months ago. Not having to dig through 6 functions deep to try to figure out whether "person" is a string, or an object, and if it's an object what attributes it has on it etc. is huge. And not to mention that some clever people decide - hey, if you pass a string I'll look up the person object - so you can pass an object or a…

I learned the same thing on a project that was using Java 1 non-generics. Not exactly untyped to typed but an analogous experience. Everyone I asked said that it was too big to do. I started anyway by enabling the warnings for nongeneric use. I turned down the reporting limit to 1000 (I think) so as not to be discouraged. After months and months of incremental work alongside my main work, I got under the 1000 warnings. It got a bit trickier after that. In the end, there was exactly 1 bug, where an object.toString was being added to a dropdown box and we'd see it from time to time as Class@hexhash. What I learned then is that it isn't strictly about the bugs, it's the confident way you can navigate the codebase and understand and add in consistent ways. Now I add types to all my Ruby and it's seems normal again.

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#100

Post by lamontcg »

layer8 wrote: post #76
david422 wrote: post #19

I love static typing/type hints if for only 1 thing - code maintenance. Even code I wrote six months ago. Not having to dig through 6 functions deep to try to figure out whether "person" is a string, or an object, and if it's an object what attributes it has on it etc. is huge. And not to mention that some clever people decide - hey, if you pass a string I'll look up the person object - so you can pass an object or a…

> I hate having to waste time figuring out the type of every variable and hold it in my head every single time I read a piece of code. For the same reason, I’m not a fan of type-inferring variable declarations.

I'm okay with "var = new FooBarBazThingyWithALongName()" because I don't need to see the type name twice there.

In an IDE you can get the type annotation from the IDE over every inferred var type, but I don't like requiring an IDE to see that information and like it showing up in 'less' as well.

Post reply on HN