5 ms·
I think the author has good points, but from where I sit they seem fairly subjective. I've written Python for several years, and as a result the way I reason a
by LyndsySimon 9y ago
I think the author has good points, but from where I sit they seem fairly subjective.
I've written Python for several years, and as a result the way I reason about problems have been heavily influenced by it.
I'm fluent in Ruby as well, but it takes mental effort for me to conform to its "flow", for lack of a better term. My time in Ruby has made me a better Python programmer, too - I understand more fully the idea of a DSL and how it should work. Ruby is great for writing DSLs and writing concise code that's guided by the language of the domain in which you're working.
I'm competent in Clojure, which if nothing else has given me a distinct distaste for impure functions - if a Python function takes an array, it should not modify that array in place unless it's very clear from the name that's it's going to do so, and a function should not both modify its input and return it.
At the end of the day, Python is still the language that I reach for whenever I'm writing pretty much any personal project. It's clean, easy to read, and the overall feel of the language guides me to write maintainable code.
- crimsonalucard 9y agoDon't get how any competent programmer can recognize a glaring flaw... type checking. A program without type checking will inevitably lead to less maintainable code.
- joshuamorton 9y agoModern python supports optional type checking.
- kyberias 9y agoWhat is modern python?
- joshuamorton 9y ago3.4+ (really 3+ with syntactical support, and really 2.7+ with comment support).
- scriptkiddy 9y agoPython does type check - at runtime. That said, I understand where you're coming from. Maybe it's because I'm very familiar with Python, but lack of static typing has not been a problem for me in a long time. If I really need to be sure that something is the correct type, i can try to catch `TypeError` and handle it. Not the most terse of methods, but I rarely find that I'm all that concerned with types in my Python work.
- KirinDave 9y agoI think you fundamentally misunderstand what type checking is.
- scriptkiddy 9y agoI don't think so. I think you're referring to static type checking. I'm referring to dynamic/runtime type checking. For instance, `1 + "hello"` will throw a `TypeError` at runtime because the `+` operator is not supported for use with `str` and `int` types. In a statically typed language, the code would not run or compile unless a `+` operator has been defined that takes a `str` type as it's first argument and an `int` type as it's second argument. I guess you could say that a `TypeError` at runtime isn't really "type checking" in a sense. I guess it would be more like "type enforcement".
- KirinDave 9y ago> I don't think so. I think you're referring to static type checking. I'm referring to dynamic/runtime type checking. No, you're referring to type-related errors at runtime. That's not checking. Nothing is checked. Code breaks and may recover, but it has no idea what the types of the arguments to the offending expression were, only that it didn't work with that bit of code. This is not type checking. > I guess you could say that a `TypeError` at runtime isn't really "type checking" in a sense. I guess it would be more like "type enforcement". All it does is say, "This code cannot execute with this implicit prior state." It has nothing to do with types except in the most tangential way.
- someSven 9y agoIsn't this covered by IDEs, which warn you when switching the type?