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

81–90 of 205 posts

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

#81

Post by dmart »

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.

Yeah, when writing type inference is obviously nice, but it can be annoying to try to go back and read.

I think the best experience is having a language server annotate the inferred types (like how rust-analyzer does it.) But even then, it can become hard to read code on GitHub or somewhere where tools are not available. Granted that's becoming less and less of a problem, and even GitHub allows using some VS Code extensions now.

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

#82

Post by angelzen »

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…

This is doubly true as experienced programmers argue that designing the data structures is the hardest part of coding. Code follows semi-automatically.

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

#83

Post by layer8 »

andybak wrote: post #75

Having spent a decade with Python and more recently a few years with C# I still can't quite put my feelings into words but here's an attempt: "The benefits of explicit typing are obvious and clear but they downsides are subtle and hard to communicate" I still think typing in general is a net win but I'm not sure whether static typing is. You find yourself writing code that just wouldn't be neccesary in a dynamic lang…

Types are effectively assertions about the values they represent, and statically-typed code constitutes proofs that the assertions actually hold at runtime. The static typing forces you to be sufficiently rigorous in those proofs, which may require additional code as you mention. Without static typing, one has to rely on the "proofs" in one’s head to be correct (which humans aren’t really good at), instead of having the compiler double-check one’s reasoning.

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

#84

Post by Zababa »

taeric wrote: post #74
Zababa wrote: post #58

Earlier quoted context omitted.

The metaphor doesn't really works, as in software lots of high rise start as a little shed.

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 world. There's no need to go look for a shed. If we had to statically type and test every shell commands we typed, we would lose lots of productivity. On the other hand, maintaining those very large scripts that started as a simple line and are now used for deploying all of our application, and tend to fail in surprising ways, would be easier.

The other problem with metaphors is that they are also hard to refute. I've never built a shed, nor worked on a high rise. I don't see why that experience would be relevant to building software, or necessary in a discussion about static typing.

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

#85

Post by fuckf4ce »

adrianmonk wrote: post #65
handrous wrote: post #18

Earlier quoted context omitted.

> 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…

Consider these 4 possible combinations for programming languages: (1) Low-level, static types (2) Low-level, dynamic types (3) High-level, static types (4) High-level, dynamic types For whatever reason, historically #1 and #4 have been most popular. C, C++, Pascal, Ada, and Java are #1. Python, JavaScript, Perl, and BASIC are #4. There haven't been a lot of #2 or #3 languages. Some #3 languages (TypeScript and Python…

Lumping Java and C together is a stretch. Even Ada and C. I think Ada is a good example that your proposed classification scheme is invalid -- what is low vs high level? Maybe Java has historically been weak in the language features department but it has had non-optional automatic memory management from the get go. What about C#? It's not exactly unpopular.

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

#86

Post by layer8 »

dmart wrote: post #81
layer8 wrote: post #76

Earlier quoted context omitted.

> 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.

Yeah, when writing type inference is obviously nice, but it can be annoying to try to go back and read. I think the best experience is having a language server annotate the inferred types (like how rust-analyzer does it.) But even then, it can become hard to read code on GitHub or somewhere where tools are not available. Granted that's becoming less and less of a problem, and even GitHub allows using some VS Code ext…

With good IDE support, writing types isn’t that much of a burden. Either write a function call first and use "assign return value to new variable", or use autocompletion where you only type the initials of a multi-word type name. Plus IDE refactoring actions when a parameter or return type needs to be changed.

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

#87

Post by shpongled »

adrianmonk wrote: post #65
handrous wrote: post #18

Earlier quoted context omitted.

> 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…

Consider these 4 possible combinations for programming languages: (1) Low-level, static types (2) Low-level, dynamic types (3) High-level, static types (4) High-level, dynamic types For whatever reason, historically #1 and #4 have been most popular. C, C++, Pascal, Ada, and Java are #1. Python, JavaScript, Perl, and BASIC are #4. There haven't been a lot of #2 or #3 languages. Some #3 languages (TypeScript and Python…

#3 languages have been around since the 80's (SML) and 90's (Haskell)

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

#88

Post by AlexCoventry »

m12k wrote: post #11

I've only been in the industry for ~15 years, but it still feels like every year, some ecosystem discovers the value of something that another ecosystem has taken for granted for decades - type-checking, immutability, unidirectional data-flow, AOT-compilation, closures, pure functions, you name it. I'm glad we seem to be converging on a set of best practices as an industry, but sometimes I wish we were spending less…

I think the limiting factor in the case of python getting type hints was that it was never designed for type safety in mind, and that it took a while to establish consensus on a good type-hinting system.

I don't think it's a matter of reinventing the wheel, in this case, more a matter of bolting something like a wheel on a system which didn't start with wheels.

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

#90

Post by orwin »

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.

The biggest reason why i like type hints is because it force me to reflect on the datatype i want to use before implementing my code.

Last week, i could've done either a dataframe, a list of list, a list of tuple, a dict of tuples, a dict of lists (this was a bad idea that did not survive more than 2s in my head) or a list of dict. I started coding with a dataframe in mind (i guess i wanted to show off my numpy/pandas skills to my devops colleagues), but adding type hints to my prototypes shut down the idea pretty quick: lot of complexity for nothing.

Post reply on HN