Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Why Did Python Win?
53 points by fud101 4 days ago | hide | past | favorite | 153 comments
I was listening to an old postcast from 2021 which discusses the inexplicable rise of Python.

I remember much of the positive sentiment around Python in the early days being less about Python and more about how powerful Perl is but Perl is Perl. Python being the nice and clean version of Perl meant it got all all the praise of Perl while enjoying the reputation of having none of the failings of Perl. In hindsight I think Python needed to stand on its own right, not just as a better Perl, but yet here we are. I think hindsight will show we should have considered the defects of Python more deeply. I know the lispers saw them but no one listens to them. Today Python is most dominant language on the planet and Perl is all but forgotten.

If you survey the language landscape now, a language can be much better than Python but never get the chance Python did just because it happened to look a bit better than Perl. Which is absurd to me.





1. Python was designed by testing syntax with novice users to see what they could adopt easily.[1] > 90% of current Python users weren’t born when it was created. They all had to learn, and Python is the easiest language to learn because Guido and his teammates, unlike $LANGUAGE_DESIGN_GOD, approach the problem as experimental scientists rather than auteurs.

2. Python is conceptually compact, dominated by hash tables with string keys. The initial leader in the ecosystem, Perl, is conceptually sprawling and difficult to reason about.

3. Python also took lessons from the Unix shell, a mature environment for accommodating beginners and experts.

4. Python had a formal process for integrating C modules from early on.

5. Python’s management has an elegant shearing layer structure, where ideas can diffuse in from anywhere.

6. $NEXT_GENERAL_PURPOSE_LANG (Ruby, Go) weren’t enough better to displace Python. Both were heavily influenced by Python’s syntax, but ignored the community-centric design process that had created that syntax in favor of We Know Best.

7. Speaking of open source entrepreneurialism, JavaScript has become a real rival thanks to the Web (and node), but it is handicapped by the inverse failure mode: where Go is dominated by a handful of Googlers, JavaScript was effectively unmanaged at the STDLIB level for a crucial decade, and now it can’t recover. (I’d also guess that having to write a module system that works well in the chaos that is Web clients and simultaneously the Unix world is a daunting design problem.)

8. Python got lucky that data science took off.

[1] https://ospo.gwu.edu/python-wasnt-built-day-origin-story-wor...


I forgot two, er, three:

9. Python got lucky that its inevitable screwups (Python3) didn’t quite kill it.

10. Swift and Kotlin both define programming as serving the compiler (specifically LLVM) rather than serving the coder’s problem. (I haven’t discussed Rust so far since it isn’t attempting to compete with 98% of Python use cases, but if you squint you can see it as going one step further than Swift and Kotlin and in effect forcing the coder to be a sort of human compiler who thinks in types and memory management. This is not a criticism of Rust, BTW.)

0. And behind all of this is Moore’s Law and the demographic explosion of programmers. Python was an implicit, perhaps unconscious bet that if you served people thoughtfully, the tradeoffs with serving the needs of contemporary silicon wouldn’t matter as much.


I can't stop thinking about this. WRT Perl specifically, it’s fascinating how the two competitors adopted Unix shell patterns. Python is handicapped to this day by not automagically snarfing up environment variables, etc. But Perl leaned hard into TECO-style gibberish and the meta-syntax that is regular expressions, confronting beginners with arbitrary complexity. It feels like Wall embraced the system administrator side of coding — the side that has an enormous capacity for tracking corner cases and managing impedance mismatches. Wall was trained, perhaps not coincidentally, as a linguist, a field where continent facts really matter. Guido, on the other hand, was an accomplished mathematician. (This is the Dwarf / Elf distinction from Cryptonomicon.)

Guido van Rossum was not an accomplished mathematician. He has a master's Degree in Mathematics and Computer Science, and got a bronze medal in the International Mathematical Olympiad, but the former is because that's where CS was taught, and the latter because he was a smart high school student.

As he described it:

"But after that first year [of college], it turned out that the real math I wasn’t particularly good at. And I think there were some great teachers at that university and some super cool topics being taught. And I couldn’t keep up. I remember something about a particular form of group theory. And I knew—and a few other students who were like, “Oh, you’ve got to go do graph theory, or group theory.” And I was like—it went way too fast. And I suddenly realized I didn’t have the skills to keep up with those topics. But in the meantime, starting almost from my first month I entered the math department, I had been learning to program because they had I think one of the first-year undergraduate courses was programming in Pascal."

Quoting from 'Oral History of Guido van Rossum', https://www.computerhistory.org/collections/catalog/10273871...


Thank you for the correction. I should have said “trained”.

I believe that "trained" is also not the correct characterization.

He got his degree in CS at a time when CS at the University of Amsterdam was part of the math department. He also took CS classes at Vrije Universiteit, under an arrangement where students could attend courses at either school.

He didn't study group or graph theory and was not interested in mathematics. Instead, he took computer classes:

> the programming classes I got at University of Amsterdam in the math department, were a pretty haphazard collection of topics that didn’t interest me. I mean, sometimes the topics interested me. I mean I remember one semester we were all learning ALGOL 68. And the teacher was super excited, but other times, it was like numerical programming, calculating what the error is after a certain set of matrix operations. And I was not interested in anything involving floating-point numbers, basically. But Tanenbaum, or his group [at Vrije Universiteit], taught topics like operating systems, databases, networks, and languages, I believe. Yeah, Tanenbaum himself did a class where he taught like seven non-mainstream programming languages. And that was all I just soaked that up.

The math department had to "customize" his degree "a little bit for [his] situation."

There is no indication of being a trained mathematician, neither as someone trained to do mathematical research, nor trained to apply mathematics to other problems.

I have an undergrad degree in math, having taken the course for both pure and applied tracks, and even when I was fresh out of college I wouldn't say I was trained to be a mathematician.


Kotlin didn't target LLVM at all when it was designed, that feature came much later. The primary target for Kotlin is and always was the JVM. And Kotlin was designed with usability in mind from day one, that was the justification for it. Weird to say Kotlin define programming as serving the compiler. The compiler bends over backwards to serve the user.

Thank you for the correction

Rust isn't so much "competing" as it is "complimentary" to python. This is very much how python was billed originally as a scripting language for "C" in it's early days.

The slow parts of your python program can be rewritten in rust or C, your choice. So refreshing.


To me, this was one of the greatest strengths of early Python: humility.

It didn't try to be everything (high performing, compile-time static typing) to everyone (novice, intermediate, expert, academic).

It instead made it easy to solve critical needs (e.g. highest performance hot code) by interoperating with an existing solution that did them well.


Can you elaborate on Ruby explicitly ignoring the community centric design process?

Ruby’s syntax is pretty accessible and powerful and Matz was explicit about having developer happiness as a design goal.


I feel like if #1 was done today, there is no way on god's green earth that whitespace would be used for code blocks.

It is far and away the most common footgun novices run into when I'm answering questions about why their code doesn't work.


My background is philosophy of language. I studied formal/mathematical logic in grad school. I was always embarrassed that I couldn't code, but the computer sciences classes were teaching languages that were inscrutable for someone even with my background, with syntax heavily focused on jargony math and technical concepts like object orientation (likely java at the time).

Around 2010, I was talking about this with friend about this failing of mine, and he said "you should try python, I've heard it is popular with non-math folks." So I bought a book, and as soon as I opened it, I could just read it. It took me a couple days of reading to wrap my head around object orientation, but on the functional side, I could have written fizz buzz like, maybe half an hour after opening the book.

