> well, with Python that doesn't happen. At least, not at all frequently.
That's a bold statement. It happened to me just last week.
The difference from Perl is that common tasks are standardized ... stuff like OOP is built-in, so you don't have to chose or stay in touch with several frameworks for doing OOP, and you could care less about integration issues between modules that use different OOP systems.
It also has a clean syntax, which makes (good code, written by good developers) readable ... but that's not what bugs me about Perl ... after all, why should you read text in some language (natural or not) if you haven't bothered to learn it?
That's about it. Otherwise I'm beginning to hate Python's limitations.
>> well, with Python that doesn't happen. At least, not at all frequently.
> That's a bold statement. It happened to me just last week.
Look, different strokes for different folks: I'm not trying to suggest that you should use Python; I'm explaining why I do.
That said, anecdote ≠ data. Your cited experience doesn't match up with what I've seen in a decade as a Python developer, and, more importantly, it doesn't match up with the data I've seen [1] suggesting that Python code takes 1/2 to 1/4 as much time to maintain as other comparable languages.
When I choose Python, it's because I know that the vast majority of my time is spent maintaining code (mine and other people's), not writing new code. I choose Python because, of all the languages I've tried in my career, it's the one that makes this task easiest.
[1] To forestal the obvious questions: no none of this data is publicly available (at least to my knowledge). I can share some rough details -- contact me privately if you want them -- but you'll pretty much have to either believe that I'm reliable or decide that I'm full of shit. I don't much care either way -- again, this is about my choices, not evangelism.
>>> well, with Python that doesn't happen. At least, not at all frequently.
>> That's a bold statement. It happened to me just last week.
>Look, different strokes for different folks: I'm not trying to suggest that you should use Python; I'm explaining why I do.
You made a pretty definitive assertion, and when someone points out that they had an experience to the contrary you say "different strokes for different folks"? Seriously?
I like Python a lot. I've been using it for about 12 years now. My experience doesn't really line up with yours.
I've found that Python is great for writing small (<2000 loc) programs. However, every single time I've seen a large project written in Python it's ended up collapsing under its own weight.
I'm sure I'll get flamed for saying this, but I think part of the problem is Python's dynamic nature. Python is the dynamic language I have the most experience with, so perhaps I'm over-generalizing, but the problem I've seen with large Python projects is that they get to a point where a major refactoring is needed and it's impossible to pull it off because of the dynamic nature of the language. Perhaps with 100% test coverage things would be easier, but in the real world that's rare/nonexistent. (Also, I find that more tests are necessary in Python than in a static language because you end up having to test a lot of the same things your static language would have been proving for you.) In the bigger Python projects I've seen they eventually rewrote the whole system in a static language.
My opinion very subjective ... I'm looking for 2 things out of a programming language ...
1) (proper) anonymous code blocks ... it's the only sane way to have declarative APIs, although I've found for some tasks that Python's features (like decorators, meta-classes) are enough ... but not for all things I want to do
2) a limited form of macro support ... like, I want to get the syntax-tree out of a closure, instead of a reference to the compiled method ... to abstract the way some processing takes place. In Python you can workaround it with some magic (a la Django's ORM), but I love to be able to write Python syntax for those queries (e.g. something like Linq) ... and have for example a unified querying interface for collections of data
> 1) (proper) anonymous code blocks ... it's the only sane way to have declarative APIs, although I've found for some tasks that Python's features (like decorators, meta-classes) are enough ... but not for all things I want to do [.]
Is the anonymous bit necessary? Or asking another way: What about throw-away names? I find that even in Haskell I rarely use lambdas, but tend to name nearly all of my functions.
Comments
> well, with Python that doesn't happen. At least, not at all frequently.
That's a bold statement. It happened to me just last week.
The difference from Perl is that common tasks are standardized ... stuff like OOP is built-in, so you don't have to chose or stay in touch with several frameworks for doing OOP, and you could care less about integration issues between modules that use different OOP systems.
It also has a clean syntax, which makes (good code, written by good developers) readable ... but that's not what bugs me about Perl ... after all, why should you read text in some language (natural or not) if you haven't bothered to learn it?
That's about it. Otherwise I'm beginning to hate Python's limitations.
>> well, with Python that doesn't happen. At least, not at all frequently.
> That's a bold statement. It happened to me just last week.
Look, different strokes for different folks: I'm not trying to suggest that you should use Python; I'm explaining why I do.
That said, anecdote ≠ data. Your cited experience doesn't match up with what I've seen in a decade as a Python developer, and, more importantly, it doesn't match up with the data I've seen [1] suggesting that Python code takes 1/2 to 1/4 as much time to maintain as other comparable languages.
When I choose Python, it's because I know that the vast majority of my time is spent maintaining code (mine and other people's), not writing new code. I choose Python because, of all the languages I've tried in my career, it's the one that makes this task easiest.
[1] To forestal the obvious questions: no none of this data is publicly available (at least to my knowledge). I can share some rough details -- contact me privately if you want them -- but you'll pretty much have to either believe that I'm reliable or decide that I'm full of shit. I don't much care either way -- again, this is about my choices, not evangelism.
>>> well, with Python that doesn't happen. At least, not at all frequently.
>> That's a bold statement. It happened to me just last week.
>Look, different strokes for different folks: I'm not trying to suggest that you should use Python; I'm explaining why I do.
You made a pretty definitive assertion, and when someone points out that they had an experience to the contrary you say "different strokes for different folks"? Seriously?
I like Python a lot. I've been using it for about 12 years now. My experience doesn't really line up with yours.
I've found that Python is great for writing small (<2000 loc) programs. However, every single time I've seen a large project written in Python it's ended up collapsing under its own weight.
I'm sure I'll get flamed for saying this, but I think part of the problem is Python's dynamic nature. Python is the dynamic language I have the most experience with, so perhaps I'm over-generalizing, but the problem I've seen with large Python projects is that they get to a point where a major refactoring is needed and it's impossible to pull it off because of the dynamic nature of the language. Perhaps with 100% test coverage things would be easier, but in the real world that's rare/nonexistent. (Also, I find that more tests are necessary in Python than in a static language because you end up having to test a lot of the same things your static language would have been proving for you.) In the bigger Python projects I've seen they eventually rewrote the whole system in a static language.
It's OK if your choice is Python, it's my choice too, for now at least.
But regardless, if you haven't worked with badly written Python code that makes you want to switch career, that's just luck.
Can you elaborate on what python limitations really frustrate you?
My opinion very subjective ... I'm looking for 2 things out of a programming language ...
1) (proper) anonymous code blocks ... it's the only sane way to have declarative APIs, although I've found for some tasks that Python's features (like decorators, meta-classes) are enough ... but not for all things I want to do
2) a limited form of macro support ... like, I want to get the syntax-tree out of a closure, instead of a reference to the compiled method ... to abstract the way some processing takes place. In Python you can workaround it with some magic (a la Django's ORM), but I love to be able to write Python syntax for those queries (e.g. something like Linq) ... and have for example a unified querying interface for collections of data
> 1) (proper) anonymous code blocks ... it's the only sane way to have declarative APIs, although I've found for some tasks that Python's features (like decorators, meta-classes) are enough ... but not for all things I want to do [.]
Is the anonymous bit necessary? Or asking another way: What about throw-away names? I find that even in Haskell I rarely use lambdas, but tend to name nearly all of my functions.
Sad to say it, but given enough programmer ambition, eventually any language is going to annoy you this way!