4 ms·
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,
by joe24pack 16y ago
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.
- stcredzero 16y agoI'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.)
- chromatic 16y agoOccasionally, 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.
- stcredzero 16y agoPerhaps 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.
- eru 16y agoCould you please elaborate?
- joe24pack 16y agoAs 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.
- jacobian 16y ago> 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/ 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.