Comment by mpdehaan2 | Hacker News Reader

Comment by mpdehaan2 | Hacker News Reader

Got to this:

"In an interesting way, it keeps you from going all-in on object-oriented programming. You only want to create a class when a casual API user will understand how it works and what they would use it for. "

Completely disagree. Python doesn't discourage OO at all. I think the author has a particular programming style with Python that does not line up with the way many people I know use it, and this may give the wrong impressions. Yes, you can just pass around tuples, but ... don't do this :) It has quite workable classes.

So, answering the question? What's the advantage? Dynamic language does require, to a degree, a small amount more tests. However, type errors are also a class of error that is very very infrequently encountered as to a problem.

I'd say that duck typing principly allowers easier mock interfaces and ability to more easily write generic-type functions, and for unrelated reasons, such languages have a very quick code-test loop. But their efficiency in this isn't so much to do with typing. It's mostly the speed of this loop, stemming from a lack of compilation, that helps. Those are not really related, but that's why people like dynamic languages.

They have also been historically more expressive, and saved typing things, for when type errors aren't really common (for me, they aren't), always specifying types doesn't always help. But to be honest, I don't mind it and it's nice to have as documentation most of the time.

I do mind compilation cycles.

The article also seems to err in that it assumes there can't be debuggers available for typed languages, where it says "you can't see inside the process".

The argument that people like dynamic systems because they build programs out of trial and error seems erroneous in all. I build my programs out of tests. This can still happen just the same and has nothing to do with a type system.

"However, type errors are also a class of error that is very very infrequently encountered as to a problem."

As someone working every day in Python, this seems mind-bogglingly divorced from reality.

I don't know if you mean something far more restricted by "type error" but most of the errors I encounter - in my code, the code of my team, and the code of those on other teams, across several projects - are errors that would have been caught by the type checker in Haskell had I been writing similar code. Many of them would have been caught by the type checker in C.

Hmm, that's curious, though I don't think it's ever a good idea to tell someone they are divorced by reality :)

I think some types of developers are more likely to make type error mistakes, and it's likely I make other mistakes, sure. I've done a wide about of massively-open source projects, and it doesn't really come up. The times I pass the wrong object type simply doesn't happen.

Do you use keyword arguments? These help a TON with argument order, and may be why you are having that problem.

When I write code and tests in JavaScript, typically the tests turn up a few typos and "brain-os" in the code (that don't keep it from parsing). Many or most of these would be caught by the type-checker in statically-typed language.

Maybe you don't "see" type errors because you consider them to be failures of test coverage, or you say, "That's not a bug, it's more of a typo?" Or you don't work on a shared codebase?

Neither. I don't make them often, and I do work in quite shared codebases - one of them had over 1000 contributors. I won't pretend I'm a better developer, I surely make other classes of mistakes, usually it's "I didn't consider the user scenario where this file didn't exist or the error path when this file has invalid contents should really raise a better exception than a generic stacktrace".

A static type checker could be of some help in both of those cases, if you use it well.

"I don't think it's ever a good idea to tell someone they are divorced by reality :)"

My statement was about the claim and about me - I meant to express (colorfully) the distance between the claim and my experience. I did not intend to cast aspersions on the claimant; I certainly apologize if I caused offense, though you seem to have taken it in good spirits regardless :)

Back to the topic at hand:

It sounds like you probably do consider a substantially narrower class of things "type errors" than I do. It is quite rare that I mix up arguments to a function. More commonly I see bad assumptions about the contents of a map, which is often a type error. The most common form of exception I see in Sentry seems to be "NoneType object has no attribute...", which is always a type error.

This. Python is strongly typed but the only runtime "checking" you get is the exception raised you try an operation on an object that doesn't implement an assumed interface.

GvR supports optional type checking in Python and has written a few documents laying out its defense, so it is in the works.

I have seen this "type errors are infrequent" argument many times and I think it stems from a confusion about what a type error is.

Many programmers who are only used to dynamic languages think it means something like the following in Java: "String foo = 5;".

But when you start learning something like Haskell you start noticing that many of the things you took for granted as "problems that just happen when you do programming" can actually be found at compile time and they will start frustrating you every time you see them.

Reply on news.ycombinator.com