[simias]

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]

> 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]

I'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]

Correct 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]

I 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]

Are your former/latter backwards?

[simias]

I 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]

Would be interesting if there could be a bureaucratic process for controversial issues, but also a "fast track" for easy wins.

[sytelus]

Unlike 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]

This 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.

[pstch]

I'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]

I 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.

[chaosite]

I mean, eventually a committee takes over, sure.

But C++ is Stroustrup, Java is Gosling, C is K&R, JavaScript is Eich. Most successful languages kept their internal consistency by being designed by a single person. Historically, these single persons also had mustaches.

Yes, eventually all of those graduated to a design-by-committee approach, but that happened much later. But yes, in that sense, Python is just following the path set by others.

[johannes1234321]

Java's predecessor Oak was created by 13 guys (among them Patrick Naughton, Mike Sheridan, James Gosling and Bill Joy) over 18 months a different then relatively quickly grew to a larger team. (While that project didn't include the language spec itself only, but also runtime and library)

C++ wasn't designed by Stroustrup alone. It's based on C's design.

Sure sometimes you have cleared leaders (see also Perl/Larry Wall) but having a larger group has benefits to see more edge cases (with the risk of committee issues)

[pjmlp]

C++ was Stroustrup before C++89, Java was Gosling until about 1.5, C was K&R before C89, JavaScript was Eich until ES3.

So, all around 20 to 30 years ago.

[xg15]

I disagree that such languages will die, but they might become designless frankensteins that draw their life energy from sources best left unexplored (see: Java, HTML)