I'm not sure I agree with one of your axioms ... the major problem is that I'm not used to thinking about type at all
Yeah - I didn't communicate it very well. I don't (and didn't) believe that you're thinking about types when the compiler could be doing it for you, but that you're thinking about other things which give you the same guarantees, when the compiler could be doing it for you, via the abstraction of types.
Does that make any more sense? I know what I mean, but the words are coming slowly today ;)
Python will die with a type error ... Does anyone here get this?
So, I think this may be part of the same thing, but first I'll answer the question directly:
The python programmer wants "4" + 3 to die, because he might have meant 4 + 3 (7) or he might have meant "4" + "3" ("43"). For every compiler which assumes one of the two, there's a legion of programmers who expected the other in some circumstance, and a universe of bugs caused by that expectation.
The python language deals with the ambiguity by disallowing it, while the perl language deals with the ambiguity by declaring one of them to be correct, and forces all perl programmers to remember which one. Python programmers don't have to remember a list of default behaviours - an error is an error. If your programme dies because of that error, you know why - the error contains the line number. Make the same mistake in perl and you get a weird behaviour a long way down the line, which you have to spend time and effort tracing back to that mistake.
The advantage of dynamic strong typing over static strong typing is that sometimes you know what the type of a variable will be, but you can't convince the compiler of it at compile time (remember casting in java before the generic collections came along?). I've never run into this problem in haskell - the polymorphism works really well.
The reason that I think it's a part of the same thing is this:
With my strongly typed hat on, "4" + 3 is just wrong. It doesn't make any sense. This has nothing to do with how it'll behave when the programme runs. I'm not worrying about behaviour, or errors, or bugs. I'm not even thinking about running the programme yet - I'm thinking about the data. It's just a grammatically incorrect non-sentence. I'm not using the type system as a safety net to catch mistakes in a programme which I've written by thinking about behaviour - instead I'm writing a programme by thinking about types.
I think this is closer to the python mindset. Whether that "wrongness" is best revealed to them at compile time or test time is a whole other issue - the key thing is the undeniable wrongness of the statement.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Yeah - I didn't communicate it very well. I don't (and didn't) believe that you're thinking about types when the compiler could be doing it for you, but that you're thinking about other things which give you the same guarantees, when the compiler could be doing it for you, via the abstraction of types.
Does that make any more sense? I know what I mean, but the words are coming slowly today ;)
So, I think this may be part of the same thing, but first I'll answer the question directly:
The python programmer wants "4" + 3 to die, because he might have meant 4 + 3 (7) or he might have meant "4" + "3" ("43"). For every compiler which assumes one of the two, there's a legion of programmers who expected the other in some circumstance, and a universe of bugs caused by that expectation.
The python language deals with the ambiguity by disallowing it, while the perl language deals with the ambiguity by declaring one of them to be correct, and forces all perl programmers to remember which one. Python programmers don't have to remember a list of default behaviours - an error is an error. If your programme dies because of that error, you know why - the error contains the line number. Make the same mistake in perl and you get a weird behaviour a long way down the line, which you have to spend time and effort tracing back to that mistake.
The advantage of dynamic strong typing over static strong typing is that sometimes you know what the type of a variable will be, but you can't convince the compiler of it at compile time (remember casting in java before the generic collections came along?). I've never run into this problem in haskell - the polymorphism works really well.
The reason that I think it's a part of the same thing is this:
With my strongly typed hat on, "4" + 3 is just wrong. It doesn't make any sense. This has nothing to do with how it'll behave when the programme runs. I'm not worrying about behaviour, or errors, or bugs. I'm not even thinking about running the programme yet - I'm thinking about the data. It's just a grammatically incorrect non-sentence. I'm not using the type system as a safety net to catch mistakes in a programme which I've written by thinking about behaviour - instead I'm writing a programme by thinking about types.
I think this is closer to the python mindset. Whether that "wrongness" is best revealed to them at compile time or test time is a whole other issue - the key thing is the undeniable wrongness of the statement.
Does that make sense?