@Charles About (i), this is of course true but weak typing doesn’t improve that. So the net bonus is still with strict typing. (ii) I don’t understand. (iii) is of course true.

Type checking can indeed catch some errors. But it also makes it hard to do certain things, and require you to often create more code to handle different types, or just cast thing to untyped pointers etc, which causes it's own set of problem. Programmers often believe that the lack of type checking will cause problems, and it feels a bit like jumping off a cliff in the beginning, but the fact is that it doesn't cause much problems, and avoids many others. The main drawback is not programming speed, but execution speed. ;-)

@Lennart Strong typing makes it harder to do certain things only in theory (yes, I know the type theory behind that). In practice, there’s no real restriction. And you’re wrong about having to handle more types – with a proper language you don’t have to do any more than with weak typing. You write that “weak typing avoids many [problems]” yet fail to name even one. That’s an extraordinary claim. The fact that programming speed in dynamic languages often seems to be on par with static languages is not, I claim, because of the type system but because those languages are more modern as a rule.

@KonradRudolph: I named them. You just say "No they don't"m which is not much of argumentation. The fact is that duck typing makes for less code and hence faster development, but as you note it can also lead to bugs, although in practice that's very rare. It's not an extraordinary claim, it's in fact pretty obvious once you have used dynamic languages for a while. Now, what you say in fact implies that Java isn't a modern programming language. THAT is an extra-ordinary claim.

@Lennart If you named them then I don’t see them. “The fact is that duck typing makes for less code and hence faster development” – that is not a fact. You are confusing correlation with causation; like I said, it just so happens that most dynamic languages are more modern in general and support faster development because of that, not because of dynamic typing. I have used both dynamic and statically, strictly typed languages for many years and I disagree strongly that your claim is “obvious”. I agree about Java but I’d say that this is an outlier: Java is just verbose by (dumb) design

@Lennart And to avoid a lengthy discussion (I just noticed this due to your use of the term “duck typing”): I think you are confusing “static typing” with “explicit typing”, and while I agree that many languages use these in parallel, they are actually pretty orthogonal and can be cleanly separated – I think Scala and Go do this, many functional languages do as well and elsewhere I’ve advocated a statically checked Python syntax.

I do think verbosity is a big part of this, and because you need less lines in languages like python they are faster to develop in. But dynamic typing is a part of that, and duck typing requires dynamic typing, ie that a variable can have any type. In static languages (explicit or not) you can not have duck typing because there is no "looks like a duck". If it is static, you know that it is a duck, or the compiler would have complained. If it does NOT complain, then your claim of less type bugs is moot.

This dynamic typing is of course only ONE of the reasons its faster to develop in Python. But I do think it is A reason, and I have argued why, and your response is just "no", which isn't an argument, and you in fact claimed that you expected the opposite result. We both agree that the typical dynamic language is faster to develop in, you just refuse to admit that this on one of the reasons.

@Lennart Sorry but I have to correct you here. You have not argued why dynamic typing is superior, you have merely asserted it. You have so far still failed to give a single argument for this. And despite your claims, I have actually given a reason for the opposite – namely that static type checking can prevent mistakes.

My first comment explains. You have not countered anything I said there. The short argument is: Duck typing means less code = faster development (and less bugs, which in turn leads to productivity according to you).

@Lennart That argument is still wrong: “Duck typing means less code” – this is simply false. You are again confusing dynamic typing and implicit typing (and implicit static typing absolutely works). The part of duck typing that results in less code is the fact that it’s implicit, not that it’s dynamic. Also, your claim that less code automatically equals faster development and less bugs is contentious (and in this case just wrong; it may be right all other things being equal – but all other things are not equal here).

No, this is wrong. I can only conclude that you don't know what dynamic typing means. You can't do duck typing without some form of dynamic typing, and once you have that form of dynamic typing, you can't have the compiler doing type checks. Your "all other parts not equal" argument is just a last straw. We are talking about dynamic typing, and it's presumed that all other parts are equal. My argument is stated above. You just say "no" and then show that you don't know what duck typing and dynamic typing means. Further discussion is pointless.