Humans have logic pre-built into our brains, it's just that we use natural language as our syntax. Python cleverly used as much of the natural language syntax as was practicable to remove the barriers to entry for non-math majors. Whitespace is perfect example of a natural language syntax feature.


The whitespace thing is actually one of python's major flaws. That feature attaches syntactic meaning to non-printing characters. From a human standpoint, there're many examples of silence having some kind of meaning. From an engineering standpoint, that entire methodology is insane. Communication needs to be positive and deliberate.

Remember that Apple SSL bug "goto fail"? That was a whitespace bug, because even if the C feature predated python, everyone's eyes had been trained to slide right off that particularly crass shortcut as python was widespread by that point.


>Communication needs to be positive and deliberate.

I don't know what you mean by this.

>The whitespace thing is actually one of python's major flaws. That feature attaches syntactic meaning to non-printing characters. From a human standpoint, there're many examples of silence having some kind of meaning. From an engineering standpoint, that entire methodology is insane.

It's not non-printed characters, it's alignment. The period is a parallel for the semicolon in programming, to signal the end of a unit, but the whitespace in python is a parallel to the bullet point, or poetic stanza. Those both parallel to python in the form of atomic statements.

Most people's concern is the hanging indentation. Here, I would argue that we can effectively prove that hanging indentation is vastly more parallel to natural language than braces. Simply search for "handwritten recipes" and you will see that in a natural language assembly exercises -- effectively a real world parallel to programming -- human beings naturally default to hanging indentation when grouping sub-categories of items together.

https://duckduckgo.com/?q=handwritten+recipes&iar=images

Does this parallel to the jargony math you'll find in math books? No. But it trivially flows from human beings in the real world, and there is nothing formally incorrect in the syntax. Thus, we would likely find that layperson would intuitively understand the hanging indentation, where as braces as syntax is jargony, and must be learned.


There's functionally little difference between spaces being non-printable characters, unless there are examples of text editors that do not render offset empty space when they're used.

Spaces vs tabs, sure, that's an argument.

But it doesn't seem reasonable to argue that {something that is visible in a text editor} is different than any other kind of character.

It's not like Python was using the bell ASCII or somesuch.


I don't think it has anything to do with Python. I had plenty of 'if' errors in C++ caused by indenting the second line and not putting braces around it prior to Python. They were always painful to debug. I finally just _always_ put a brace around an 'if' block, regardless of whether it is one line or many, and I've never had that problem again. I think the problem is that C lets you omit the brace for one line; it should always require a brace.

Python executes like it reads, which seems like a positive feature to me. Makes errors like C's two-line if block impossible.


> It is far and away the most common footgun novices run into when I'm answering questions about why their code doesn't work.

It was, in my experience, before Python 3 clamped down on mixed spaces on tabs; before the `SyntaxError`s got better (for example the handling of `try` without `except`); and before VSCode got so popular (such that all the novices were using who-even-knows-what random editor and you had to figure out every time how they were actually producing the indentation, whether it does/can convert tabs to spaces).

And, oddly enough, before LLMs. Not so much because they explain anything all that well, but because lazy clueless people now get correctly indented code generated in-place rather than copying and pasting from Stack Overflow and not having any clue how to make the pasted code line up properly.

