5 ms·

How? I don't think I've ever gotten a type I wasn't expecting in any of my python code. It's just not a problem for me. That is, past the first time I run it.

How? I don't think I've ever gotten a type I wasn't expecting in any of my python code. It's just not a problem for me. That is, past the first time I run it. I've been known to pass something an x when it wanted a y, but that's a "fail early, fail loud" bug and not an actual problem.

zwerdlds 9y ago
So, I have a tiny bit of experience with Python. What I think you're describing is a good representation of my experience: If you're not branching too much, or you unit test enough, Python can be really, fabulously, great. If your logic is complex, the solace that having a really good type system (eg tagged unions paired with pattern matching) is that your edge cases are handled. Maybe not according to your business rules, but at least you'll find fewer runtime errors. Python is a tool. I think of it similar to Legos: it allows you to build small units of work. But when the work gets more complex, it's time to look at something that can handle that complexity. This was posted the other day, and probably communicates my point about runtime/compiler time identification of issues better: http://samwho.co.uk/blog/2017/09/06/move-your-bugs-to-the-left/ http://samwho.co.uk/blog/2017/09/06/move-your-bugs-to-the-le...
newen 9y ago
Well the obvious problem is that you have to test all of the code paths before deciding that your code is type safe. Static types do not have that problem.
contravariant 9y ago
This just means that you already have an idea of what kind of object should go where, you just never wrote it down. And because you never wrote it down it becomes hard to generalise things when you eventually want to reuse some method, since you never made explicit which operations an object should support to be able to reuse that method. Also you have no guarantee that what you think the types should be is actually consistent.
everheardofc 9y ago
Unfortunately in my experience I don't know what type of x I'm supposed pass into to. I either have to guess what x is out of a infinite search space or I have to look at the implementation but unfortunately it also calls some other functions so I need to determine the possible inputs for that function and repeat this until I've read 100s of lines of code just to use a single function because someone thought that documentation is uneccessary and 10 seconds of less typing were worth the tradeoff. Static typing is statically enforced documentation. Sure you might be lucky and already have voluntary documentation available but I am not. I'm getting sick of randomly being stuck for 10 hours on some trivial problem caused by wrong incentives.

zwerdlds 9y ago

So, I have a tiny bit of experience with Python. What I think you're describing is a good representation of my experience: If you're not branching too much, or you unit test enough, Python can be really, fabulously, great. If your logic is complex, the solace that having a really good type system (eg tagged unions paired with pattern matching) is that your edge cases are handled. Maybe not according to your business rules, but at least you'll find fewer runtime errors. Python is a tool. I think of it similar to Legos: it allows you to build small units of work. But when the work gets more complex, it's time to look at something that can handle that complexity. This was posted the other day, and probably communicates my point about runtime/compiler time identification of issues better: http://samwho.co.uk/blog/2017/09/06/move-your-bugs-to-the-left/ http://samwho.co.uk/blog/2017/09/06/move-your-bugs-to-the-le...

newen 9y ago

Well the obvious problem is that you have to test all of the code paths before deciding that your code is type safe. Static types do not have that problem.

contravariant 9y ago

This just means that you already have an idea of what kind of object should go where, you just never wrote it down. And because you never wrote it down it becomes hard to generalise things when you eventually want to reuse some method, since you never made explicit which operations an object should support to be able to reuse that method. Also you have no guarantee that what you think the types should be is actually consistent.

everheardofc 9y ago

Unfortunately in my experience I don't know what type of x I'm supposed pass into to. I either have to guess what x is out of a infinite search space or I have to look at the implementation but unfortunately it also calls some other functions so I need to determine the possible inputs for that function and repeat this until I've read 100s of lines of code just to use a single function because someone thought that documentation is uneccessary and 10 seconds of less typing were worth the tradeoff. Static typing is statically enforced documentation. Sure you might be lucky and already have voluntary documentation available but I am not. I'm getting sick of randomly being stuck for 10 hours on some trivial problem caused by wrong incentives.