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

101–110 of 205 posts

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

#101

Post by plmpsu »

tetha wrote: post #97
wvenable wrote: post #34

Earlier quoted context omitted.

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

I don't understand your argument. Could you please explain it?

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

#102

Post by KingMachiavelli »

I think mandatory type hints in method signatures and optional type hints at assignment are a good compromise.

But if I had to pick either a language without any type hint/inference or a verbosely strictly typed language - I would must rather use the strictly typed language.

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

#103

Post by fiddlerwoaroof »

novok wrote: post #94
fiddlerwoaroof wrote: post #69

Earlier quoted context omitted.

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.

The problem is that the “live programming” aspect violates a fundamental assumption of a lot of static type systems: the “closed world” assumption that all the relevant types are known at compile-time. If you can dynamically extend/redefine the types on the fly, your type-system guarantees start getting weaker anyways. Instead, you need a system of contracts or something like Racket has.

Also, if you have macros, you can always just embed a Haskell into your language for the parts where you want that sort of guarantee: https://coalton-lang.github.io/

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

#104

Post by layer8 »

lamontcg wrote: post #100
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.

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.

I agree it's redundant if the type name occurs twice in the same statement. However, further evolution of the code often causes the instantiation to be moved elsewhere, and I wouldn't have confidence that the one doing that change then also changes `var` back to the type name. Instead, it would be nice to have syntax avoiding the duplication in the fashion of `FooBarBazThingyWithALongName thingy = new(...constructor parameters...);`.

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

#105

Post by taeric »

Zababa wrote: post #92
taeric wrote: post #91

Earlier quoted context omitted.

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…

What I meant in our industry being nothing but metaphor is basically me staring at so many OO taxonomies. Even if you ignore deep OO trees (and I think you should), it is hard not to see the way we define most data and simulations as anything other than a very formal metaphor.

That said, I was not trying to say that abstractions and types are directly metaphor. I agree with your points. My argument there was that, like metaphors, types/abstractions are never perfect.

I use types to avoid type errors. Which is a big class of error, to be sure. But they do little to help with logic errors, in my experience. And they are flat detrimental if they require pulling in more and more formalism to cover cases that are of increasingly limited ROI.

If anything, I think our industry would do well to embrace many of the modelling domains that allow use of SAT solvers to find answers. And I don't think I've ever seen a strongly typed one of those that wasn't hard to follow. (I am interested in counter examples.)

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

#106

Post by fiddlerwoaroof »

simion314 wrote: post #96
fiddlerwoaroof wrote: post #72

Earlier quoted context omitted.

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.

People always say this about reading code and it’s just never matched my experience working in either sort of codebase: one difference (comparing lisps and, say, Typescript or Java) is that lisps just have fewer lines to read. So, any assistance you get from the types is counteracted by having to read more code.

But, additionally, I just don’t find it true to my experience that it’s easier to read and understand a dynamically typed codebase vs. a statically typed one. Especially when you have a lisp-like environment that makes accurate jump-to-definition possible.

EDIT: I think I just tend to think about codebases in terms of operations rather than types. And, consequently, when I build a codebase around compositions of functions, the way I think about it isn’t very different in either paradigm.

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

#107

Post by nayuki »

DylanSp wrote: post #78
adrianmonk wrote: post #65

Earlier quoted context omitted.

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…

I don't really see how Java is closer to C than it is to Python in terms of what level of abstraction it's working on, could you elaborate?

It's a matter of opinion whether Java's level is closer to C or Python. But I can name a bunch of high-level features in Python that aren't in Java:

List literals, dictionary literals, tuples, bigint literals, byte strings, f-strings, sequence unpacking assignment, named parameters (kwargs), decorators, closures (functions within functions), metaclasses, generators, async, list/set/dict/generator comprehensions, multiple inheritance, natural JSON support, ...

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

#108

Post by Jensson »

tetha wrote: post #97
wvenable wrote: post #34

Earlier quoted context omitted.

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

> Sufficiently advanced static typing is indistinguishable from dynamic typing.

Static typing type checks are compile time, dynamic typing doesn't. I don't see how these two could be indistinguishable, in one you can't run the program with type errors, in the other you can.

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

#109

Post by pjmlp »

DylanSp wrote: post #78
adrianmonk wrote: post #65

Earlier quoted context omitted.

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…

I don't really see how Java is closer to C than it is to Python in terms of what level of abstraction it's working on, could you elaborate?

And at what level of abstraction does ISO C work on?

"C Is Not a Low-level Language, Your computer is not a fast PDP-11."

https://queue.acm.org/detail.cfm?id=3212479

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

#110

Post by BeFlatXIII »

nyberg wrote: post #62
tabbott wrote: post #57

Earlier quoted context omitted.

I would argue that the really big benefit of dynamic typing is that it enables a really nice interactive interpreter shell experience. I think it's also important from a prototyping standpoint that Python's static typing model does a lot of inference -- you don't have to add an explicit type annotation on every single variable.

This is possible with statically typed languages with Haskell being one of the examples where it's encouraged to use the REPL to work towards a solution and/or qucikly test ideas without having to write unit tests or full program tests. Ocaml and friends fall within this category too and none require extensive type annotation due to type inference. I feel that too much focus is on static languages like C/C++ where ty…

> languages like C/C++ where types become a chore

It's been a long while since I used those languages, but I remember the chore part wasn't so much of typing Int or String and more so having to care if it's an Int, Short, or Long or if the float is single or double precision. I believe that those micro-optimizations are no longer popular, but manually thinking low-level is not something I enjoy.

Post reply on HN