But now I far more often see people who are clueless enough that they can't distinguish the REPL from a command line ("why is `pip install ...` a syntax error?"), or are struggling with whatever is the latest attempt by the Python team to make Python easier to install and manage on Windows, or who seemingly can't wrap their head around the idea that Python has to know where on disk to look for the installed libraries (or why it won't work to just put everything in the system environment). And in terms of the language itself, probably the biggest stumbling blocks are things like command-query separation ("why can't I `foo.append(bar).append(baz)`?") and just using functions properly (which typically boils down to "why doesn't `return foo` let me refer to `foo` in the calling function?", but generally stated completely differently).


Whitespace cleanliness is only part of the problem. The much bigger issue is the fact that the ending of a block is invisible. This leads to several problems:

1. It becomes much more difficult to tell beginners where the end of a block is, because the ending of the block isn't something you can describe verbally. You have to point to it instead.

2. Students who might be prone to using the wrong number of "}" or "end" tokens to close a block will instead un-indent the wrong number of times. It doesn't prevent the kinds of mistakes that mismatched parens tend to cause.

3. When closing a block, the thing you're trying to align a prior block with might not be on screen any longer. I don't know why, but I've seen more off-by-one spacing gaffes after the close of a nested block than I ever expected to see.

That said, I don't doubt that Python arrived at the choice of whitespace blocks empirically. However, I highly suspect that the majority of the users learning how to program in the late 80's and early 90's were familiar with monospaced text, which was ever-present in most productivity applications of the day, and thus easier for them to reason about.

And to be clear, I don't really care that much about Python's whitespace blocks. I don't like them, but I'm at the age where I feel like quibbling over minor syntax gaffes is beneath me, and Python is my top "swiss army knife" language when I need a job done quickly. My only point is that I feel like whitespace blocks are a relic of the time when they were developed, and I don't think they are as beginner friendly as advertised.

EDIT: After stepping away from the post, I realized that in my perfect world, a beginner language would look a lot more like Lua than Python. Then I remembered how popular Roblox is, and how popular Garry's Mod was before that. Given the success of those platforms, there might be something to it.


#1 helps make Python maybe the most readable language which is probably more important than some minor hassles formatting it.

Previously:

- Perl's decline was cultural - https://news.ycombinator.com/item?id=46175112 - Dec 2025 (460 comments)

- (!) Ask HN: Why did Python win? - https://news.ycombinator.com/item?id=37308747 - Aug 2023 (839 comments)

- Ask HN: Why is Python so popular for ML/DS? - https://news.ycombinator.com/item?id=16207834 - Jan 2018 (19 comments)

- Ask HN: Is Python dying? - https://news.ycombinator.com/item?id=11100251 - Feb 2016 (352 comments)

- Python is now the most popular introductory language at top U.S. universities - https://news.ycombinator.com/item?id=8001337 - July 2014 (362 comments)

- Ask HN: Why Python over Ruby? - https://news.ycombinator.com/item?id=682101 - July 2009 (196 comments)

- Ask HN: What does Ruby have that Python doesn't? - https://news.ycombinator.com/item?id=283639 - Aug 2008 (223 comments)


It's hardly "inexplicable"... particularly if you're comparing it to Perl, a famously hard to read language.

* Python has clean and readable syntax that a complete beginner can understand -- it's really close to the pseudocode you might use for teaching.

* Python has a good standard library, so you can do a lot before you need to work out how to install more (and, reproducibility concerns aside, `pip install` is really simple once you get there)

* Because it was easy to pick up and easy to use for teaching, it took over some niches like stats in academia / data-analysis, where the people doing the work aren't professional programmers but just need something they can hack together. Once NumPy existed, people had minimal incentive to move away.

(Insert Marge Simpson "I just think it's neat" gif here.)


> a famously hard to read language.

That's putting it lightly. Many jokes were made at Perl's expense on that topic, but

    $\=$/;for(@ARGV){open F,$_;while(<F>){print if/$_/}}
is a valid Perl program to grep for lines that are the file's name. One of the jokes was that it was a write only language and it was only half way a joke. Coming back to a pile of magic variables months later with no comments, omfg. Meanwhile, Python sometimes scarcely even needs commenting if it's a short script if the writer uses descriptive function and variable names.

Perl's downfall, was that coming back to a ball of Perl mud after say 3 years and have to fix a bug, due to lack of classes and Perl 6 being delayed forever, you were in for not lot of fun. Python isn't perfect and that's why it's grown types, but Perl was seriously write only at times.


Every programmer worth their salt must learn to use power tools, and also train to work beyond the beginner-intermediate levels, that has now become the permanent situation in our line of work.

Nobody should be spending a day writing Python to do work that can be done using a vim macro in like 5 mins. Or spend a year doing in Python what can be done in a week in Perl.

>> $\=$/;for(@ARGV){open F,$_;while(<F>){print if/$_/}}

There are lots Perl one-liner patterns, once you learn to write them. You are basically saving yourself writing many dozen man-hours of Python/Java coding work.

I remember telling my manager during the Perl days. A 10 year Java experience guy looks great, but thats basically a junior Perl dev with 6 months experience.

There is nothing to feel great about wasting effort and more importantly time.


I have used perl oneliners on and off for 20 years and because I don't need them every day I have to look up stuff every time.

Not sure your time-saving thing really works, especially if 99% of problems you have are not solved by a perl oneliner.


>>Not sure your time-saving thing really works, especially if 99% of problems you have are not solved by a perl oneliner.

That's because if you don't have a paradigm of thought, you are not likely to reach for a tool that works there.

Most of the times, I have seen Java programmers watch in total awe that their pet weekly project, that took 40+ hours to accomplish, was basically a vim macro that they could have done in like 3 - 5 mins.

That was my whole point I made, when I said, when a Java dev says they have like 10 years of experience, thats barely a Junior perl dev.

I'm guessing most Python/Java programmers would find it impossible to work in project which doesn't involve a database, XML, or json. Those languages are not designed to work with a data or a compute paradigm outside of these formats.


There is nothing to feel great about wasting effort and more importantly time.

Which is why the tasks you're talking about are being delegated to LLMs that don't GAF what the target language is.


This might be the stupidest comment I've ever read on HN. There's not a single case where using Perl is the right call. As others have joked it's a "write only"language. The garbage you write in Perl is illegible to everyone else and will be illegible to yourself once you move on to the next project and have to come back and debug your old Perl in 18months+. You think you're being clever with your Perl one liners and mini scripts but you're actually sabotaging your team. My honest opinion is that anyone who knows this and still writes Perl needs to be fired because they're actively undermining the team and the organization with code that is essentially legacy technical debt the minute it's committed to the organization repos.

You use a real language for these projects because it allows someone besides yourself to collaborate and maintain the project


>>As others have joked it's a "write only"language.

The pet project you write to replace that Perl one liner is also write only once project. The only difference is you waste years of your life doing what we do in minutes.

There is nothing to boast about wasting your life doing things that don't even have to be done.


> If you survey the language landscape now, a language can be much better than Python but never get the chance Python did just because it happened to look a bit better than Perl. Which is absurd to me.

You’re struggling to understand Python’s success because in your head the primary reason Python succeeded was because it happened to be prettier than Perl, and you can’t wrap your head around why that’s enough. But it’s not enough. Python succeeded for many reasons.


My gut feeling is that it succeeded due to escaping scrutiny. I had heard enough critiques of the language from CL folks but the rest of the world was just happy to get a nicer Perl that could be used to glue together C code into useful apps and scripts.

With respect, lispers are probably not the best people to ask how to make a widely adopted language.

Regardless, you’re regurgitating exactly what I said. Your gut is that Python was just a slightly better replacement for Perl. This is at best one dimension. If you can’t broaden your perspective, then this thread full of examples and arguments for why Python became popular will be lost on you.

If you’re so confident in your assessment, why did you bother to ask?


> My gut feeling is that it succeeded due to escaping scrutiny.

Basically every languages mostly escapes scrutiny except from very niche corners (usually people deeply committed to other languages that aren't actually considering alternatives, but criticizing everything that isn't their preferred language for not being their preferred language) until it succeeds, because there are enough of them that basically no one cares to put the time into scrutinizing them until they achieve a critical mass.

That's not why Python succeeded against other languages.


> escaping scrutiny.

What more scrutiny can a language get than people writing large projects in it over time?


Yep folks just need some glue languages that doesn’t require a lot of time to learn. Python fits the bill perfectly.

> My gut feeling is that it succeeded due to escaping scrutiny.

You keep saying it, but from 2000-2010, what scrutiny did it escape, exactly?

Are you saying when universities dropped Java/C++ for the introductory course and replaced it with Python, they simply threw dice to pick the language?

Are you saying all the Perl programmers who kept saying "Python will never have the power of CPAN" didn't exist?

Are you saying Eric Raymond never wrote an essay on the virtues of Python?


I learned Python circa 2000 as a 17 year old.

It felt pretty easy to read and write, had minimal surprises, and it made writing simple programs easy. The batteries-includedness was great.

It felt like it was designed by a smart guy for practical programming, rather than by a brilliant academic who was wed to purity for maximum elegance. It accepted some warts, but them in mostly ergonomic places.

It was dictated by people who could relegate map, filter, and reduce from builtins to the library. As much as I personally even liked map in particular (I am not super anti functional programming), it's nice to realize the designer had the taste to prefer longer but more explicit programs.

    ys = [f(x) for x in xs]
    ys = map(f, xs)
As much as I disliked that particular decision, there is no doubt to me that it is just designed for lower cognitive burden when doing simple/common things.

If you show both of those lines of code to a person in cs101 who has studied Java for a couple months but hasn't seen Python, I am pretty sure they are gonna understand the first line way quicker. Mostly consistent decision making like that leads to ergonomic, practical languages. And they win.

It fits in people's brains better. See also, pytorch vs tensorflow.


Because not many people prioritize syntax design like GvR. Even now if someone releases a new programming language most people will ask what features it has, how fast it is, how fast is the package manager etc. Because these questions are simple yes and no ones. Unlike syntax design choices.

Even if they ask about the syntax design people just dismiss their question with saying "syntax is not important". Python did the opposite, it focused on syntax over everything else. That caught on with beginners and now here we are.

Of course with AI Python got even more popular, but even before ChatGPT was released it was already dominant.


I think the reason python won was that it was easy to learn and read and was batteries included. vs perl: People need to solve their problems, not fight with syntax

Theres a lot of network effects as well. The more people were using it, the more people will use it.


Python was batteries included, in the standard library, in an era where putting those kinds of things in the standard library made sense.

Now there's tons of stuff they're deathly afraid of removing, that they would never remotely consider adding if it weren't already there. (If you don't believe me, have a flip through proposals on discuss.python.org for new additions. People think of Python as a language that's constantly adding and changing stuff and inadvertently causing breakage as a result, but it's actually very conservative relative to the volume of proposals.)


>>I think the reason python won was that it was easy to learn and read and was batteries included.

This is also a big reason why AI assisted programming will wholesale replace Python programmers.

If your are optimising for people who wish to remain at beginner levels all life, and that replaced people using power tools to solve harder and bigger problems. It shouldn't be surprising that now some automation will replace you.


Perl had the batteries and it had CPAN. Python borrowed the best bits of Perl and enjoyed a reputation which overlooked its many flaws. If it had been scrutinized as much as Perl, we'd have realized it was just as bad but in different ways.