"In computer programming with object-oriented programming languages, duck typing is a style of dynamic typing in which an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface." en.wikipedia.org/wiki/Duck_typing

@Lennart I didn’t say that duck typing works with static typing. I said that the benefits that you derive from duck typing are simply because of its implicitness, not because of its dynamicity. “all other parts being equal” is relevant here since dynamic typing has salient disadvantages to static typing (early type checking finds errors!) which influence speed of development.

I will also take the opportunity, even though this isn’t the right place, to remark that having an argument with you is painful. I acknowledge that comments aren’t a perfect medium but you essentially reiterate your points again and again any apparent effort to engage my arguments. Then you accuse me of the same. We should both assume good faith on the part of the other. All I can do is reassure you that I’m interested in a genuine argument.

@KonradRudolph: I feel exactly the same about you. Yes, I reiterate my arguments over and over again. You have not offered any counter arguments. You just keep saying "no".

@LennartRegebro That is just not true, I have offered a counter-argument, you just keep ignoring it.

No you have not.

"benefits that you derive from duck typing are simply because of its implicitness, not because of its dynamicity." - That makes absolutely no sense. Duck typing requires dynamic typing. Without dynamic typing, no duck typing. Then claiming that the benefits of duck typing does not derive from dynamic typing makes absolutely no sense. Of course it does. Without dynamic typing, no duck typing. I also find it without base to say that duck typing is implicit. I don't agree with that statement.

@LennartRegebro What I am saying is this: duck typing gives you a benefit, that is true

but that benefit does not require all the features of duck typing, just some of it

to wit, the benefits deriving from the implicitness that duck typing gives you

"duck typing gives you a benefit, that is true" - OK, done, case closed, you agree with me.

but for this implicitness you do NOT need duck typing proper

and in fact some statically typed languages offer you the exact same benefits

I feel that yet again you didn't read what I wrote.

@LennartRegebro I did but I feel that without proper discussions we are turning in circles

Let me quote myself: Without dynamic typing, no duck typing.

You can't do duck typing without some form of dynamic typing, and once you have that form of dynamic typing, you can't have the compiler doing type checks.

I acknowledge all that, but it’s irrelevant

Then claiming that the benefits of duck typing does not derive from dynamic typing makes absolutely no sense. Of course it does. Without dynamic typing, no duck typing.

*what is the benefit that, according to you, duck typing conveys, that cannot be conveyed without duck typing (in a statically typed language)?

Explain how it's irrelevant?

The benefit is duck typing.

I also find it without base to say that duck typing is implicit. I don't agree with that statement.

@LennartRegebro Like I’ve said from the beginning, the advantage of duck typing is not a property of its dynamicity.

@LennartRegebro That is not a benefit

That's just using many words to say "no".

@LennartRegebro Then explain why duck typing is beneficial

@LennartRegebro Yes, because you have not offered a convincing argument, just an assertion: “duck typing is the benefit”

Duck typing leads to faster development by enabling a clearer, more flexible code base with less code.

@LennartRegebro And how does it do that?

Or, put differently, you can achieve the same goal without duck typing and static type checking

first of all, how it does that is obvious to anyone who has used a dynamic language for any period of time.

But for the benefit of you, I'll try to formulate it in words.

@LennartRegebro This makes it impossible to engage you in an argument. If you want me to be able to refute your points you need to be specific

Meanwhile maybe you can explain what YOU think the benefit of duck typing is?

@LennartRegebro Sure. It allows you to write generic code that works for different but similar kind of data without code duplication

Well, there you go.

you can do the exact same thing in statically typed languages

That's one of the ways it does it. But I'd go further than that.

No, you can't.

And it in fact allows you to write generic code that works for VERY DIFFERENT kinds of TYPES.

@LennartRegebro What the hell is that supposed to mean? Of course you can, C++ templates do exactly that, as do Haskell type classes

The data in itself doesn't need to be similar, the interface does.

… and F#, Ocaml, Eiffel, Go etc. also allow it

