31–40 of 75 posts
Having no experience with using gradual typing, I wonder if there's any stable equilibrium here between "thoroughly dynamic" and "type declarations everywhere".
In any case, as someone who started with Python and started preferring static types later on, I really hope this gets used.
Earlier quoted context omitted.
Having used Haskell a lot, I still feel pretty fine about C++ or C# type systems. It's Java's that drives me absolutely insane. Type erasure makes me want to pull my hair out.
I agree that Java is painful to use, but why is type erasure the annoyance that you need to single out? Haskell does type erasure as well.
Earlier quoted context omitted.
No, but let me clarify. Bolting on a form of type checking to a weakly typed language seems orthogonal to the nature of a language like Python. If you find yourself saying "I wish I had a type system in this code base, its getting pretty big and a compiler that does type checking at compile time sure would make my life easier" maybe you should think about using a more appropriate tool. I use Python a lot and it has i…
Though I agree with your sentiment, I must mention that there is nothing "weak" about Python's type system. You likely meant "dynamic", not "weak". See here: wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language
Earlier quoted context omitted.
Would you like to reconsider your tone?
No, but let me clarify. Bolting on a form of type checking to a weakly typed language seems orthogonal to the nature of a language like Python. If you find yourself saying "I wish I had a type system in this code base, its getting pretty big and a compiler that does type checking at compile time sure would make my life easier" maybe you should think about using a more appropriate tool. I use Python a lot and it has i…
Even if people are only using it as a shim for what could be static typechecking, I think there's something to say about the practicality of it existing, if only for the reason that their ecosystem might already be Python-based.
One of the reasons why I use Python 3.x exclusively is for the new function annotations, which allow use of this: https://github.com/prechelt/typecheck-decorator This allows me to write Python in a design-by-contract style with full, rich runtime type checks. My bug count has gone down dramatically, and when I do find a bug it's virtually always via a typecheck exception.
This might sound odd, but lately I haven't noticed any bugs I've introduced to production that were type errors. Inevitably my code will produce results of the right type, but have a logical error that makes either the answer flat out wrong or more or less inaccurate based on our cloud requirements.
So python becomes nim now? I wish they kept separate ways. Python for simple and powerful hobbyist programs and nim for the enterprise. If we have two languages doing the same thing, we will abandon one group of enthusiasts. Then another language will come to fill the gap.
[1] As opposed to implementations... because I don't know what kind of crazy compiler (JIT or AOT) they do nowadays to make "slow" languages fast. So for all I know Python can still be fast, given enough manpower.
Earlier quoted context omitted.
I encourage all use of the type system to ensure program correctness, but once you've had Hindley-Milner inference, it's hard to muddle along with something like this.
It really is. Since using Haskell, the type systems in the mainstream languages I've used have seemed sorely lacking.
Though maybe you could restrict how expressive the type system is on something like a module (Haskell module) level, so that you can have type inference if you give up on some power? I don't know.
Earlier quoted context omitted.
Though I agree with your sentiment, I must mention that there is nothing "weak" about Python's type system. You likely meant "dynamic", not "weak". See here: wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language
Python's type system is weak whether they self-identify that way or not. Types are implicitly converted in a variety of cases, notably True-ness. Meanwhile, runtime type identity is kind of meaningless; classes and individual objects can have their behavior meaningfully changed at runtime. The most you can say about any variable in Python is that it is a descendant of 'object' or else some primitive type.
Earlier quoted context omitted.
Having used Haskell a lot, I still feel pretty fine about C++ or C# type systems. It's Java's that drives me absolutely insane. Type erasure makes me want to pull my hair out.
I agree that Java is painful to use, but why is type erasure the annoyance that you need to single out? Haskell does type erasure as well.
0: http://stackoverflow.com/questions/12468722/does-haskell-era...
Earlier quoted context omitted.
This might sound odd, but lately I haven't noticed any bugs I've introduced to production that were type errors. Inevitably my code will produce results of the right type, but have a logical error that makes either the answer flat out wrong or more or less inaccurate based on our cloud requirements.
You can encode logic into types making what were previous runtime logic errors compile time errors.