> “ Things get significantly more complicated when an application runtime also enjoys broad popularity as a scripting engine.”
I think this phrase towards the end succinctly captures the big mistake the author is making.
All scripting is application development. Having variation of application lifetimes, deployment circumstances, etc., does not at all represent any difference of kind in terms of reliance on third party APIs, shared abstraction layers, or the standard library. It is all just application development.
I strongly disagree that these different use cases imply different requirements, e.g. for separately versioned instances of the same standard library module.
Python is not unique in this at all. The exact same phenomenon has happened since virtually the dawn of C programming. Some people make educational applications with a deployment model of sharing code or binaries from a website, some people make huge web service frameworks, some people make database drivers, some people make video games.
The same thing is true for C++, Haskell, Java, Scala and many more language ecosystems.
Scripting is different, though, because there is often little or no ability or desire to use a 3rd party library from a script. When’s the last time that you installed a bash package? (that was not distributed as a second-order effect of installing something via apt or yum or what have you). Python plays in this space - perhaps with just Perl and to a lesser degree Ruby similarly situated.
Python has to work productively for people who have never heard of pip through to those who are building multi targeted native modules as part of a complex application build.
Michael Kennedy of the Talk Python podcast refers to Python as a “full spectrum” language, and I think this discussion is a good illustration of that point.
I install new command line utilities to use in scripts all the time, rsync, cloud storage clients, silver searcher, linting tools, many things.
Same with Python. Virtually all data cleaning scripts I write rely on special scientific computing and structured data libraries.
I’d venture to guess _most_ scripts desire third party tools, because scripts are very often highly specialized for unique purposes.
> “ Python has to work productively for people who have never heard of pip through to those who are building multi targeted native modules as part of a complex application build.”
Yep, sounds pretty standard and sounds exactly like every other mainstream programming language I’ve ever used.
> I install new command line utilities to use in scripts all the time, rsync, cloud storage clients, silver searcher, linting tools, many things.
> Same with Python. Virtually all data cleaning scripts I write rely on special scientific computing and structured data libraries.
This is the point of view of a programmer.
You would be baffle by the number of people that code daily in Python without ever having used the terminal even once. They don't install 3rd party libs. They don't know how. Sometime they use some, using the ones provided by a distro like Anaconda installed from their sysadmin 5 years ago. Sometimes they are using Python emmbeded in a another system and just script that. Sometimes they teach and there is no reason to even use anything else. There are so many use cases that are just not yours.
Not to mention a lot of people don't even have the right to install anything. They are in corporate env with firewall and security policies that give them an immutable setup for years.
> Yep, sounds pretty standard and sounds exactly like every other mainstream programming language I’ve ever used.
Definitely not.
There is no other language that have all the following characteristics combined:
- very easy to learn and fast to be productive with (exclude c, c++, java, etc)
- ridiculous number of different ways it used IRL (exclude ruby, php, bash, etc)
- very heterogeneous user base (exclude JS, perl, c#, etc)
Python is used in banking, by geographers, in embedded systems, in movie pipeline. Several OS rely on it, the education system is using it everywhere, it is included as a scripting engine in strange systems...
Yes, you can find that some languages have similarities for some situations. But not all of them. The closest one in JS, and yet, it doesn't come close because most people use JS in one plateform: the browser. The other use cases are dwarfed by it.
You could argue with each point individually, but combined, it would be moot. Scripting in C/C++ is not popular. People don't regularly analyze their biological data in Javascript. It is not a common thing to make operating system core services in Java. C# is not even a blimp in Unix, or bash on Windows. Perl user base is dying. Lisp/Haskell/Ocaml are still niche languages after decades. Ruby and PHP never got out of the Web.
And yes, this put the language in a very odd position.
It definitely doesn't "sounds pretty standard and sounds exactly like every other mainstream programming language".
There is literally zero example of a similar occurrence in the history of programming.
JS is very popular and has a large user base. But it's not very heterogenous, espacially compared to Python.
The vast majority of JS coders are interested in the web. A few for apps and UI in other area thanks to react native and electron. The rest is anecdotal.
There is not an entire banking industry analyzing data with JS. Biologists and chemists do not rely on JS to make their models. JS is not the de facto solution for machine learning. GIS systems are not massively scripted in JS. The cinema industry do not include JS as a core element in their rendering pipeline. No sysadmin every said "well, I know how to provision those 300 servers, I'll make a JS script". Security experts don't reach first to JS for pentesting. apt is not coded in JS. JS is not the stuff that all students will be taught in math classes. If you have a dumped csv to download from an ftp to insert in your database every night, JS is certainly not the first tool that comes to mind.
I could go on and on.
Not saying you can't do this is JS. Not saying it never happens. It's just not popular to do it.
All those tasks match some kind of user base, with different profiles, needs, skills and constraints.
> All scripting is application development. Having variation of application lifetimes, deployment circumstances, etc., does not at all represent any difference of kind in terms of reliance on third party APIs, shared abstraction layers, or the standard library. It is all just application development.
In the same way that boiling pasta is cooking.
> I strongly disagree that these different use cases imply different requirements,
But a art major student and a haute cuisine chef have vastly different needs in the way their kitchen is setup.
It just happens that Python serve the whole spectrum of user base.
You are seeing this from the point of view of a programmer. There is a enormous quantify of Python coders that are not. They don't have an IDE. Don't know what an env var is. Are not able to install dependencies. And they chose Python because it doesn't force them to.
> e.g. for separately versioned instances of the same standard library module.
How to address it properly is a different issue, and requires indeed a debate.
> The exact same phenomenon has happened since virtually the dawn of C programming.
No. Geographers don't casually code in C. Math teachers don't have to teach it everywhere. You cannot be productive in C after 7 days of dabbling with it. And hence there is a huge number of people that will never, ever use C, or any other language, but use Python.
I wish people saying that would accompany me on my job, going from company to company all day long to witness what is really happening outside of the HN bubble. Remember, if you are on this site, you are very far from 80% of the Python coders. In fact, if you even spell "Haskell" correctly, you are in another dimension.
No one would ever mention C after that. For many, Python is way closer to Excel.
> The same thing is true for C++, Haskell, Java, Scala and many more language ecosystems.
> It’s all just application development.
Some people produce fast food. Some prepare a pick nick. Some make a banquets for a family of 30.
It's all just cooking.
I'm sorry, no, this is a misguided conclusion.
Python is the only knife I know that is popular for almost all of this different use cases of cooking, but all this different types of cookers. It makes it a special case. A very special one.
Good article considering it's so rare to see people with a decent overviow of the python user base. Most just live in their use case bubble and are, as pointed in conclusion, baffled when they discover what others do with it.
In fact, the best you are at programming, the more you are likely to ignore the diversity that exist behind other entities firewalls.
I think this phrase towards the end succinctly captures the big mistake the author is making.
All scripting is application development. Having variation of application lifetimes, deployment circumstances, etc., does not at all represent any difference of kind in terms of reliance on third party APIs, shared abstraction layers, or the standard library. It is all just application development.
I strongly disagree that these different use cases imply different requirements, e.g. for separately versioned instances of the same standard library module.
Python is not unique in this at all. The exact same phenomenon has happened since virtually the dawn of C programming. Some people make educational applications with a deployment model of sharing code or binaries from a website, some people make huge web service frameworks, some people make database drivers, some people make video games.
The same thing is true for C++, Haskell, Java, Scala and many more language ecosystems.
It’s all just application development.