The benefits of static typing without static typing in Python • Hacker News Board

Re: The benefits of static typing without static typing in Python

#41

Post by dzbarsky » Sun, Jan 24, 2016, 5:13 PM UTC

mcguire wrote: post #29

What does mypy do if you make a call from code with type annotations into code without? Or vice-versa? Has anyone ever gotten paid to add annotations to code that works? Personally, I view type systems as like a safety line when doing work on a roof, and optional typing as having a line that might or might not be tied off.

> What does mypy do if you make a call from code with type annotations into code without? Or vice-versa?

It's not able to analyze across such boundaries, but as you expand the set of typed code you get better and better coverage.

> Has anyone ever gotten paid to add annotations to code that works?

At Dropbox, we're starting to add type annotations to code. We're confident it will catch many bugs at lint time. Source: I work at Dropbox.

> Personally, I view type systems as like a safety line when doing work on a roof, and optional typing as having a line that might or might not be tied off.

At least it has the possibility of being tied off and catching you. Better than definitely not having a line.

Re: The benefits of static typing without static typing in Python

#42

Post by dzbarsky » Sun, Jan 24, 2016, 5:16 PM UTC

qwer wrote: post #20

Since I unit-test the heck out of my code, this doesn't really do much for me. Unit-tests test actual values (which is where the interesting bugs come from IMO) and give me more powerful refactoring capabilities than an IDE. The real benefit I'd be looking for is the chance to give the compiler hints to speed up execution times.

Even if you ignore all the other benefits of type annotations, merely being explicit about the types of parameters your function accepts helps people reading your code.

If you're going to make the argument that you can just add comments with the types - well then that's exactly what mypy is doing, but if you do it in the mypy format you get static analysis of your types for free.

Static typing and unit testing aren't mutually exclusive.

Re: The benefits of static typing without static typing in Python

#43

Post by aphexairlines » Sun, Jan 24, 2016, 5:20 PM UTC

randallsquared wrote: post #28

TazeTSchnitzel wrote: post #26

Having type annotations that are ignored at runtime would cause problems when you interact with code without type annotations, no? PHP has a (unfortunately quite limited) set of type annotations, but the interpreter actually enforces them.

How could adding ignored type annotations cause problems? Any problems that arise would have to be there without the type annotations...?

Without the type annotations, you're expected to handle dynamic type checks yourself. With type annotations, you might think that tooling does it for you, so you might omit the dynamic checks. But the tooling doesn't necessarily check all your callers, and you end up with unexpected input.

This is partly what the Typed Racket writers mean when they say that most gradual typing systems like this one are not sound.

http://www.cs.cornell.edu/~fabianm/tpls/papers/20151110.shtm...

http://www.ccs.neu.edu/racket/pubs/popl16-tfgnvf.pdf

Re: The benefits of static typing without static typing in Python

#44

Post by grdvnl » Sun, Jan 24, 2016, 5:41 PM UTC

zeckalpha wrote: post #11

ptype wrote: post #9

Earlier quoted context omitted.

I hear this argument a lot, and I'm sure static typing is helpful when refactoring, but I have found that nothing is as important as tests when refactoring. I'd rather refactor dynamically typed code with good test coverage than statically typed code without good tests.

It is better with certain languages, and it is better when you encode business logic into your type system.

I work on Python and the Pandas data frame is one of the core data structure that is used in the implementation. I have been thinking of how I can translate this code in a more robust type checking language such as Haskell, without loosing some of the conveniences Pandas provides. Do you have any suggestions or pointers to this?

I would love to encode the business logic into types. But, I am always afraid I might end up in type hell!

Re: The benefits of static typing without static typing in Python

#45

Post by nickpsecurity » Sun, Jan 24, 2016, 5:54 PM UTC

pka wrote: post #37

ptype wrote: post #9

Earlier quoted context omitted.

I hear this argument a lot, and I'm sure static typing is helpful when refactoring, but I have found that nothing is as important as tests when refactoring. I'd rather refactor dynamically typed code with good test coverage than statically typed code without good tests.

In addition to what the others said, I'd much rather prefer good static typing (i.e. Haskell). Especially in the prototyping phase, I do a lot of iterating and refactoring - and I mean A LOT, because I've found that this is the best way for a good design to fall out. Sometimes like 20-30% of the code get refactored, replacing core data structures and control flow. If I ever had to rely on unit tests for this, I'd sho…

What about tech that generated tests automatically from code and annotations? How do you think that would affect your work?

