You know that sinking feeling when you crack open 3-year-old code written by your predecessor's predecessor and realize it's a load of garbage and that you'll never be able to fix the bug?
Yeah, well, with Python that doesn't happen. At least, not at all frequently.
Python forces you to spend a bit more time up-front and then saves you time each and every time you need to read, edit, or improve your code. People choose Python for the same reasons they choose good testing practices. Python's a mature language for mature developers who want to produce mature software.
> 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.
Can you go into more detail about how Python fixes maintenance? I'm really curious what language features of Python are conducive to good or easy maintenance, and how those features are unique to Python. Color me skeptical, but I can be convinced.
I'm really curious what language features of Python are conducive to good or easy maintenance
My guess is that "Less is More" in this situation. Python often does tend to read like pseudocode.
The problem with this, though, is that idiocy has seemingly infinite resources on its side. Occasionally, you will have an outlier who has vast holes in their understanding of programming and writes large amounts of jaw-dropping bad code and can do this even in simple elegant languages. In fact, there's one on the team I'm working with right now. (He was maneuvered onto the testing team to mitigate the damage.)
Occasionally, you will have an outlier who has vast holes in their understanding of programming and writes large amounts of jaw-dropping bad code and can do this even in simple elegant languages.
One interesting quirk of Python is that such code superficially resembles good code in everything except the length of functions and methods.
Perhaps not always a good thing. Kent Beck's preferred Smalltalk indentation style made good Smalltalk look good, and bad Smalltalk look really bad. That's actually useful.
As far as "Less is More" goes, this could be practiced in other languages by voluntarily choosing a simpler subset of features in a language with a complex feature set. Think RISC style in CISC architecture.
> Can you go into more detail about how Python fixes maintenance?
It's pervasive, so there isn't any single feature I could point to. Python embraces a general philosophy that starts from the observation that programmers spend much more time reading code then they spend time writing it [1]. Thus, most trade-offs between readability and writability should fall in favor of readability.
For instance, let's look at the whitespace thing. It's the first thing new Python users bump up against, and it's a source of perpetual controversy. There's a not-insignificant group of users who try Python, hit whitespace-for-control-flow, and leave in a huff. I won't argue that these people are wrong, but I will point out that it's ridiculously nice to have all the code you read always use the same control flow indentation conventions. Though Python's my primary language, I do more and more work in JavaScript theses days, and I could go on and on about my frustration trying to follow the flow of code written with varying intendation, brace, and semicolon styles.
This is encapsulated by the observation, from The Zen of Python, that "there should be one — and preferably only one — obvious way to do it" (http://www.python.org/dev/peps/pep-0020/). At its best, Python code eliminates any stylistic differences. This sounds like it's a stifling of creativity (and perhaps it is), but in practice it means maintaining someone else's code is just as easy as maintaining your own.
Take Django, for example: I can tell at a glance who's responsible for any given line of JavaScript in the framework, but it usually takes digging into SVN history to discover who's written some given line of Python [2].
Or look at Python's general lack of language features. There's a `while` loop but no `do ... while`. There's a `for` loop, but it's really just `foreach` and nothing else. There's `if/else`, but no `switch/case`. There's language-level primitives for basic types list, dicts and tuples, but not regexes, ranges, heredocs, or anything else more exotic. Python's a little language; I can keep it all in my head. I never have to run to the docs to find out what some obscure syntax does; there isn't any obscure syntax.
If I got to do green-fields development all of the time, I might very well choose a different language. I've certainly used languages that are easier to write. But I live in a world filled with old code, so I've tried to make sure my career involves code that sucks as little as possible.
[1] Indeed, I'd argue that reading code — especially other people's — is the most important skill a developer can have. I'd go so far as to argue that asking people to write code during interviews is pointless; we should be asking them to read it. But that's another show.
[2] I'm often surprised to find that the code was written by me, though I'm not sure if that's a praise of Python or a remark on my generally shitty memory…
[3] Well, until Python 3. Again, that's another show.
Thank you for the reply. I've had some opportunity to work with Python, read some other people's code, and yes Python lends itself to regularity of form. If you squint and turn your head a bit, you can almost see the abstract syntax tree that the compiler ought to create. That is beside the point I think. For me the most difficult thing in maintenance is understanding the intention of certain functions, classes, methods etc. Why did the original author make the choices that he made? What exactly was the intent? Sometimes the accompanying commentary is short on those details. Commentary on why a particular design choice was made and what the intent of the design was is many times more valuable to me when I maintain code.
>For instance, let's look at the whitespace thing.
I immediately fell in love with significant whitespace. Since I was already indenting anyway, why not make it meaningful and skip the additional overhead of matched curly braces?
I am in the same camp. Interestingly I also find Scheme's approach quite nicely: The syntax is so uniform and thus the editor support so good, that you can just pretend that you have significant whitespace and that the parens are just a hint for your editor.
OTOH C is a more difficult language to use, so it takes a certain level of care to write in it. Does that mean that any working C program is readable and maintainable as long as you crossed that threshold and now know how to read and write C?
Comments
Python fixes maintenance.
You know that sinking feeling when you crack open 3-year-old code written by your predecessor's predecessor and realize it's a load of garbage and that you'll never be able to fix the bug?
Yeah, well, with Python that doesn't happen. At least, not at all frequently.
Python forces you to spend a bit more time up-front and then saves you time each and every time you need to read, edit, or improve your code. People choose Python for the same reasons they choose good testing practices. Python's a mature language for mature developers who want to produce mature software.
> 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!
Can you go into more detail about how Python fixes maintenance? I'm really curious what language features of Python are conducive to good or easy maintenance, and how those features are unique to Python. Color me skeptical, but I can be convinced.
I'm really curious what language features of Python are conducive to good or easy maintenance
My guess is that "Less is More" in this situation. Python often does tend to read like pseudocode.
The problem with this, though, is that idiocy has seemingly infinite resources on its side. Occasionally, you will have an outlier who has vast holes in their understanding of programming and writes large amounts of jaw-dropping bad code and can do this even in simple elegant languages. In fact, there's one on the team I'm working with right now. (He was maneuvered onto the testing team to mitigate the damage.)
Occasionally, you will have an outlier who has vast holes in their understanding of programming and writes large amounts of jaw-dropping bad code and can do this even in simple elegant languages.
One interesting quirk of Python is that such code superficially resembles good code in everything except the length of functions and methods.
Perhaps not always a good thing. Kent Beck's preferred Smalltalk indentation style made good Smalltalk look good, and bad Smalltalk look really bad. That's actually useful.
Could you please elaborate?
As far as "Less is More" goes, this could be practiced in other languages by voluntarily choosing a simpler subset of features in a language with a complex feature set. Think RISC style in CISC architecture.
> Can you go into more detail about how Python fixes maintenance?
It's pervasive, so there isn't any single feature I could point to. Python embraces a general philosophy that starts from the observation that programmers spend much more time reading code then they spend time writing it [1]. Thus, most trade-offs between readability and writability should fall in favor of readability.
For instance, let's look at the whitespace thing. It's the first thing new Python users bump up against, and it's a source of perpetual controversy. There's a not-insignificant group of users who try Python, hit whitespace-for-control-flow, and leave in a huff. I won't argue that these people are wrong, but I will point out that it's ridiculously nice to have all the code you read always use the same control flow indentation conventions. Though Python's my primary language, I do more and more work in JavaScript theses days, and I could go on and on about my frustration trying to follow the flow of code written with varying intendation, brace, and semicolon styles.
This is encapsulated by the observation, from The Zen of Python, that "there should be one — and preferably only one — obvious way to do it" (http://www.python.org/dev/peps/pep-0020/). At its best, Python code eliminates any stylistic differences. This sounds like it's a stifling of creativity (and perhaps it is), but in practice it means maintaining someone else's code is just as easy as maintaining your own.
Take Django, for example: I can tell at a glance who's responsible for any given line of JavaScript in the framework, but it usually takes digging into SVN history to discover who's written some given line of Python [2].
Or look at Python's general lack of language features. There's a `while` loop but no `do ... while`. There's a `for` loop, but it's really just `foreach` and nothing else. There's `if/else`, but no `switch/case`. There's language-level primitives for basic types list, dicts and tuples, but not regexes, ranges, heredocs, or anything else more exotic. Python's a little language; I can keep it all in my head. I never have to run to the docs to find out what some obscure syntax does; there isn't any obscure syntax.
If I got to do green-fields development all of the time, I might very well choose a different language. I've certainly used languages that are easier to write. But I live in a world filled with old code, so I've tried to make sure my career involves code that sucks as little as possible.
[1] Indeed, I'd argue that reading code — especially other people's — is the most important skill a developer can have. I'd go so far as to argue that asking people to write code during interviews is pointless; we should be asking them to read it. But that's another show.
[2] I'm often surprised to find that the code was written by me, though I'm not sure if that's a praise of Python or a remark on my generally shitty memory…
[3] Well, until Python 3. Again, that's another show.
> I'd go so far as to argue that asking people to write code during interviews is pointless; we should be asking them to read it.
An excellent idea.
> [3] Well, until Python 3. Again, that's another show.
This doesn't seem to be referenced in the body of your comment. What are you referring to?
Thank you for the reply. I've had some opportunity to work with Python, read some other people's code, and yes Python lends itself to regularity of form. If you squint and turn your head a bit, you can almost see the abstract syntax tree that the compiler ought to create. That is beside the point I think. For me the most difficult thing in maintenance is understanding the intention of certain functions, classes, methods etc. Why did the original author make the choices that he made? What exactly was the intent? Sometimes the accompanying commentary is short on those details. Commentary on why a particular design choice was made and what the intent of the design was is many times more valuable to me when I maintain code.
>For instance, let's look at the whitespace thing.
I immediately fell in love with significant whitespace. Since I was already indenting anyway, why not make it meaningful and skip the additional overhead of matched curly braces?
I am in the same camp. Interestingly I also find Scheme's approach quite nicely: The syntax is so uniform and thus the editor support so good, that you can just pretend that you have significant whitespace and that the parens are just a hint for your editor.
You might want to have a look at Haskell, if you like this trade-off of making writing somewhat more complicated but reading much simpler.
Also if you browse some PEPS (and other sources) you will find that Python and Haskell's history are more intertwined that one would guess at first.
I'm willing to bet you haven't seen a lot of Zope 2 code. :-)
Given that he developed Django, the framework that thankfully euthanized Zope, he's probably seen things us people wouldn't believe.
OTOH C is a more difficult language to use, so it takes a certain level of care to write in it. Does that mean that any working C program is readable and maintainable as long as you crossed that threshold and now know how to read and write C?