3 ms·

I'm a python hater. Yes it is easy, but in exactly the wrong way. Easy for simple code for middle schoolers. For grownups with large codebases to develop and ma

I'm a python hater. Yes it is easy, but in exactly the wrong way. Easy for simple code for middle schoolers. For grownups with large codebases to develop and maintain, it's not optimal. Of course I hate the whitespace trickery. I hate the auto formatting that sometimes doesn't work. Those are fairly minor. What I really, really hate is the lack of static typechecking. You often have to read lengthy swathes of code to understand how functions are actually used. The conventions in the community are terrible. I have used respected libraries where functions are designed to return a variety of types, just because, so you need to dynamically typecheck your results. Gawd. And just as bad the fact it is impossible to encapsulate code. This underscore nonsense, don't even mention it. Sheesh. I have found that in real life, internals bleed out over the code base making code more fragile over time and harder to refactor. It has all these open source scientific libraries because professional programmers were working on other things, and that is truly unfortunate. The lack of seriousness is demonstrated by the fact that it's frozen in time in terms of runtime data structures because cpython knows and relies on those internals. Nutso. And then the GIL!! What the ?@.

xtracto 8y ago
I used to program in Python, and found Ruby as a language to give me everything Python provides but with a more Programmer friendly syntax. I never understood why you would use a function like len() in an Object Oriented Language (instead of x.len ) or having to explicitly add self to every method...
- orf 8y ago
  > I never understood why you would use a function like len() in an Object Oriented Language (instead of x.len ) or having to explicitly add self to every method... The answer is simple: there is a x.len function. It's just x.__len__, the protocol. Forcing it to be exposed on every type is a waste: do you use .len, .length, .size? This duck-typing allows any object that supports the length protocol to be passed to `len()`. Simple. Having it add itself to every object is.... not what you want at all. Some objects don't have a length.
ubernostrum 8y ago
Easy for simple code for middle schoolers. For grownups with large codebases to develop and maintain, it's not optimal. Yes, like the tiny puny baby middle-school children who built microscopic useless toy "programs" (not even worthy of the name) at Instagram, YouTube, Dropbox... What I really, really hate is the lack of static typechecking. Then don't use dynamically-typed languages. Not everyone shares your tastes, nor do they have to. And just as bad the fact it is impossible to encapsulate code. The more you write here, the more I think C# is a great language for you. And I don't dislike C#! But you want a nice statically-typed object-oriented language with data hiding. C# is an example of one. Python is not. And then the GIL!! I've written at length about how the existence of the GIL is the result of tradeoffs that seemed perfectly reasonable at the time (keeping in mind that Python is older than Java, and I suspect older than the average HN commenter). With 20/20 hindsight would a different approach have been better? Sure, but if they'd had the ability to see the future in enough detail, the folks who chose those tradeoffs probably would have bought lottery tickets instead of building Python.
coryfklein 8y ago
While it is technically feasible to write a maintainable and well-organized large codebase in Python, in practice the lack of static types leads to a giant mess. After trying to maintain a legacy system written in Python (where all the authors had left the company) for a year, I threw my hands up and moved on to a Scala shop. I vowed to never work again on any major project written in a language without static typing. I think this lesson has been learned in the broader community though. Even most of my colleagues that have used Javascript for years have moved on to Typescript and never looked back. I even disagree with the, "well it's good for small projects" line of thinking. Look - if it works there, it's only because you have net fewer bugs to catch and lines to read, so the cognitive overhead can be born. But why not dispense with that cognitive overhead in the first place and just use static types! The one exception I make here is for shell scripting. The tight integration with the command line just makes bash the best choice for some situations. But even then, I have about a 50% success rate of estimating whether or not this "little script" will ever grow to become a production application with multiple modules and components, so today I'm even wary of using shell scripts in many cases.
- lmm 8y ago
  > Look - if it works there, it's only because you have net fewer bugs to catch and lines to read, so the cognitive overhead can be born. But why not dispense with that cognitive overhead in the first place and just use static types! I'm not convinced. When a program really is small enough to hold the whole thing in your head, writing that knowledge down is just overhead. (Of course, this reverses as soon as the program gets bigger than that).

xtracto 8y ago

I used to program in Python, and found Ruby as a language to give me everything Python provides but with a more Programmer friendly syntax. I never understood why you would use a function like len() in an Object Oriented Language (instead of x.len ) or having to explicitly add self to every method...

orf 8y ago
> I never understood why you would use a function like len() in an Object Oriented Language (instead of x.len ) or having to explicitly add self to every method... The answer is simple: there is a x.len function. It's just x.__len__, the protocol. Forcing it to be exposed on every type is a waste: do you use .len, .length, .size? This duck-typing allows any object that supports the length protocol to be passed to `len()`. Simple. Having it add itself to every object is.... not what you want at all. Some objects don't have a length.

ubernostrum 8y ago

Easy for simple code for middle schoolers. For grownups with large codebases to develop and maintain, it's not optimal. Yes, like the tiny puny baby middle-school children who built microscopic useless toy "programs" (not even worthy of the name) at Instagram, YouTube, Dropbox... What I really, really hate is the lack of static typechecking. Then don't use dynamically-typed languages. Not everyone shares your tastes, nor do they have to. And just as bad the fact it is impossible to encapsulate code. The more you write here, the more I think C# is a great language for you. And I don't dislike C#! But you want a nice statically-typed object-oriented language with data hiding. C# is an example of one. Python is not. And then the GIL!! I've written at length about how the existence of the GIL is the result of tradeoffs that seemed perfectly reasonable at the time (keeping in mind that Python is older than Java, and I suspect older than the average HN commenter). With 20/20 hindsight would a different approach have been better? Sure, but if they'd had the ability to see the future in enough detail, the folks who chose those tradeoffs probably would have bought lottery tickets instead of building Python.

coryfklein 8y ago

While it is technically feasible to write a maintainable and well-organized large codebase in Python, in practice the lack of static types leads to a giant mess. After trying to maintain a legacy system written in Python (where all the authors had left the company) for a year, I threw my hands up and moved on to a Scala shop. I vowed to never work again on any major project written in a language without static typing. I think this lesson has been learned in the broader community though. Even most of my colleagues that have used Javascript for years have moved on to Typescript and never looked back. I even disagree with the, "well it's good for small projects" line of thinking. Look - if it works there, it's only because you have net fewer bugs to catch and lines to read, so the cognitive overhead can be born. But why not dispense with that cognitive overhead in the first place and just use static types! The one exception I make here is for shell scripting. The tight integration with the command line just makes bash the best choice for some situations. But even then, I have about a 50% success rate of estimating whether or not this "little script" will ever grow to become a production application with multiple modules and components, so today I'm even wary of using shell scripts in many cases.

lmm 8y ago
> Look - if it works there, it's only because you have net fewer bugs to catch and lines to read, so the cognitive overhead can be born. But why not dispense with that cognitive overhead in the first place and just use static types! I'm not convinced. When a program really is small enough to hold the whole thing in your head, writing that knowledge down is just overhead. (Of course, this reverses as soon as the program gets bigger than that).