Python is better than the lisps for team based development, IMO, primarily because you can't write your own language in python. In a team you're normally working on long-lived code of medium - large projects (e.g. over 100k lines, over a period of 1 - 5 years). You need to be able to quickly grok how to maintain older code written by someone else. Python's mantra "there's only one way to do it" means that is more likely to be possible than it is in one of the lisps. However I have to admit that that is conjecture on my part, not having worked on a large team with a lisp project.
Right, because programs with millions of lines of code written by many different people are so easy to "quickly grok". As long as they stick to lower-level constructs.
The problem with this fallacy is that it assumes that what is true of a single self-contained function is true of thousands of inter-depending functions heaped on top of each other.
We, for instance, structure all our code very carefully with clearly defined and documented interfaces and modularised functional areas. I doubt that any function is really interdependent with more that 20 other functions, never mind thousands. If someone needs to understand thousands of functions to maintain any piece of code then that code has a serious problem and probably a low 'bus factor' (how many developers being hit by a bus it would take to derail your project). I suspect that the power of the lisps tempts developers into writing code that does effectively have many interdependent functions, though they may not fully realise until it's too late.
I really don't see any difference there. You can write bad code in any language. If you have the organizational discipline to code the way you've described in Python, why wouldn't that restraint carry over into other languages? Why are macros different?
I find typical Python programming to be not particularly disciplined, so if you've overcome the problem in that language you should be fine in a generally more disciplined language like Clojure.
I'm not in that situation, virtually the whole software industry is in it. If you think "policies" can address that, we have a very different worldview.
The real point though (which remains unaddressed) was that the argument against higher-level abstractions is wrong because it assumes that what is true of a single function written at a certain level of abstraction will remain true if you try to build an entire complex system out of them. It won't. Therefore, as complexity grows, we need the ability to create new abstractions. There is something perverse about the argument that we should eschew powerful techniques for doing this because they'll make large systems hard to understand. It's like saying we should avoid water because dehydration is bad.
I only jokingly implied you could be in such a mess. I also can assure you it's not the _whole_ industry.
Some of us employ techniques that make it easier to maintain large chunks of code. I refrain to describe them as complex because complexity is something to be avoided like the plague.
It's a legitimate way to disagree, as has been made clear here on many occasions. Besides, sometimes it's better not to engage in an active argument. For example, my contributions to this thread were borderline over-participation.
There should be no such thing as "over-participation". As long as you have something to say: as I implied - at least one group I participate in has managed to have a very large and long lived codebase that has little to no signs of the cruft described in the thread head. Careful choice of languages, paranoid test coverage evaluation, commit policies (like "you only merge into head if all the tests pass and no function is left untested"), extensive code reviews (one could go as far as do pair-programming all the time) and relentless refactoring and feature removal can get you very far.
You can think of the current *BSD codebases as direct descendants of the original AT&T UNIX codebase that have survived by employing one or more of the techniques I mentioned in the previous paragraph.
