undefined | Better HN

0 pointsgeofft7y ago0 comments

Nobody required him to be in charge of Python. Nobody required him to personify Python. Plenty of languages have succeeded without their creators handling every little detail, from C to JavaScript to PHP to Java.

A core skill of any open-source project maintainer is recognizing when you're burnt out enough that your continued presence isn't helping the community and is just getting in the way of others, and stepping aside. If you can't do this, you're not a good maintainer. I'm happy to have sympathy for your personal problems, but you're still failing at your job. Here, for instance, is a short but effective way to do it: https://mail.mozilla.org/pipermail/rust-dev/2013-August/0054... (That was almost two years before Rust reached 1.0, and the language hasn't suffered one bit for it.)

And part of Amber's point is that core Python development is taking on too many burdens for no actual benefit. By bundling so much in the standard library and expecting the standard library to be usable for real work without installing additional packages, the core team (and Guido in particular) increases their own workload, impedes the ability of others to contribute, and produces worse results for end users than they would otherwise.

0 comments

3 comments · 1 top-level

lone_haxx0r7y ago· 2 in thread

> Plenty of languages have succeeded without their creators handling every little detail, from C to JavaScript to PHP to Java.

Sure, if your definition of success is being used by as many people as possible, but there are other (more) important criteria for asserting the quality of a language.

When you have a vision for your project, you might be afraid that other people are going to ruin it, because they don't understand, or they don't have good taste, etc.

geofftOP7y ago

In that case the right thing to do is to make it clear that you're not prioritizing number of users, you're not here to solve problems for users other than yourself at least in the short term (because you're interested in pursuing your vision, not implementing feature requests from people without good taste), and that you're not trying to take everyone's feedback into account. Then people stop expecting you to do more than you can, and you can slowly and quietly pursue your vision and perhaps find a small number of collaborators who share your taste.

Clojure sort of had this moment recently, where various people in the community were unhappy with the language direction and Rich Hickey (who is a person who cares about vision and taste in a language) made it quite clear that addressing their problems directly wasn't his definition of success. He was building a language for himself / his company to use, and if it worked for other people, great, and if they wanted to contribute to his vision, great, but if it didn't work for them, they should not expect Clojure to change. https://gist.github.com/richhickey/1563cddea1002958f96e7ba95... That, at least, is clear, and it means that authors of significant third-party libraries that are clashing with the vision of the language (and its community) can make an informed decision to spend time elsewhere, avoiding frustration on all sides. https://twitter.com/cemerick/status/1067111260611850240

I don't think Guido is/was actually trying to do this, and I think it's unfair to say that was his goal. If it was, then he was deliberately tricking people by having a core team, BDFL-Delegates, a language summit, etc. If it was, then he was being rude by asking her to come to the language summit instead of saying "Amber, Twisted is very good but your vision for Python is not my vision for Python." Guido, as far as I can tell, built Python to be a widely-used language, not a language following any sort of vision he started with. Guido does want Twisted and other Twisted-scale projects around, and does want Python to be a useful language for them. That's why I say that if he's burned out, the right way to execute his vision (which is exactly what he's doing, in fact) is to step aside graciously.

zimablue7y ago

I think the tone of your post seems to imply that writing languages in some quasi-democratic (rather than oligarchic/dictatorial/elitist) way is or should be default. In fact, those assumptions are not the default (I can't think of any languages that are truly democratic, certainly most big ones aren't). Nor should it work like that imo, we don't design power plants by referendum. We put experts in a room, probably with a dictatorial decision maker and everyone else can whistle (or at least would really have to shout loud and be clearly right to be heard).

Also, if you're going for max language usage through design, how do you do that? By trying to perfect your design, so it's kind of an irrelevant motivator. Rich got a ton of clojure users (relative to his resources), he did that by having strong (reasoned) beliefs, not by opening the floor to a vote. Rich did /not/ say that he was only building Clojure only for his company, that's a very misleading statement that you've made.

j / k navigate · click thread line to collapse