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.
> Type bugs just aren't that painful.
You haven't learned the true power of a decent type system then.
And yes, Haskell is terse. Other popular statically typed languages (Go, Kotlin, TypeScript, Dart) are not.
Haskell, OCaml, Elm, Purescript, arguably Scala although I don't like it personalyl.
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.
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.
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!
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).
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.
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.
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 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.
So you can understand the point being made, congratulations, it's what engineering is all about.
Dynamic languages excel at fast initial development and "gimmicky" code (wildfire monkey patching, introspection, dynamic code generation etc.), and to get there you pay dearly. Practically all other properties suffer; stability, maintainability, performance, memory usage, ease of deployment, distribution and so on and so forth.
That doesn't mean that dynamic languages have no place, or applications developed using them are somehow generally inferior to those written in statically typed languages; choice of language is only one mosaic stone of many. But it is also a foundation stone, and dictates many constraints, both technical, and social.
If print() in Python includes a string and an int, I think the interpreter should be able to implicitly cast my int to string in order to make it all work. As it stands, I have to go back in and cast it myself, which kills productivity.
Any idea as to why implicit casts aren't more supported in strictly typed languages?
I'd prefer a warning on runtime than having to go back to the code.
That's the difference between weakly and strongly typed. If you take a strongly typed language, and add implicit casting, you get a weakly typed language.
How this is resolved (or if at all) depends a lot on the language. For example, in C++ it is straightforward to define implicit conversions (which can become confusing). In Python on the other hand, it is generally up to the receiver to call some kind of conversion function, like str(), which will use an object protocol (like __str__) on the instance. This is what print("foo", 1) does, or "foo %s" % 1.
As type systems vary, almost every statically-typed language allows some errors of the class statically-typed languages, in general, can prevent, so this is not really true.
What is true is that on the continuum from no static validation to something like Idris or Agda, you accept more statically-avoidable type errors the closer you are to the former rather than the latter.