Python Creator Guido van Rossum Asks: Is 'Worse is Better' Still True for Programming Languages? (blogspot.com) 47
In 1989 a computer scientist argued that more functionality in software actually lowers usability and practicality — leading to the counterintuitive proposition that "worse is better". But is that still true?
Python's original creator Guido van Rossum addressed the question last month in a lightning talk at the annual Python Language Summit 2025. Guido started by recounting earlier periods of Python development from 35 years ago, where he used UNIX "almost exclusively" and thus "Python was greatly influenced by UNIX's 'worse is better' philosophy"... "The fact that [Python] wasn't perfect encouraged many people to start contributing. All of the code was straightforward, there were no thoughts of optimization... These early contributors also now had a stake in the language; [Python] was also their baby"...
Guido contrasted early development to how Python is developed now: "features that take years to produce from teams of software developers paid by big tech companies. The static type system requires an academic-level understanding of esoteric type system features." And this isn't just Python the language, "third-party projects like numpy are maintained by folks who are paid full-time to do so.... Now we have a huge community, but very few people, relatively speaking, are contributing meaningfully."
Guido asked whether the expectation for Python contributors going forward would be that "you had to write a perfect PEP or create a perfect prototype that can be turned into production-ready code?" Guido pined for the "old days" where feature development could skip performance or feature-completion to get something into the hands of the community to "start kicking the tires". "Do we have to abandon 'worse is better' as a philosophy and try to make everything as perfect as possible?" Guido thought doing so "would be a shame", but that he "wasn't sure how to change it", acknowledging that core developers wouldn't want to create features and then break users with future releases.
Guido referenced David Hewitt's PyO3 talk about Rust and Python, and that development "was using worse is better," where there is a core feature set that works, and plenty of work to be done and open questions. "That sounds a lot more fun than working on core CPython", Guido paused, "...not that I'd ever personally learn Rust. Maybe I should give it a try after," which garnered laughter from core developers.
"Maybe we should do more of that: allowing contributors in the community to have a stake and care".
Python's original creator Guido van Rossum addressed the question last month in a lightning talk at the annual Python Language Summit 2025. Guido started by recounting earlier periods of Python development from 35 years ago, where he used UNIX "almost exclusively" and thus "Python was greatly influenced by UNIX's 'worse is better' philosophy"... "The fact that [Python] wasn't perfect encouraged many people to start contributing. All of the code was straightforward, there were no thoughts of optimization... These early contributors also now had a stake in the language; [Python] was also their baby"...
Guido contrasted early development to how Python is developed now: "features that take years to produce from teams of software developers paid by big tech companies. The static type system requires an academic-level understanding of esoteric type system features." And this isn't just Python the language, "third-party projects like numpy are maintained by folks who are paid full-time to do so.... Now we have a huge community, but very few people, relatively speaking, are contributing meaningfully."
Guido asked whether the expectation for Python contributors going forward would be that "you had to write a perfect PEP or create a perfect prototype that can be turned into production-ready code?" Guido pined for the "old days" where feature development could skip performance or feature-completion to get something into the hands of the community to "start kicking the tires". "Do we have to abandon 'worse is better' as a philosophy and try to make everything as perfect as possible?" Guido thought doing so "would be a shame", but that he "wasn't sure how to change it", acknowledging that core developers wouldn't want to create features and then break users with future releases.
Guido referenced David Hewitt's PyO3 talk about Rust and Python, and that development "was using worse is better," where there is a core feature set that works, and plenty of work to be done and open questions. "That sounds a lot more fun than working on core CPython", Guido paused, "...not that I'd ever personally learn Rust. Maybe I should give it a try after," which garnered laughter from core developers.
"Maybe we should do more of that: allowing contributors in the community to have a stake and care".
Re: I don't think anyone cares (Score:3)
First mention I can find is here
https://science.slashdot.org/c... [slashdot.org]
He is missed for sure.
Re: (Score:1)
Re: was there ever an obit as promised? (Score:2)
That was the clincher for me.
Re: (Score:1)
Re:Rossum (Score:4, Interesting)
Capek was Czech, and in Czech "robota" means a very specific type of work: corvee. Work for the feudal lord as a form of taxation.
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2, Informative)
Nah, Paul Stanley and co were around in the 70s.
Yeah it's nice if all your users sit down the hall (Score:1)
Then it doesn't matter if there's a glaring bug or missing features because the glaring bug can be avoided by handshake agreement and the missing features simply don't exist in your little social bubble of geeks.
I've written and worked on several large (100kloc+) pieces of software like that over the past 20 years or so.
And then a commercial package comes along that costs something north of $50k/seat but actually fixes all those bugs and handles the corner cases y'all were too lazy to implement.
But of cours
Yes. (Score:5, Insightful)
Feature-itis is the death of usable, useful software, commercially or Open Source.
I don't mean you can't SELL such software (*cough*MS-Office*cough*), but the software sucks.
Apple's success is understanding that one simplifies by removing choice, and this helps _most_ people find the software more usable and useful.
(And no, Apple doesn't walk on water, and yes, they make tons of mistakes and bad choices. No fan-boi here.)
There are a number of constituencies who will _hate_ software simplified this way. One of those is the typical developer, who's an "ultimate customizer" and typically wants all the options available and discrete control over them.
This difference between developers and "most people" is one of the reasons so much software has awful usability: Developers build it for someone like themselves. If there's no one with the professional capacity of evaluating a design's usability, or no corporate will to understand and implement the findings of such an evaluation, the software is gonna suck, for most people.
Yes, there are a few unicorns out there: Developers who know that the typical developer isn't like most people, and can empathize with people who aren't customizers. But they're scarce as...unicorns.
And there are a few use cases out there (IDEs, for example) built for these customizer constituencies, which do well by providing all the options for them. It's often hell getting these expert-focused tools past the usability staff, who, obviously, aren't like developers, and can't see their own blind spot here.
Re: (Score:3)
Since the article is talking about the development of the Python language itself, this would fall into the category of software used by "customizers" who do want everything.
Even in software development tools and languages, there is a such thing as too many options. Cygwin is one such developer tool, where you have hundreds of options at install time. At that point, I have no idea about half the options.
On the other hand, one of the reasons I *love* .NET programming, is that it has a million built in tools a
Re:Yes. (Score:4, Insightful)
.NET was actually designed as a programming language specific to Microsoft Windows. Python was designed as a scripting language because perl tried to be a programming language and grew into an unusable mess. Python then mimicked perl and did the same thing, becoming a travesty of a programming language, IMO. So many bad design decisions trying to make it a programming language, ditto with perl.
Re:Yes. WRONG (Score:3)
" .NET was actually designed as a programming language specific to Microsoft Windows. "
Wtf... that's wrong on so many levels, not sure how it was labelled insightful. .
NET is a framework, NOT a language. You can program against the framework using C# (most common), F# or VB.
https://dotnet.microsoft.com/e... [microsoft.com]
And it was specifically designed NOT to be platform dependent, MS woke up and moved away from being Windows dependent, .NET was intentionally architected to be multi-platform:
".NET is supported on Android
Re: Yes. (Score:2)
SAD
Re: (Score:2)
I love that you're currently 50% Insightful and 20% Informative, when in fact, you are wrong, and confidently spreading misinformation.
Way to go Slashdot.
Re: (Score:3)
Re: (Score:2)
Re: Yes. (Score:4, Interesting)
Re: (Score:2)
Same here. My dev toolset is vi-gcc-gdb-strace. Done. Can't be arsed with some IDE that requires me to create a friggin "project" or "solution" before I can write a line of code never mind compile it and buries some compiler options 2 or 3 levels down.
You kids (Score:3)
Get off my lawn!
Re: Yes. (Score:2)
âoeI also hate over-complicated toolsâ
âoeI use a small subset of Emacsâ
Hmm. . .
Re: Yes. (Score:2)
Re: Yes. (Score:3)
>Apple's success is understanding that one simplifies by removing choice
It's not just removing choice. It's (presumably) designed to streamline the most popular use cases.
The rest of your comment sounds like the standard tug of war between engineering and marketing.
Simplicity is great... when you nicely fall into the use cases the sw is designed for. The problems and grumbling starts when you need something beyond the imagined use cases.
Re: (Score:3)
It's actually dependent on culture.
When I was in Japan I noticed appliances had a TON of buttons. The remote control for the hotel room AC was wild. It had all sorts of buttons for every function. My house AC has a MODE button that switches between modes. The japanese remote had one button for each mode (color coded even). I actually have a Daikin AC at home (japanese brand and actually the same brand that was in most hotel rooms - either Daikin or Mitsubishi). The "western" remote has fewer buttons.
If you
Re: (Score:2)
If worse is better then Python wins (Score:2, Insightful)
If worse is better then Python wins because even minor version updates break everything. Morons.
Not to mention everything else wrong with it. Slow, whitespace syntax, etc.
Re:If worse is better then Python wins (Score:5, Insightful)
Guido van Rossum is confused as to what makes Python successful. Guido van Rossum thinks his shit don't stink.
It's all those libraries that he's complaining about that lock in Python's dominance, not his childish views on fun and ownership. Python is a crappy scripting language that commands incredibly powerful software NOT written in Python. Guido van Rossum is a dipshit we put up with, not a visionary that guides us.
Re: (Score:3)
Python is a crappy scripting language that commands incredibly powerful software NOT written in Python.
There are plenty of crappy scripting languages out there. Why did Python rise to dominance over AppleScript and Visual Basic and bash and MS-DOS .bat files and Perl and Tcl and all the rest?
I suggest that it's because Python is significantly less crappy than its competition.
Re: (Score:2)
I suggest that it's because Python is significantly less crappy than its competition.
I think this could only be written by one of those idiots.
More high level concepts just for the sake of it (Score:1)
With all major feature already present in the core of the language, useful idiots turn to all these exotic theoretical high level concepts as if they come at no cost.
In the end your language will be slower and less understandable.
It is just like sticking to indentation as part of your syntax because in the 70's all you had was this 40 character CRT to program on and never could image one day working on a 5K 32 inch display.
Re: (Score:3)
"...It is just like sticking to indentation as part of your syntax because in the 70's..."
I don't think justification for TABs as a semantic element is nearly that intelligible, but the real offense is continuing to insist on a sub-80 character line length. A total joke. I stopped doing that before Python even existed. Yes, I know Python doesn't enforce it, but the community does.
Python is liked, and chosen, because it is easy to learn by non-programmers. Scientists could more easily do their own coding.
Re: (Score:2)
Idiots gravitate around all kinds of things. Confusing the popularity of those things with quality is a fatal error.
Maturity (Score:5, Insightful)
Time for someone young to reinvent the wheel.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Does that mean assy lang rules? (Score:2)
who? (Score:2)
"In 1989 a computer scientist argued"
Um, the name of that computer scientist was Dick Gabriel.
The way I remember it, part of the argument was that garbage software with lots of features -- the Microsoft way -- is more successful in a mass market.
The next python (Score:2)
The next python will work interpreted or compiled to machine code.
The next python will have an optional, built-in, cross-platform, object oriented UI.
Until then, I will code in Python and C++.