This makes no sense.. Python _was_ heavily scrutinized when it was introduced - the whole "Perl vs Python" comparison was pretty popular for a while, with either of those being declared winner, depending on the author.

If there is really a killer argument for Perl over Python that was overlooked in all those years, why don't you say that argument, or even better, write a blog post explaining why Perl is better than Python? Then we could discuss that instead of nebulous "different ways"/


Perl had charm, it was respected by hackers for the joy it brought people who 'got' it. It still remains a beautiful language that I regret not learning due to having a superior taste. Python had none of it. I still don't understand how it won, stealing the halo of a language while having nothing of the sort. The only argument you can make is boring is better imho.

Perl hacker who tried to switch to Ruby before adopting Python here:

Of _course_ boring is better. How could it not be? If you are trying to solve a problem, the last thing you want to be thinking about is the language itself.

The language you adopt to code up a solution should force you to think clearly, but no more than that. Executable pseudocode is as close to an ideal state as you can get for a high-level language.

Perl, meanwhile, was filled with multiple ways to do things -- famously and absurdly thought of as a virtue -- reveled in side effects, and did so much implicit work with variables and flow that perl was often unreadable by anybody else, including the you of three months from now.

"Python did everything other scripting languages did, but in a cleaner and more comprehensible way" tells you most of what you need to know about Python's victory, but the death blow was delivered by the perl community's love of complexity, which led to the disaster that was Raku.

By the turn of the century, it was clear that python 3 was a better plan for the future than perl 6.


Mostly right, but

> By the turn of the century, it was clear that python 3 was a better plan for the future than perl 6.

Work on Python 3 wasn't even announced until 2006, and Perl 6 in 2000.


> it was respected by hackers for the joy it brought people who 'got' it

Isn't that the crux of the issue? Perl was great if you're a hacker who 'got' it. For the remaining 95% of the population, Python worked.

Lisp/Scheme are also beautiful to those who 'get' it.

> I still don't understand how it won, stealing the halo of a language while having nothing of the sort.

Plenty of people have already told you. 95% of programmers do programming to get the job done. The linguistics grad student I knew 20 years ago did his work in Python because it was easy (he had no programming background). He would have simply changed his thesis topic if Python didn't exist. He would not have learned Perl.

Perl was for hackers. Python was for everyone.


> Isn't that the crux of the issue? Perl was great if you're a hacker who 'got' it. For the remaining 95% of the population, Python worked.

It’s really not the crux of the issue though. “Better than Perl for normal developers” is not a high bar. Most languages clear that bar whether they are successful or not. This is certainly not the only reason that Python became so successful.

Tangentially, in my experience Perl was great for one liners and small glue projects. I never saw significant, valuable works of code built in Perl even when I worked at a company (Yahoo) that widely used Perl. I am convinced that much of Perl’s beauty is in its cleverness and’s not in its utility for large projects.


> “Better than Perl for normal developers” is not a high bar. Most languages clear that bar whether they are successful or not.

Dial the clock back to 2002, and this statement is not true. Perl became popular not because of its beauty, but because of it being extremely effective glue. It was a language to get stuff done while writing little code.

The only mainstream alternative was Python.


I see. There are two separate but related questions.

1. Why did Python replace Perl?

2. Why did Python become so extremely popular?

The answer to the first is because it’s better than Perl for so many engineers in so many cases. The answer to the second is much broader.


Did you seriously start this thread just to ask people to confirm your bias?

In that case, yes. Perl is beautiful. Python sucks and only succeeded because idiot developers couldn’t see the beauty of Perl. Python is poorly suited at every job except stealing potential Perl devs.

Feel better?


No.

Readability, explicitness, one way to do things are examples of great design taste. Perl was the opposite of all that.


I don't believe the "syntax win" scenario. Python is also ugly, due to the required indentation, like yaml.

I believe more in the ecosystem, specifically how the computer vision and machine learning movements have adopted python extensively as frontend language (the heavy weightlifting is still doing in C++). The exploit of numpy has brought many many use cases into the language as well.


Indentation is there regardless, and is increasingly enforced by format-checking tooling which is more commonly an out-of-the-box offering for many ecosystems (gofmt).

So why not make it have syntactical meaning since it’s already there in 99% of cases?

It does feel weird at first but honestly it’s not something you’ll think about much after a while.


> don't believe the "syntax win" scenario. Python is also ugly, due to the required indentation, like yaml.

That's like, your opinion. Python was explicitly designed being easy to learn, borrowing heavily from ABC, which actually experimented with different syntaxes to see what works and what doesn't. The indentations apparently helps a lot with this, along with ':' before the introduction of indented blocks.


That 'ugly' required indentation and whitespace also made Python easier to read, especially for newbies and casual coders. A standard visual structure and a syntax that is pretty close to executable pseudo-code lowered the barrier to entry for a lot of people and made Python feel 'approachable'. This perception that it was easy to use helped increase the network effects other have noted.

It's not about being beautiful or ugly, it's about being simple.

Python is simple to read / write and easier to reason about, especially for people that need a programming language to solve a problem but are not software engineers.

The reason it won, especially in data analysis, is because most data analyst are/were not software engineer and Python feels more natural to people.

The indentation is not a big problem when a decent text editor is used


> Python is also ugly, due to the required indentation, like yaml.

The fact that YAML also won in its configuration file niche doesn't give you pause?


> Python is also ugly, due to the required indentation

As opposed to the not required indentation that literally everyone who writes code ever does anyways?

> believe more in the ecosystem, specifically how the computer vision and machine learning movements have adopted python extensively

What came first, the chicken or the egg?


I was not exposed to much code before trying Python 2, and I always thought of the indentation and newlines as aesthetically pleasing and helpful. Same for yaml actually. Would argue that preferences on indentation etc. are just an acquired case.

Even for someone who has used more than one languages, I think Python is fine. It’s a lot prettier than the academic-HN preferred lispy languages.

"Ugly" is a very opinionated statement there. I personally find it's fine, and Python's required-indentation matches what I'd be doing anyway. It's no different to me than a project which lints indentation via something like gofmt.

required indendation simplified a ton of readability problem with other languages for a regular user.

There was no easy for people who wanted to get something done in a simple interface.


I think the controversy around Python’s indentation helped it gain success. Regardless of how you feel about the choice, it’s a great opportunity for bike shedding and encouraged (and still encourages) a lot of talk about the language.

There are all sorts of other arguments people make, but it's frankly incomprehensible to me that some people find indentation-based block syntax "ugly" and the alternatives not so. I must wonder if this extends as far as not indenting code in braced languages.

Python wins hands-down in having readable code.

Perl has so many ways to write the same code, no two codebases are the same - it's practically different languages. Back when I was programming Perl, I remember reading my own Perl scripts I wrote few years ago, and being annoyed with how they were doing everything all wrong... because in those few years, my Perl style has changed significantly. And others' scripts were even worse!