Yes, but with every step you take towards dynamic typing, you get less type checking.

@LennartRegebro Except that all these languages do this statically at compile time, not dynamically

So you can get some of the benefits of dynamic typing in essense by adding some dynamicism.

Yes, and to get all of the benefits, you have to stop doing that, and make it completely dynamic.

@LennartRegebro Please explain. You don’t need to do that.

okay sorry, I need to go – lunch break

I’ll be back later but after lunch I’ve got a meeting

I think I know where this discussion is going to end up.

The discussion is going to end up about when the compilation is done. You can have a static language that compiöes on demand, and if it then compiles the templates on demand to, then you in fact get run-time errors.

Which means it's not about static vs dynamic at all, but about getting the warning during the compilers syntax check pre-compilation. You can implement such a thing for dynamic languages as well if you want, and run it as a separate test.

Nobody has done that, because you don't need it, because the errors you get from the compiler is just a false security.

It feels good, and it feels like you can be more sure that the code does what it should, but that's just an illusion.

If you miss that compile feeling when using dynamic languages such as Python, run a lint before you run the tests. It's about as effective.

@LennartRegebro Claiming that static type checking is false security is a very strong claim, and one that would need extraordinary evidence to corroborate. In fact, static type checking provides the equivalent to tons of auto-generated tests which test all possible code paths for correctness on a well-defined feature set

That feature set is of course not comprehensive (so more tests will need to be written) but it’s explicitly codified in the type system (and, depending on the types you’re using, you can determine which features are going to be tested) and you can rely on the fact that there are no subtle errors in these tests (because they’re auto-generated by the compiler) and just in quantity and coverage they amount to the same as a huge amount of tests that you’d otherwise have to manually write

Not to speak of the automated and compiler-verified documentation that you get by using types

It is however still true, and common knowledge amongst developers of dynamic languages.

You do not in practice get very many runtime type errors on deployed, released apps. It's quite unusual. It is in practice not a big deal.

And in any case, the issue was about development speed.

Claiming that type checking amounts to "huge amounts of tests" is absolute baloney. Yes, you are right that static type checking amounts to checking all possible code paths for correctnes on a well defined feature set.

But calling it "not comprehensive" is over selling it. It tests all possible code paths fore correctness on one and exactly one feature set: That the type of the variable matches the type of the function. That's it.

So type checking will in no way amount to huge amounts of tests. You'll still have to write all those huge amounts of tests if you want to know that your application actually works. Because type checking catches only one of the multiple types of errors your code can have.

And in general, when you write your code, you also test that it works. And that catches pretty much any type error you will have.

Yes, it happens that your code makes an assumption in place X that the type will be a list of strings, and you forgot that the method also sometimes are called with just plain strings, and then it will fail when it reaches place X in a month because you didn't test that case.

But that's not only bad design to accept such wildly different types and then not immediately in the function call make them the same type, it is also not a common problem, as I mentioned.

With 12 years of full-time development as proof I tell you: This is just not a big issue.

I'm not asking you to like dynamic typing. That's up to you. I'm just telling you that the worry you feel when not having a compile-step is perfectly normal, and everyone has that. But that worry is not founded in reality.

Yes, static typing catches errors you wouldn't catch otherwise. But not very often. That's just how it is. If you want to disprove me, why don't you make some huge study on it or something.

But until then, all we have is the expectation you expressed, vs the experience of thousands of developers.

@LennartRegebro You seem not to know what type checking means: YOU determine what is checked, by implementing the relevant semantics in the types that you use

the salient example is in Joel Spolsky’s article about Hungarian Notation – you can implement the semantic distinction between safe and unsafe strings in your types so that the class of HTML injections cannot occur by design – any violation is caught by the compiler

So type checking is absolutely and definitively equivalent to a ton of test cases and documentation. That is in fact the salient property of statically typed systems. Everything else is besides the point.

And claiming that this class of runtime errors isn’t common is absolutely wrong. In fact, all the most common security vulnerabilities in web applications could be prevented by static type checks and properly written types.