5 ms·
A good benevolent dictator is often more efficient than a more decentralized and democratic system but you have a single point of failure and you need to be abl
by simias 8y ago
A good benevolent dictator is often more efficient than a more decentralized and democratic system but you have a single point of failure and you need to be able to find said dictator in the first place. A bad or incompetent not-so-benevolent dictator can be absolutely terrible for a project and cause a lot of long-term damage.
For such an important project unfortunately I think a certain amount of bureaucracy and paperwork is not only unavoidable but actually necessary and important.
- kibwen 8y ago> unfortunately I think it's curious that commenters (this is not aimed at you specifically) don't dare to even indirectly praise bureaucracy without couching it with words like "unfortunately", because there's nothing unfortunate about having a well-described and transparent decision-making process. Python has had bureaucracy for decades, e.g. the entire PEP process, so it's too late for us to be wringing our hands about tainting the Python project with the bogeyman of government.
- SolaceQuantum 8y agoI'm under the impression that well-described, transparent decision making process has the consequence of increasing cognitive load when it comes to participating in decision making. Given that decision-making in large projects like this is already a significant cognitive load, adding on "did I make the decision following pre-defined process goals" does increase difficulty. Whether or not the tradeoffs are worth it is another decision.
- kibwen 8y agoCorrect that it involves tradeoffs, though having no process at all for making decisions leads to at worst a free-for-all (which can work for small or non-critical projects, but even so be prepared for inevitable drama), or at best an opaque and implicit process as others here have warned about. To use a HN-friendly analogy, it's like static typing vs dynamic typing: you can either accept pain up-front to avoid pain down the road, or vice-versa. The latter is better for massive, established projects and the former is better for young, rapidly-changing projects, so we must consider which of these two better resembles the Python project.
- SolaceQuantum 8y agoI agree with this, and I'm mostly under the impression that in the case of a benevolent dictator, the benevolent dictator already has a set of processes that are just opaque/implicit. However it is true that in the case of multiple minds (a council) there is latency cost (bureaucracy).
- mixmastamyk 8y agoAre your former/latter backwards?
- simias 8y agoI consider it unfortunate because I think we've all been frustrated by "due process" and having to wait or do seemingly useless tasks when the way to go appears obvious. Being able to say "let's do this" and start hacking right away sounds a lot more fun than "let's submit an RFC and wait for one month for people to comment, then we'll vote and if people accept the proposal we'll implement the unit tests, do the code review, validate the tests, put it on the unstable branch for at least six months and if everything goes right we'll have the change released next year". I'm far from a libertarian so I completely understand and accept why these rules and regulations are necessary but it's still annoying and somewhat inefficient from time to time. For the same reason I consider it unfortunate and annoying when I get a speeding ticket even though I understand why such things exist. Rules are good when they apply to other people but they tend to suck when they apply to me, mainly because obviously I'm much more clever than my peers and specs and code reviews are for losers.
- mixmastamyk 8y agoWould be interesting if there could be a bureaucratic process for controversial issues, but also a "fast track" for easy wins.
- sytelus 8y agoUnlike other software projects, language design requires a single mind to think holistically, break things when needed, avoid feature creep while at the same time keep doors open for new ideas. It’svery intricate balance. Once language doesn’t have one leader, it will likely die in long term. I would call it death by committee:).
- kibwen 8y agoThis is unfounded in practice. Having a BDFL did little to stop Python's feature set from growing, or to prevent design flaws like `lambda`, or to make Python 3 anything other than the poster child for how not to break things. Conversely, we can look to Javascript (yes, Javascript!) as an example of a language that was a total mess after being designed by a single person and that got immeasurably better once it began being designed by committee (yes yes, "ten days" and all that, but I daresay that even Eich would agree with me that the Javascript committee has done a relatively fantastic job). The reality is that languages are born with a single creator, and spend their adolescence growing under that creator's care, but achieve maturity once they can demonstrate that they can function without such a single point of failure as a BDFL.
- deleted 8y ago[deleted]
- pstch 8y agoI'm curious, and I didn't see any other mention of it in the thread : why do you consider `lambda` to be flawed ? Is it because it has the same scoping rules as functions, and that you consider these scoping rules inappropriate for lambda expressions ?
- ecshafer 8y agoI think as far as successful languages go, the truth is the opposite. Languages with large design by committee teams are most successful. C++, Java, C, JavaScript or even going back to Cobol and Fortran. The languages with the most use are not typically designed by one person.