Re: The benefits of static typing without static typing in Python

#46

Post by nickpsecurity » Sun, Jan 24, 2016, 5:58 PM UTC

japhyr wrote: post #7

incepted wrote: post #4

The main advantage of static typing to me is that it enables automatic refactorings. Without types, it's impossible for tools to refactor your code safely without the supervision of a human. This leads to developers being afraid of refactoring and, ultimately, code bases rot and become huge piles of spaghetti that nobody wants to touch. With a statically typed language, I'm never afraid to refactor whenever I see an…

I haven't done large-scale refactoring work before. How does typing help with refactoring? Is it because you know exactly what's being passed into a function?

Refactoring changes how various chunks of code interact with each other. Types usually provide security against a limited set of bad interactions. Abstract or compound types can provide security against even more bad interactions, among other things. So, having simple, compiler-checked mechanisms for enforcing good interactions helps when you make changes that can cause bad interactions between chunks of code.

Re: The benefits of static typing without static typing in Python

#47

Post by spo81rty » Sun, Jan 24, 2016, 6:22 PM UTC

ptype wrote: post #9

incepted wrote: post #4

The main advantage of static typing to me is that it enables automatic refactorings. Without types, it's impossible for tools to refactor your code safely without the supervision of a human. This leads to developers being afraid of refactoring and, ultimately, code bases rot and become huge piles of spaghetti that nobody wants to touch. With a statically typed language, I'm never afraid to refactor whenever I see an…

I hear this argument a lot, and I'm sure static typing is helpful when refactoring, but I have found that nothing is as important as tests when refactoring. I'd rather refactor dynamically typed code with good test coverage than statically typed code without good tests.

As a C# developer I rarely write unit tests, because of static types and compilation identifying most problems. (plus Resharper) I only use them to test business logic or complex scenarios, which is what I would argue they are meant for. Not replacing a compiler.

Re: The benefits of static typing without static typing in Python

#48

Post by matt_kantor » Sun, Jan 24, 2016, 6:39 PM UTC

hibikir wrote: post #6

Optional typing like the one we see here is not uncommon in other dynamic languages: For instance, Clojure has core.typed and prismatic schema, which approach the problem in ways related to what the article shows. However, while optional typing gives you some benefits over purely dynamic typing, the fact that it's all bolted-on causes a variety of problems. First, there's the fact that you'll have code with types int…

I haven't had an opportunity to actually use it, so take this with a grain of salt, but the optional/gradual type system of TypeScript looks decently expressive (http://www.typescriptlang.org/Handbook).

Re: The benefits of static typing without static typing in Python

#49

Post by zimbatm » Sun, Jan 24, 2016, 7:19 PM UTC

hibikir wrote: post #6

Optional typing like the one we see here is not uncommon in other dynamic languages: For instance, Clojure has core.typed and prismatic schema, which approach the problem in ways related to what the article shows. However, while optional typing gives you some benefits over purely dynamic typing, the fact that it's all bolted-on causes a variety of problems. First, there's the fact that you'll have code with types int…

It's more helpful to think about classes of errors and what the type system prevents.

A simple type system prevents type mismatch errors. A more complex type system like Haskell's might be able to encode interfaces and other rules but might also has it's limits.

The trade-off is usually that the more classes of errors you remove, the more complex the type-system becomes. Over the lifetime of your program, how much time did you spend hunting bugs vs time spent in long compilations or encoding all the rules.

I guess my point is that a lite-weight type system might also be enough.

Re: The benefits of static typing without static typing in Python

#50

Post by tome » Sun, Jan 24, 2016, 7:48 PM UTC

zimbatm wrote: post #49

hibikir wrote: post #6

Optional typing like the one we see here is not uncommon in other dynamic languages: For instance, Clojure has core.typed and prismatic schema, which approach the problem in ways related to what the article shows. However, while optional typing gives you some benefits over purely dynamic typing, the fact that it's all bolted-on causes a variety of problems. First, there's the fact that you'll have code with types int…

It's more helpful to think about classes of errors and what the type system prevents. A simple type system prevents type mismatch errors. A more complex type system like Haskell's might be able to encode interfaces and other rules but might also has it's limits. The trade-off is usually that the more classes of errors you remove, the more complex the type-system becomes. Over the lifetime of your program, how much ti…

> time spent in long compilations

Type checking Haskell, for example, is actually incredibly fast and adds basically nothing to compilation time. This isn't one of the drawbacks of a type system.