Plus, python had all those neat quality-of-life things useful for day-to-day scripting. For example actual function parameters, exceptions (no more "or die" after each open), pretty big stdlib (I _don't_ miss having to configure "cpan" on each new machine), repr() in language core, etc..

And yes, Python got lucky somewhat - there was a need for "Perl but easier to read and friendlier to new users", and Python has filled that need. And now that need is no longer open, so it's harder for newcomers to fill that niche. But that's life in general - Rust filled the niche of "No overheads like C++ but memory safe", Go has filled the niche of "Compiled systems language with GC" etc... And once a language gets popular, network effects kick in.


> In hindsight I think Python needed to stand on its own right, not just as a better Perl, but yet here we are.

It has. That just wasn't where the foothold was. Python has had several moments propelling it to its current position. "The early days" absolutely did not set an inexorable machine in motion. It took further boosts from fields like data science, machine learning etc. that would likely never have touched Perl even if the Perl 6 story had turned out much better.

> I think hindsight will show we should have considered the defects of Python more deeply.

There are many. I personally find that many of the commonly proposed ones are not that important, while everyone else is ignoring much more serious things. But so it goes. You can say these sorts of things about all the popular languages. "Although practicality beats purity."

> I know the lispers saw them but no one listens to them.

Lisp has had enormous hidden influence on how people write code in other languages, honestly. SICP is a revolutionary work. It just turns out that homoiconicity is not hugely useful the large percentage of the time that you don't need metaprogramming, and that the structure of the code is harder for humans to grok when it isn't explicitly marked with a variety of punctuation (rather than just parentheses).

> If you survey the language landscape now, a language can be much better than Python but never get the chance Python did just because it happened to look a bit better than Perl. Which is absurd to me.

This falls in the category of life not being fair. If you have your own ideas about how to make a Python-killer, I'd encourage you to pursue them anyway.


All true.

But also:

> It just turns out that homoiconicity is not hugely useful the large percentage of the time that you don't need metaprogramming,

It turns out that metaprogramming, like anything else, has many possible levels, and that for the shallower levels, Python's reflection, magic methods, and metaclasses suffice without too much heartburn.


Honestly I feel like even metaclasses are overused, where class decorators would often suffice.

That's probably true, but there are a few reasons for it:

- Face it, decorator syntax is kinda ugly

- History. Decorator syntax is new

- For things which will be repeatedly subclassed, the metaclass automagically tags along

But it's almost certainly easier for a maintainer to look at a decorated class and figure out what's going on.


It was designed by a person with good taste, not by a committee. That's about it, there's nothing inexplicable or accidental about a well designed language rising to the top.

The excessive mentions of Perl are weird — it, along with PHP are prime examples of awful taste. Those are the languages that only gained any traction because they happened to be available at the time, not because they were any good.


To be fair, it is my understanding that PHP is still king in the niche of "simple language with practically zero cost to spin up and deal with a web request."

Now it _may_ be that the erroneously named "serverless" architectures that are the soup du jour will make this less true, but I don't have enough insight on web stuff to know how that's proceeding.


Years ago I wrote article on this topic: https://www.notonlycode.org/why-python-has-won/

In short (all below is my opinion): it was popular in academia and got some corporate adoption, so when ML exploded in popularity it was a natural choice as the scripting language for ML tooling. On top of that it’s easy to pick up as a language, and it’s a general purpose language - there are lots of scientific tools like pandas written in it, there are web frameworks, etc.

Perl was too quirky for wide adoption and it stopped developing (Raku/Perl 6 took to long to develop), PHP was focused purely on the web, similarly JS. Ruby could have won, I like it more than Python, but outside of Japan it’s also mostly been associated with web development (because of Rails), it also lacked libraries that Python already had.


> Ruby could have won,

Seems unlikely. Its got its own fair share of Perl-inspired quirks.


Python won because Google picked it over perl in the early 2000s, declaring that it was more uniform in having one preferred way to do things rather than allowing (in contrast to Perl) programmers having a zillion ways to do things.

Larry Wall, creator of Perl, coined the phrase, "make the easy things easy, and the hard things possible". But the things perl made easy were not always things that the market needed. Perl was very distrustful of enterprise disciplines and the perl culture "let a thousand flowers bloom" mentality (which they/we called "There's more than one way to do it"/(TMTOWTDI)) was not actually useful for organizations maintaining larger code bases/systems with large groups of mixed skill level people.

Python threaded that needle of centralizing a right way to do things (not just whitespaces) more effectively.

I also observed Scala suffering from similarly disfunctional "TMTOWTDI" dynamic in organizations I belonged to; different people had wildly different styles of solving even basic problems and it really made code hard to maintain even in smaller organizations where people came and went and new people were onboarded frequently.

Plus data science use cases saved Python's web/scripting lifespan in a way slightly analogous to AI/CUDA extending NVidia's 3D graphics-centric roots. (Although the python data science ecosystem nowdays does have some TMTOWTDI weaknesses that remind me of perl/cpan's choices of web development frameworks of the mid-2000s!)


You can't only look at it from the perspective of a software engineer. Ordinary people can read and write Python much more easily than a ton of other languages. It's very easy to get started, with basically no ceremony. Highly tolerant of user errors yet still allows one to grow with the language (nobody writes ABCs on their first day).

Python has issues, but those issues don't matter equally to everyone and every use case. Low barrier to entry, coupled with Metcalfe's law, explains a lot IMO.

I love Scheme, but not everybody does, and I can see why.


> You can't only look at it from the perspective of a software engineer.

This is absolutely true.

OTOH, the "No true Scotsman" attitude that some display, that no real programmer would deliberately use Python, always says a lot about the one displaying the attitude.


Non-swe, classic engineer here

Python is easy to learn and has an extensive library catalog. It also has massive support available online. That's why I have chosen it in the past when I needed to write basic programs for work.

With the rise of LLMs, python is now even more attractive as LLMs really excel at writing it.


Python ultimately won because of its community.

The Python leadership group is friendly towards beginners and people with non-traditional backgrounds, and they actively reach out and recruit those folks to participate. It's also one of the least toxic developer communities I know of.

That matters a lot in a field like data science or cybersecurity, which has a lot of people who don't have traditional SWE backgrounds.

The language is pleasant and readable to use and has a lot of features built in, which Perl did not, but I think that's much less critical than the network effect of being a (1) welcoming and pleasant community who (2) actively recruits new fields of people.


I have recently gone all in on Python. Before I decided this, I was using Python for projects where I needed Pandas or numpy. I used React/TypeScript/Node for web applications. But, I moved to Django/HTMX.

The main reason is to avoid npm, but also, I wanted something with more built-in defaults (my web apps have simple needs). It has nothing to do with the language -- it's more the ecosystem for me.

I considered Ruby/Rails, but it didn't seem enough better than Python and can't replace the Pandas work I need to do.


Personally, I do not think there is a language in the ALGOL family tree with better syntax than Python. It removes just about all the BS: ceremony, boilerplate, curly braces, etc. Oftentimes as programmers we write out ideas as pseudocode... and that pseudocode is oftentimes coincidentally valid Python! I think this is a critical reason why Python has been so successful. It's simple and powerful at the same time.

There is a network effect with programming languages. Once you get popular, more people write libraries and guides for that language, which in turn makes it even more popular.

If you were czar of the universe and could start from scratch, could a better scripting language be created? Sure. But that’s not the fact pattern, and Python isn’t bad enough at what it does to warrant starting over.


My 2c. And only my recollection. Back in the stone age, there were two that had significant mindshare: perl and python. Of course, there were others, and they had their day in the sun too (e.g. rexx, rebol, etc.). I suspect that python stood out, and developed momentum, because of its availability on, and integration with, Windows where many of today's senior devs were cutting their teeth. Particularly, I'd point out, Mark Hammond's contributions. Suddenly, you had an accessible language with a deep integration with the underlying OS. Perl had that too, if you were using one of the unices, but most eager devs weren't - back then, linux wasn't what it is today. Perl excelled at the traditional file-based (and filelike-based) tasks. It had a good niche in early web development using cgi. But, I think python was just both more accessible in general, and more useful in general than perl - without resorting to C, or C++, or another compiled language.

Three things:

1. The Rise: 2005 - 2010 Google hired Guido van Rossum in 2005 (stayed on for seven years) and gave corporate blessing that made everyone comfortable with moving from Perl to Python. It was seen as the language of scientists and smart people so a lot of people working in misc. languages like Fortran, MATLAB, Perl moved here. To remove the speed issue the official Google mantra was "Python where we can, C++ where we must". AI heavy weights like Peter Norvig (I think he was the chief AI scientist at one point and co-author of the famous AIMA book), promoted Python to be an acceptable Lisp.

2. Near Death: 2010-2015 Python almost died due to self inflicted wound from the 2 -> 3 transition and there was a good chance it would have gone nowhere like many languages before. Guido also moved away from Google and Google seemed to have shifted it's attention to Golang (apart from the standard C++ and Java). BTW, Python's dominance was not seen positively within Google hence they stopped actively promoting it. For ex. a leaked transcript from Eric Schimdt had him saying this

   So another definition would be language to Python, a programming language I never wanted to see survive and everything in AI is being done in Python.
https://gist.github.com/sleaze/bf74291b4072abadb0b4109da3da2...

3. Resurrection: 2015-Now Data science and ML took off and Python was right there thanks to the initial sponsorship from Google and ecosystem of scientists and engineers who were familiar (including working in the two-language mode). There was no language that could rival at this point.

Most of the syntax, power considerations etc.. are side shows as most scripting languages just tap into very powerful libraries written in c/c++/fortran or wrappers around shell. Doubt that distinguishes Python to the point where it has become so dominant.


Nothing against Python but I still use Perl 5 because it works for what I need to do.

The Perl 6 redesign was announced in 2000 and it has been going on for 2 decades? Python is clearly a good programming language but the Perl 6 redesign took so long that many people gave up. Then it was renamed Raku in 2019 I think.


Because it's really enjoyable to use. If you are doing something where you can use Python, ie. you can afford the performance hit, it's hard to find reasons to not like it. Common Lisp has it all, but for some reason people can't cope with the parens. People just genuinely enjoy using Python.

Its syntax is lowest common denominator. It’s incredibly easy for people from all walks of life to pick up. It’s “good enough” for just about every task.

But really it’s because Google, Dropbox, etc made it so. Same reason Java got popular. It’s hard to beat first class corpo support even if the actual language isn’t that great.


Google certainly had a honeymoon period with Python. They hired Guido to work on some internal apps (IIRC Mondrian?). They released the original App Engine before cloud was a buzzword supporting only Python. But at some point, the default easy-to-learn language at Google became Go, and it happens to be statically typed, preventing a large class of bugs from ever being compiled. There was a manifesto about how Python and all other dynamically typed languages were unsuitable for large-scale software engineering. Only small pieces of code are still using Python.

Supporting pre-compiled native binary packages. Look at the manylinux effort for eg: https://github.com/pypa/manylinux, which spans a decade to ensure that glibc changes did not break python wheels. Every other language required a full-build pipeline for binary extensions: node-gyp for eg. Even where it was supported (such as PECL), compatibility with the language and system was always left as an afterthought and underspecified. The end-result was that the only way to "safely" install binary extensions for most languages was via distros or third-party repositories, but never via the package registry.

Slightly amusing story: the year is 1990-something and I'm in grad school working a lab where we do electromagnetic simulation. That code has to run fast, obviously, but some of us in the lab were looking for some glue language to wrap around the very utilitarian C that the simulation code was written in.

One of us started playing with Perl. He ended up dropping out and going to work as a SysAdmin.

One of us started playing with Tcl/Tk. He ended up changing majors and going into UI/UX testing.

I started playing with Python, which at that point was, I think, at 0.9.2 or something. Eventually, after some twists and turns, I went on to work on ML stuff.

Is there a lesson in that? Probably not, but somehow I find it amusing all the same.


Win what?

Against Perl? Over a decade ago. 10 years ago, the only places that required Perl were either hard engineering (i.e. non-programmer EEs) or those with legacy code bases.

Over everything else? Of course not. You don't do systems level work in Python.

The problems with Python are minor (other than packaging), and not a big enough pain to adopt another language. If you really could benefit from static typing, there are already existing languages that do the job well (C++, Rust, etc).

For the majority (including even some Perl fans), switching to Python was a significantly better experience. If you now show me a language better than Python, it's really only an incremental benefit. Sure, I prefer ML languages like F#, but the vast majority don't.


> it happened to look a bit better than Perl. Which is absurd to me.

It's not absurd, it's a debatable point. I think being easy to read is definitely a desirable quality for any language, especially for adoption. Some are better than others in this field.


python won because of enforced whitespace. It solved a social problem that other languages punted to linters, baking readability into the spec

Python was viewed as an alternative to Perl mainly because they were used for the same kinds of scripts. The biggest difference at the time, how-many-ways-to-do-it notwithstanding, was that when a novice saw a Python script of 20-50 lines, they (felt like they) understood it without having to reach for a language reference. Readability at a glance for people who hadn't yet specifically learned the language was huge. "Executable pseudocode" was the operative phrase.

One contributor that I don't see mentioned elsewhere: For many many python users, their only touchpoint for the language is reading and writing it.

Python gets a lot of grief from the perspective of people who are frustrated because they didn't start off using virtual environments and now their global python package namespace is a nightmare. Legit criticisms, but for many non-developer python users those problems are somebody else's problems. Given the readership on this site... they're most likely our problems, but we aren't the users that python is made for. We're support for those users.

It's winning because its audience is not code specialists, but other kinds of specialists which sometimes need to use code. Their work often has a sort of immediate importance that ours often doesn't. It's not evaluated based on whether the techies like it, it's evaluated based on whether the scientists, the analysist, the students, and the {non-computery-engineering} Engineers like it.


> [conflicts in virtual environments are] most likely our problems, but we aren't the users that python is made for. We're support for those users.

Maybe? I mean, if people aren't noticing these issues and you are, how are they relying on your support?

> It's winning because its audience is not code specialists, but other kinds of specialists which sometimes need to use code. Their work often has a sort of immediate importance that ours often doesn't. It's not evaluated based on whether the techies like it, it's evaluated based on whether the scientists, the analysist, the students, and the {non-computery-engineering} Engineers like it.

There is no bright line. I'm a code specialist. I use Python as a tool to help build other code. I don't have any venv problems because my git repo has everything I need in it.


I mean that several professors have learned that I'm useful for resolving packaging related problems and they contact me for help with them. They expect that if they had a job in industry then there would be somebody who they would file a ticket with and then that person would help sort out the tangle.

Also, in a previous job, I was responding to tickets of that kind (e.g. "why does installing this version of foo prevent the bar from running at a all?").

Others provide support in other ways. The guy racking and stacking GPUs at a data center somewhere is doing so, at least partially, in support of some specialist wielding python to move data around.

Sure plenty of specialists do their own stunts, but plenty others do not and instead have support, institutional or otherwise, for that kind of thing.


That makes some sense, except you're mostly describing a division of labor where the people relying on you to fix their environments probably could do it themselves if you weren't around.

I think we agree these are not typical end users.

> Others provide support in other ways. The guy racking and stacking GPUs at a data center somewhere is doing so, at least partially, in support of some specialist wielding python to move data around.

I mean, the farmers help to feed me, too. Where do you draw the line?


My point is that they are typical. I think there are legions of them. Whole classrooms at a time, whole departments at a time, people whose job is to write python according to whatever procedures came down from on high.

We don't notice them because they're not participating in conversations about which programming language might be suitable. Instead they're having conversations about whether Python is necessary or whether they can get away with a spreadsheet.


> Python gets a lot of grief from the perspective of people who are frustrated because they didn't start off using virtual environments and now their global python package namespace is a nightmare.

I never got to the "nightmare" stage before learning about venvs.

But it's still nice sometimes to have an environment ready to go full of popular, non-conflicting things to play around with a REPL in.


I wonder why activating a venv ended up being implemented as a script you source (updates env vars in the current process) and deactivate (puts them back) rather than being something that puts you in a subshell (detects your current shell and re-invokes it with new vars).

subshells would let you nest venvs so you could have a "sane defaults" venv, and then you could descent into madness with another "wacky experiment" venv, and to return to sanity you'd just exit the subshell. As it is, deactivating takes you all the way out to the system package namespace (or maybe you can nest them, not sure, but it's up to the venv implementation and not your OS to restore the intermediate env).


> I wonder why activating a venv ended up being implemented as a script you source (updates env vars in the current process) and deactivate (puts them back) rather than being something that puts you in a subshell (detects your current shell and re-invokes it with new vars).

The venv is just the folders and Python stubs.

The activation script concept is probably just what happened to occur to Ian Bicking first. But also maybe the subshell UX isn't so pleasant on Windows?

Certainly others have implemented subshell-based venv management.

> As it is, deactivating takes you all the way out to the system package namespace (or maybe you can nest them, not sure, but it's up to the venv implementation and not your OS to restore the intermediate env).

The effects do not nest, at least not with the *sh activate script. You'd need to implement a stack of old environment variable settings.

But I think the use case you describe just doesn't resonate with a lot of people.


> But I think the use case you describe just doesn't resonate with a lot of people.

Yeah I suppose "flat is better than nested" is right there in the zen.

I guess I'm just an oddball. The idea of exiting all the way up to the root and finding nothing installed there except for the ability to descend into one or more specialized transient environments feels so... clean to me.


The other thing is, if you don't at least set $PS1 it gets hard to remember which level you're at.

You can configure direnv to en/disable envs based on dir enty/exit, so as long as your shell prompt shows your cwd you also know which env you're in. Less overall to think about if you bind the two states together.

I think part of why Python won is that it is community driven. Many high level languages that compete with Python are created by some big tech business or the other. But people are less trusting of programming languages created by a big tech business. There have been cases where such languages have had license changes or other problems.

Python was easy to read and write. Network effects did the rest.

Perl6 was a much greater mess than Python3.

I'm more surprised that Ruby didn't do better.


> I'm more surprised that Ruby didn't do better.

As you say,

> Network effects did the rest.

In an alternate set of universes, Ruby has Python's current position, and you are wondering why Python didn't take off. (But I suspect Ruby evolved fairly differently in those cases.) The universes where both are popular are much rarer.


I don't know if you can point to a single feature, a lot of what makes a language successful is around context and placement (javascript being a great example of this).

I think there's a few key features for python that have definitely been a big help for it:

It's highly dynamic meaning you can get running with it before understanding every detail (no compile step, no static typing etc).

It may not be the best at everything, but is a decent choice for most things, making a good generic intro language for programming.

It has good interop with low level languages - this is a big deal for data science where a less technical (from a CS perspective) user still needs the performance of a language like C/Fortran/Rust/etc. Python's pattern of "use python as a high level api for libraries in those other languages" (as in numpy, pandas, polars, pytorch etc).

That last one has been a big deal recently, python has become the de-facto language for data science as a result of this.


Perl was my introduction to web programming in the 90s, and then I moved onto python and php.

Perl’s alien syntax and how there were multiple competing “best practices” put off newcomers and made it difficult to code review.

Perl also stagnated for quite some time due to the efforts to move to Perl 6, though python likewise stalled later it already had better traction at that point.

However I’d argue that Perl lost to PHP at least as much as it lost to python. PHP was revolutionary at the time for how easy and straightforward it was to do simple web programming which was one of the big use cases for Perl.

By the early 2010s there wasn't much of any use case that made sense to choose Perl. Sysadmin scripting was clearer to review and maintain in python and golang, web applications moved to php and frameworks written in languages that didn’t have the downsides of Perl.


About 30 years ago, buying compilers retail went from the common route for beginners to more expensive than most beginners wanted to spend. And specialized professional software engineering became pretty damned expensive, too. The first of those changes made python comparatively attractive to every programmer starting out before the last 30 years who did not yet work as a programmer. The second of those changes made python comparatively attractive to every domain expert with a computer already on their desk working in an organization of any size who could not get their desired or imagined super simple and easy high-value application funded by said organization. Inevitable.

IMO, Python rode some of the growth from the data and scientific computing computing. It was lower friction for many people partially due to the amount of blogs, and open source projects that were available. Pandas and Numpy made it quite easy to get up and running with a lot of analytics. pytorch and tensorflow were also there to facilitate this, made people able to get the benefits of the optimized C code but most users did not have to learn C. Eventually FastAPI came out for those looking to build products out of their data, and FastAPI had fantastic documentation and guides, which helped these same folks coming from data/scientific compute build working software. I suppose what I am describing are some of the network effects.

I often consider how many total human lifetimes must have been spent on nothing other than dealing with and/or mitigating something as seemingly banal as Python versioning & dependency management or line ending encoding snafus.

After all these years, I assume it must measure in the tens to hundreds of thousands?

It’s in those moments of consideration that I understand humanity hasn’t done a very good job grappling with its frailty and mortality. If we had, then we’d have a crowned a winner that didn’t subjugate us endlessly to the most vapid and Sisyphean aspects of programming. Python is a lesson in managing existential angst, which I now assume was the point of it from the very beginning.


Python had a pretty big jump in 2008 when it was the first language supported by Google AppEngine. It was one of the big 3 languages used internally at Google. That's probably the first key domino in the chain.

I'd like for Julia to fill its niche myself.


Python optimized for C-interop (NumPy) just as data science exploded. While Perl won text processing, Python became the universal interface for C libraries. That ecosystem lock-in—not syntax—is why it won. It was the right glue at the right time.

I think an underrated aspect of Python's success is that is easier for non-SWE professionals to understand and use. Python is popular among software developers, but it is overwhelmingly popular among scientists.

> Python is most dominant language on the planet

By GitHub contributor counts, August 2025 marks the first time TypeScript emerged as the most used language on GitHub, surpassing Python by ~42k contributors

https://github.blog/news-insights/octoverse/octoverse-a-new-...


Python won because simplicity scales. Like English—26 letters, minimal grammar—it became the default. Python mirrors that trajectory.

It is trivially learnable, absurdly flexible, and unmatched in ecosystem leverage. No simpler language delivers comparable reach.

Python may not be so suitable for systems, real-time, or performance-critical work—that’s Rust, C, and C++.

Nevertheless, every serious engineer must know Python, just as they must know shell/bash scripting. Non-negotiable.


My totally amateur take:

Python is C/C++ but without syntax decorations and pointer problems and who cares about speed when CPU cycle is so cheap.

Python is shell but you can build large projects with a shebang change

Python is Java but with less verbosity and no company behind

If one only affords to learn/master a single language (which holds for the majority), this should be Python.

The only drawback, there is no Python interpreter in browsers (like JS and PHP). But then Python might have faced anticompetitive measures :-)



> Python is most dominant language on the planet

JavaScript would like a word!


English laughs at their supposed dominance.

Math peers through a microscope and smiles at all the Earth languages. So cute.

Math isn't a language, of course. What we oft refer to as "standard notation" is, but it is as earthy as all the others.

> of course

It's reasonable to disagree, but let's not pretend that some alternative is the obvious choice.

The laws of physics as a program and math as its language is just as good as any other framing. And its a short logical hop to expect that more than one civilization would discover that language.


To me it was Django that made python a choice of language to develop on. On top of it , not dealing with pointers of c++ made it much simpler to use.

I started my data analysis journey using Perl and then Python. Perl had also a variety of libraries, online classes from O'Reilly's, samples online, CGI support, I moved to Python when installing some dependencies became troublesome and Perl versioning was not compatible between each other don't recall the details, since then been using Python extensibly since 2.7

From the perspective on somebody who lived it:

- the first and MAIN reason is excellent windows support. Nobody wants to say this, but it was the first unix friendly community for a good scriting language to not shit on windows users.

- batteries included is frawn uppon today, but it was a BIG deal back then

- python had the best c integration system after lua and got the Numric lib because if that. It became numpy.

- it was dynamically typed, but strongly typed. No ===.

- optional parenthesis for ruby and symbols from perls were a repellant to many C and java users.

- the error messages were better than the competition.

- lisp shell without lisp

- docstrings and help()

- the packaging ecosystem that everybody craps on today was actually the best at the time. Ruby's was AWFUL at the time.

- one of the first scripting language with good namespace. Ruby could have been that but killef it with monkey patching for years.

- python found ground outside of the web unlike php, js and ruby very early

- python devs were willing to work with os devs to improve integration, and so linux and mac got system tools written in python

- django and twisted were amazing at the time. The dev server without apache was a killer feature

- google advertised they used python for the search engine and youtube. Then HN successes like reddit znd dropbox. It became so famous.

It was not inevitable at all. Just a collection of random stuff.


Because easy always wins, when enough people use something.

It’s why Windows beat DOS ( and NT beat Warp ) and why Apple then beat Microsoft.

Easy always wins.


Python succeeded because in the ages before LLM you had to be able to learn a language in order to use it and Python was easy to learn and use for beginners and for experienced devs who were too tired to use a more complex language

First class package manager, first class numeric operations for scientific usages (numpy), garbage collection, uniform human-readable syntax. Basically seems like it learned a lot from Perl both good and bad, and put those lessons into usage with the scientific community first. Kids got used to it in school and wanted to use it after.

Google used and endorsed it at a critical time back when the mainstream media machine was inflating their image. Even programmers like to ape celebrities and by extension Python was the choice of the sophisticated and well-read hacker in the know. It was just luck and dumb social reasons.

Ex-product manager of an IDE and language here. Languages, like just about anything, win because of what you can do with them: ie, value. Consider Ruby on Rails: it drove Ruby; the achievement was easily creating fullstack web apps, at just the right time. Consider VB: you could build UI apps. No languages win based on the language itself but what it lets you achieve. Usually, this is in the form of libraries:* ie, functionality that using the language lets you achieve. It's not the language, but where using the language lets you get to.

Python is a nice language, but so are others. I know of three main libraries -- three main "I can get stuff done" -- eras with Python, and I think these drove Python.

1. Beautiful Soup. Early/mid 2000s, web scraping and website / XML / HTML data manipulation were a thing; this library came along and made it easy. I'd heard of Python before on places like Slashdot; it was cool but Perl was more spoken of. Then, in my anecdotal experience, what I suddenly read about was not Perl or Python, but Beautiful Soup.

2. NumPy / SciPy. Python was apparently written with numerical computing in mind, and NumPy in its current form arrived a bit after BS. Early 2000s: stats and data vis folk were using R. By the 2010s, I was hearing about all these people that were not using R, but were using NumPy and SciPy.

3. AI. Until a few years ago, it was all SciPy, then with the current era, everyone is using Python -- for AI.

None of this is the language, per se. People were not 'using Python'; they were (say) using SciPy.

I think Python benefited hugely from having not a single "I can achieve stuff" value proposition, like VB did; it had three consecutively in a row.

These all had roots well before they became well-known. Enthusiasts, initial design, years of work and usage, and 'suddenly' out of nowhere everyone is using it. The common factor there is likely Python's design and community; there would be lower level reasons for Python's success than the things it let users achieve, and those would be, what incentivised or led to Python being used for those libraries (value enablers) in the first place. I can't speak to that; I wasn't there in the Python community in the 90s or 2000s.

[*] Not always: Rust's value is in its memory system and safety. That is not a library but inbuilt, yet that still is something you can do, a goal, value, something you achieve using the language and thus you turn to the language in order to achieve. Rust minus that would need some other reason to be used.


> None of this is the language, per se. People were not 'using Python'; they were (say) using SciPy.

Sure, but the language itself has a lot to do with why library writers choose to target that language.


I fully agree. Most language users aren't library writers, they're library consumers. So it is what libraries exist that drives popularity -- with, and you are right, that language needing to be one that brings the library writers too in order for that to happen.

Multiple levels!


You are missing Django/Flask which have & had very high adoption.

Good point. I never heard about them as much as the others, but that may have been my bubble / area of attention. I do know they're both very popular.

Developer velocity beat the need for runtime efficiency. Created a ton of code that technically is not production ready but good enough and few want to admit they made the wrong choice.

No surprise that interpreted languages like Javascript, Perl, PHP and Python are disproportionately popular independent of pure language merit. The feedback loop is the killer feature.

Well if you talk to Go programmers they value their fast feedback loop too. It doesn’t just have to be interpreted languages.

The elegant syntax that is close to plain English sets it apart.

(It’s not so pretty these days though with all these type hints and other cruft that’s been added in the last ten years.)


Type hints are 100% optional, though.

And to be honest when you start using it, even just for simple things such as function signature, with the proper IDE it helps you catch mistakes.


Python won by perfecting two things: (1) syntax structure to be simple yet powerful, and (2) complete object/function standard library with module system.

Did it win? Against just Perl, or everything else?

So much easier to pick up than Perl. Even for an experienced programmer, let alone a new learner. And the rich standard library.

I think it is because it got rid of braces and semicolons and other syntactical ephemera, and had rational indent. :)

pytorch, langchain, streamlit, fastapi, and on and on ...

There are many clear reasons imo.


If you look at https://www.tiobe.com/tiobe-index/, Python's growth really started in 2018 which was before langchain, streamlit, and fastapi.

May be that Python 2 to Python 3 migration was holding it back but it is remarkable that it shows positive strides or was relatively stable even within that transition period. https://www.tiobe.com/tiobe-index/python/

Science

Hopefully RAM prices continue to increase so that we are forced to rediscover the lost art of software efficiency and optimisation.

It's the lost art for us. LLMs will probably rediscover it for its overlords (but no need - they have all RAM and GPUs already).

In a phrase: Worse Is Better



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: