Read the comments here. Look at the diversity of opinions and the number of them that, while professing love for Python, directly contradict each other. Python is verbose|concise, simple|advanced, disciplined|experimental, modern|classical.
It goes to show: something doesn't need to be actually-better. It doesn't need to be actually-simpler. It doesn't need to make your job easier or better. It needs to make people think it does that.
Python is not, in any way, revolutionary. Several contemporaries exist with similar design constraints. But Python persists because it's created a community that considers itself hygienic for avoiding any other aspect of programming. And by doing this, it can be superlative in any aspect it wants to be. It simply conjures the worst example from any given competitor and those are, by proxy, pushed onto all of them.
Did we see a glowing review of how Javascript did this? No. Javascript, despite being the most deployed programming environment family in human history, didn't do this. Python did. Because it says so, over and over.
Even if you disagree with that assessment, I think Python has had a lot less to do with pushing python to new audiences. Its community has projected it outward with an impressive degree of vigor over the years, forcing it on more and more people.
Not all of those are contradictory. For example, Python mostly stays away from cryptic syntax and implicit behavior, making it verbose, but it finds powerful ways to express common patterns, making it concise. You get a small amount of readable explicit code. The words are antonyms if you pick their meanings carefully, but they don't have to be.
Python's design isn't revolutionary, but it's good and the language happened to become popular. So it's not just well-designed, but it also has all the libraries and resources and network effects that you don't get just from having a well-designed language. I'm sure a lot of it was dumb luck, but I like the result.
JavaScript's design had much less impact on its success than Python's design did on Python's success. It was doing the right thing in the right place at the right time, and how it did that wasn't all that important - once it turned into a web standard it wasn't going away.
> Not all of those are contradictory. For example, Python mostly stays away from cryptic syntax and implicit behavior, making it verbose, but it finds powerful ways to express common patterns, making it concise.
Unsurprisingly, I disagree with this opinion. Python code is typically nearly as much as a slog as Go code, but adopts all the brutally hard parts of the common lisp's functional world by only exposing wrap-primitives.
> JavaScript's design had much less impact on its success than Python's design did on Python's success. It was doing the right thing in the right place at the right time, and how it did that wasn't all that important - once it turned into a web standard it wasn't going away.
The Python community would have us believe this. I think it's a profoundly biased and one-sided reading of the history that paints a bullseye around the target. Python's primary innovation is a community that doesn't embrace differences and growth, but rather hates and hazes it. And when change finally does happen, it happens in the way most likely to cause everyone heartache, as if to fulfill the prophecy the community made.
> And when change finally does happen, it happens in the way most likely to cause everyone heartache, as if to fulfill the prophecy the community made.
I assume you're referring to the 2 to 3 split? Which happened once and every other change has left code in an completely runnable state. Unless you're talking about the C-API then, yeah, it's a PITA to keep it current across versions.
Just today I learned about f-strings and previously not knowing about them being added to the language caused me zero heartache -- I could accomplish the exact same things using the other string formatting forms since they still work as designed.
Aside from the 2 to 3 thing I'd be interested in a concrete example of a change which caused everyone heartache because, honestly, I've never seen it and I (halfass) follow python development.
Success and popularity of a programming language is mostly determined by the platforms it supports and the libraries it has available.
Objective C and now Swift is popular because you need to use one of them (without going to great lengths to avoid it) to write iOS apps. Javascript is popular because you need it to write web apps.
C and C++ are popular because they run almost everywhere, and are the implementation languages of many operating systems and software platforms.
You need Java to develop Android, and it has an incredible amount of libraries for server side web application development.
In a similar vein, TensorFlow and Numpy/Scipy makes Python the de facto language for machine learning, "data science" and scientific programming. It also has an amazing amount of libraries for web application development, text processing, and many other common programming tasks.
Libraries and community/popularity create a positive feedback loop. Large communities create more high quality libraries, which draw in more developers, which create more libraries, etc.
All of this is to say, I don't think much of your observations about Python's design and technical qualities and evolution have much bearing on Python's success one way or another, or for any other programming language. By design or accident, Guido managed to create a community that wrote a lot of useful libraries for many different kinds of tasks, that led to the positive feedback loop leading to Python's current popularity. "Forcing" is not an appropriate term for describing this phenomenon, I think, more accurate to say they have attracted a large community by making Python useful for many different tasks.
> It goes to show: something doesn't need to be actually-better. It doesn't need to be actually-simpler. It doesn't need to make your job easier or better. It needs to make people think it does that.
I don't agree with that takeaway. You ask us to consider all the diversity of opinions here, but then you evaluate them out of context, what one person says about Python is not necessarily in reference to the metrics that another has laid out, hence, they don't "directly contradict each other".
To claim that "oh you all just think Python is less verbose than Java, but it's all hype and no fact" is utter absurdity. You seem to have had bad experience that make you think Pythonistas are the tech world's Jehovah Witnesses, when plenty of other programmers will make the same case against Javascript (especially in the Node.js context).
Why do you think Python, or any programming language, has to be "revolutionary" -- or engage in cultmindthink -- for it to become popular?
> Why do you think Python, or any programming language, has to be "revolutionary" -- or engage in cultmindthink -- for it to become popular?
I don't think it has to, and I didn't say you HAVE to. I'm saying that you can accomplish the goal with a community that prides itself on ignoring things. Python's community is even more insular and ensconced in their opinion than editor proponents. Most Vi proponents can tell you about how they know Emacs and hate it (and vice versa). In the Python world, not knowing these things is in fact often a purity test, with GVR doing some kind of classic, "I'm just a hyperchicken lawyer" gag reel in public while in private engaging in complex debates about the very concepts he claims are inherently not understandable.
I guess I don't understand what your point is, I even less understand how you measure it, as you don't even offer up a particular language feature or PEP in which Python's purported ignorant groupthink has influenced, or even an outlandish personal anecdote ("This one guy tried to convert all our codebases into Python...").
I guess I can't personally relate since I came from Python after C/JS/Ruby/PHP and have done so not out of delusion or hype. Maybe your perception is based on having met a lot of non-erudite Python developers. Which wouldn't directly contradict the basis of the submitted article, which is that Python is an incredibly popular language, i.e. one that attracts the masses.
> Isn't it amazing how an insular group managed to independently come up with Haskell-like list comprehensions, and even give them the same name?
That's the big irony: The very same things the senior community and GVR pan are in fact their bread and butter. They're smart and informed. But the engender an attitude of willful ignorance in their community.
GVR is smart. I've been on a pretty intense private mailing list with him. He can competently talk to both advanced functional programming and OO programming. He can talk about advanced compiler and gc subjects. He just doesn't in public, because that'd weaken the message and persona he adopts in public.
You said Python developers as a whole were insular and as a whole it "prides itself on ignoring things".
I listed three different things which Python obviously got by looking to other languages. This is neither insular nor ignorant.
How do you reconcile your statement with my observation?
You replied with "The very same things the senior community and GVR pan are in fact their bread and butter."
I presumed this had something to do with the three items I listed, since that's how conversations are supposed to work.
Van Rossum has been pushing for async programming since at least Tulip, so it was certainly part of his 'bread&butter'. Thus, async/await are in category of things you claimed that he panned.
Now you say you didn't claim that?
Are you really just so pissed off that van Rossum doesn't like lambda that you want to besmirch the entire Python development community?
I believe SQL is "the most deployed programming environment family in human history". SQLite is seemingly everywhere.
Your second paragraph does not follow from the first. It could instead be that HN commenters are poor at this sort of analysis, or that people in general are poor at this sort of analysis.
What were the contemporaries with similar design constraints? I started looking at Python in 1995, and the major alternatives were Perl and Tcl. I don't remember anything close than those to Python.
I agree that Python is not revolutionary. I don't agree with your statement "avoiding any other aspect of programming". Van Rossum's ABC experience strongly influenced his ideas in how programming should be accessible to non-professional programmers, and that type of design is certainly an aspect of programming, though often overlooked.
I really don't understand "forcing it on more and more people." In some sense it's true - Python is a widely used teaching language, and as such the teachers are forcing ever more students to learn it; Python is the de facto required language for a number of fields, so again people are 'forced' to use it because their tools are often in Python.
But I don't think that's the type of force you mean?
You'll need to define some terms here. What is a "programming environment family"? Does BASIC in its various forms count? That includes Visual Basic and VBA.
Do people need to use it, or could it just be sitting there, like BASICA.EXE on an old MS-DOS distribution?
For that matter, the DOS shell is still hanging on, and it's a programming environment.
Most people use browsers on a smart phone or pad, with (as I understand it) no access to a programming environment.
I think that BASIC might actually be the dark horse I haven't considered here! Nice! I wonder if the fact that it isn't shipped on the other platforms evens that out though.
I just pulled out my surface book and Basic doesn't seem to be on my command line. I wonder if that's unique.
> SQLite is not a server.
Did I imply it was? SQLite is not a programming environment when shipped, either. An SQL server with a sufficiently large editor buffer might be able to squeak by as one.
I gather the exact opposite opinion of you: when something is aesthetically pleasing people will come up with rationalizations for why they like it, even if the real reason is difficult to describe. Similar to how in a focus group you can judge people's overall opinion but you should not focus on their specific feedback.
I am involved in many, many language communities. I've shipped software to production audiences of varying sizes in C, C++, Perl5, Common Lisp (Allegro), Common Lisp (SBCL), Ruby, Python, Scala, Ocaml, Java, JavaScript, Clojure, Haskell, F#, Typescript, Purescript, and Pony (finally!). I've used many more languages for non-trivial projects, including some now some defunct but really beautiful contenders like Nim, Io, Pike, Perl 6, Factor, Elisp, Vimscript, Coq and Idris. That's off the top of my head, I'm forgetting at least half a dozen more.
Python's community certainly feels distinct to me in this way.
But this is, of course, subjective. Your mileage may vary.
Yeah I miswrote it. I meant to phrase it differently. I love most languages on that list and didn't see my on-mobile editing had caused me to say Idris is defunct until it was too late. :(
A Javascript array comprehension [0] in theory is similar to a Python list comprehension [1]. However, the slight difference in syntax makes Python dramatically easier to read and write. Javascript dropped the feature. Pythonistas use it often.
Many programmers, even Python core devs, don't understand what makes one syntax more readable than another.
The evidence is in the usage. As I said, Javascript decided it was a bad idea, despite its popularity in Python.
Your phrasing is a little aggressive, so I'm guessing this is one of those discussions where there's no real chance to change your mind, but I'll give it a shot.
Consider one of the most friendly languages, SQL. Python comprehensions follow the same pattern as SQL.
SELECT expression FROM table WHERE condition
[expression for name in sequence if condition]
Javascript put the expression at the end.
[for (name of iterable) if (condition) expression]
Putting the expression first makes the language more declarative. The easiest languages -- SQL, HTML, etc. -- are declarative, not procedural or functional.
It's possible it was not adopted because there's a cost involved in every feature that has inconsistent support across runtime. The benefit needs to outweigh that cost.
> Putting the expression first makes the language more declarative
The case for a specific order makes less sense in a declarative language, not more.
And:
[1,2,3,4].map((x) => x * 2)
Doesn't seem substantially more or less declarative than:
[x * * 2 for x in range(1,5)]
to me. If anything, the latter example asks more of the reader because it requires an awareness of case-specific semantics.
And overall, it's simply never been clear to me what comprehensions buy in terms of readability or semantics over map/reduce/etc, and given JS cultural buy-in on some imported concepts from FP, my guess is that the marginal benefit just didn't seem worth the cost rather than it being a misstep in the specific proposed JS syntax.
Also: SQL has its points, but it's not a language I'd generally describe as easiest. Declarative DSLs tend to be largely convenient only in their domain. It may be worth admitting SQL to this discussion I suppose given the overlap between its domain and map or foreach like concepts, but is it really strictly easier to reason about how to do something this particular thing in it (and what it's actually doing) than either Python or JS? I don't think that's as straightforward an argument as you seem to have assumed.
Listen to how people who don't program describe the task of transforming each element of something. In my experience they often say something along the lines of, "I want y for each x in z," rather than, "For each x in z, I want y." The latter is more common among people who've been programming in certain languages, not the average person. I don't have systematic data collection for this, just personal experience. But the Javascript decision adds some evidence, in my view.
> it's simply never been clear to me what comprehensions buy in terms of readability or semantics over map/reduce/etc
Ask some random person off the street to read your source code. They're more likely to get the gist of code using comprehensions than code using map/reduce/etc.
> SQL ... convenient only in [its] domain.
Which is exactly the domain we're talking about when discussing comprehensions.
> Listen to how people who don't program describe the task of transforming each element of something. In my experience they often say something along the lines of, "I want y for each x in z," rather than, "For each x in z, I want y."
If we're really at the point where we're arguing between which clause order (among other potential variations in expression) is more natural across most natural language speakers, that should about wrap it up.
But to the extent that it doesn't, this assertion has the merit that it sounds like an empirically verifiable position.
> Ask some random person off the street to read your source code.
Which is worth considering, I suppose, in situations where the relevant software is being built by people being brought in off the street.
> [SQL] is exactly the domain we're talking about when discussing comprehensions.
"Exactly" overstates the case. As I said above, I recognize it's a related domain, but there's plenty of things that are easier to do with Python or Javascript than they are in SQL, even specifically with operations over every tuple in a set.
And again, declarative == easier is overgeneral assumption. Take Prolog, for example. Definitely domain-overlapped with SQL, often a poster child for declarative. I quite like it myself, but it's not always a hit at parties. Even hackathon parties.
Programming is such a rapidly growing field that I think the majority of software will be written by programmers with less than 1 year experience. For a time, anyway. Maybe in 20 or 30 years the growth will slow.
That's not what I asked for. You're asking me to accept a concrete proposition that I obviously don't. To sway me, I'd like proof, not a single example labeled evidence.
The fact that Javascript decided not to adopt the syntax seems like good evidence to me.
I'm not asking you to do anything. I'm offering you some insights. Normally people pay me for my time, but I suppose I feel like volunteering at the moment.
The fact that python decided to use a different syntax doesn't prove that it was good either.
What you volunteered to me is a mirror image of an argument you think I presented, then suggested my version was wrong.
But I'm not actually advocating for JavaScript syntax here. I just don't think list comprehension syntax, as presented by python, is particularly better in comparison.
You said it's much better, then demanded that I agree with you.
> Python is not, in any way, revolutionary. Several contemporaries exist with similar design constraints.
I think it was revolutionary in its own terms. For example, list slicing was revolutionary and it reduced many lookups to the minimum. Sure, it was implemented by other (not so popular) programming languages before but not in addition of many other features like easy interpreter embedding, good reflection/metaprogramming, straightforward bindings, unicode, etc.
Now in 2018 all these things are discussable and we can objectively criticize eternal issues (e.g. interpreter lock) but Python showed that you can write applications in a concise way without a lot of boilerplate. I would love to see a programming language that progresses from this point.
I think this is precisely what I said. If you discount any other competitor and what they did, Python was revolutionary within itself. Which is not all bad, it means the language has had progress. But it's a very narrow metric.
It's surely the case that other binary interpreters are more deployed. But shipped interpreter with free input, a runtime, debugger and (for nearly every implementation, an interactive visual editor).
Office Macros (and the underlying Windows COM interfaces), which include all of those features if you enable it. Bash.
Desktops versions of browsers have all those things you listed. Mobile browsers do not. Also only modern-ish desktop browsers have that feature set, for a very long time the predominant browser of the day hardly had any debugging experience worth mentioning, the two I've listed have had them for a long, long time.
> Office Macros (and the underlying Windows COM interfaces), which include all of those features if you enable it. Bash.
Bash is a good one! But I think windows ships without it. Office Macros are a really good one. Excel is also really good. But I think Windows technically ships without both, whereas the current browser is technically a full on programming environment and has been there since (minimally) IE7, which was a long, long time ago.
Sorry, I did kinda cheat on the way I defined my statement tho.
It goes to show: something doesn't need to be actually-better. It doesn't need to be actually-simpler. It doesn't need to make your job easier or better. It needs to make people think it does that.
Python is not, in any way, revolutionary. Several contemporaries exist with similar design constraints. But Python persists because it's created a community that considers itself hygienic for avoiding any other aspect of programming. And by doing this, it can be superlative in any aspect it wants to be. It simply conjures the worst example from any given competitor and those are, by proxy, pushed onto all of them.
Did we see a glowing review of how Javascript did this? No. Javascript, despite being the most deployed programming environment family in human history, didn't do this. Python did. Because it says so, over and over.
Even if you disagree with that assessment, I think Python has had a lot less to do with pushing python to new audiences. Its community has projected it outward with an impressive degree of vigor over the years, forcing it on more and more people.