> You even introduce a class of bugs doesn’t exist for statically typed languages.
Conversely, you're also able to write equivalent functionality with less code and with idioms you can't use in statically typed languages. It's an engineering trade off, the static typed handcuffs prevent you from making a certain kind of mistake but they also prevent you from writing certain kinds of code that are extremely powerful; many prefer the power over the handcuffs. Type bugs just aren't that painful.
I've had professional jobs writing both Python and Haskell. My Python code has to be far more verbose and complex than my Haskell, and the Python's harder to maintain too!
> Type bugs just aren't that painful.
You haven't learned the true power of a decent type system then.
While certainly Haskell lets you do more, you can get some interesting help from even the C type system. For instance, I was able to enforce "this can only be called from the main thread" with no runtime overhead.
You explained this once to me before and it was very cool. Did you ever write a blog post about it? I think it would be neat to link to in the future when these sort of discussions come up.
> You haven't learned the true power of a decent type system then.
Conversely you haven't learned the true power of dynamic types or like coding with handcuffs to keep you safe. What static types offer me is not as useful to me as what they forbid me from doing, so no it isn't an issue what what I don't know, but rather of what I do. And Haskell, no thanks, I'm not a masochist.
> and the Python's harder to maintain too!
That's an issue with Python, not with dynamic types. My Smalltalk code is a joy to maintain.
And what exactly do static types forbid you from doing? (For the sake of argument let's consider state of the art static type systems such as those found in Haskell, OCaml, Elm and Purescript)
State of the art is hardly relevant, what's relevant are languages in demand by employees that dynamic language are actually in competition with so no I don't accept that restriction for the sake of the argument as it's moving the goalpost. However plenty of meta-programming techniques including the use of dynamically interpreting message sends to methods that don't exist in the context of the receiver, i.e. Smalltalk's doesNotUnderstand or Ruby's method missing are but one example.
Look, I get it, you like static typing, how about accepting that we all don't; we value different things from a language, and extreme late binding in all things is something we value more than being protected from ourselves with a type system. Don't assert to others what they have or haven't learned just because their preferences differ from yours.
I think you're responding to an argument I didn't make.
You claimed "Type bugs just aren't that painful". Haskell allows you to make all sorts of bugs into type bugs, from SQL well-formedness, through certain concurrency guarantees, to guarantees that your HTTP routing is correct. So yes, type bugs can be very painful, and that's a good thing!
Using Haskell is more painful than any type bugs it might help fix, no thanks. One can write correct code without a type system to guarantee it for them, we're fine doing this rather than dealing with said pain in the ass type system. Haskell is not my idea of a good programming language, it's not what I want from a programming language, it's not conducive to how I want to program. It's an esoteric language for a reason, few people like it and it'll likely remain that way.
OK, if that's your opinion then fine. I just wanted to challenge your claim "type bugs just aren't that painful". On the contrary, they can be and should be!
You can't challenge a claim about how I feel about something, if I say something doesn't hurt, nothing you can say will convince me it does. Pain is subjective, keep that in mind when trying to tell others how they feel about something.
> you're also able to write equivalent functionality with less code
The amount of code one writes says more about the language than whether or not it's statically typed.
To me, adding "bigint" or "bool" to the occasional variable and function declaration isn't "more code", it's an extremely terse way of avoiding different code (e.g. type assertions).
That's not what I mean by more code, by taking advantage of dynamic typing you can write more generic code than is even possible with generics in a statically typed language; code that works for any type, whereas a static language either forbids you or forces you to write multiple versions of the function. You can't write a single Max function in C# that works for any type supporting >=, it simply can't be done. This is typical of static languages, they forbid perfectly good code because it "might" be used inappropriately or because the type system can't guarantee it won't.
> by taking advantage of dynamic typing you can write more generic code than is even possible with generics in a statically typed language; code that works for any type, whereas a static language either forbids you or forces you to write multiple versions of the function.
If you can write code that works for some combination of types, it's because those types present a common interface that could be specified in a sufficiently-expressive static type system, either via something like OOP interfaces or something like Haskell typeclasses.
> You can't write a single Max function in C# that works for any type supporting >=, it simply can't be done.
You can, in fact, do so for any type supporting the IComparable<T> interface. That the operators are defined independently is a C# type-system quirk, not a fundamental limitation of static type systems.
> that could be specified in a sufficiently-expressive static type system
Ah the mythical sufficiently-expressive static type system, I'm concerned with type systems that are in use in real jobs, not vaporware ones that could exist if only. Dynamic language support it now.
> You can, in fact, do so for any type supporting the IComparable<T> interface.
Which requires forethought on the designers of said library, I'd rather have duck typing which works without requiring correct future planning with interfaces.
Nothing is stopping languages from allowing both. For example, it could have some form of compound type declaration.
Meanwhile, how often is code made worse because you have to write multiple Max implementations? And I doubt that there's many instances where such repetition is necessary, or can't be mitigated with wrapper functions.
> Nothing is stopping languages from allowing both
Nothing stops pigs from flying either... hypothetically, but they don't, and languages don't, so debating what they could do is rather pointless, they don't.
> how often is code made worse because you have to write multiple Max implementations
Similar situations occur quite often.
> I doubt that there's many instances where such repetition is necessary, or can't be mitigated with wrapper functions.
That they have to be mitigated is the point, I don't have to do stuff like this at all in a dynamic language, things just work.
Congratulations, you have worked out that there are no perfect languages. I don't understand what point you're trying to make, other than you prefer one set of trade-offs to another.
The biggest advantage of dynamically typed languages is the ease of using deeply nested data structures with mixed data types. This is just a pain in languages like Java and Scala where the Any type is often reverted to.
Conversely, you're also able to write equivalent functionality with less code and with idioms you can't use in statically typed languages. It's an engineering trade off, the static typed handcuffs prevent you from making a certain kind of mistake but they also prevent you from writing certain kinds of code that are extremely powerful; many prefer the power over the handcuffs. Type bugs just aren't that painful.