Why Python keeps growing, explained

Post by osigurdson » Fri, Mar 03, 2023, 3:04 PM UTC

Yoric wrote: post #214

pletnes wrote: post #11

Python keeps growing in number of users because it’s easy to get started, has libraries to load basically any data, and to perform any task. It’s frequently the second best language but it’s the second best language for anything. By the time a python programmer has «graduated» to learning a second language, exponential growth has created a bunch of new python programmers, most of which don’t consider themselves progr…

I fully agree with the description. What worries me, though, is that the features that make Python quite good at prototyping make it rather bad at auditing for safety and security. And we live in a world in which production code is prototyping code, which means that Python code that should have remained a quick experiment – and more often than not, written by people who are not that good at Python or don't care about…

Post by wussboy » Fri, Mar 03, 2023, 3:04 PM UTC

leetrout wrote: post #227

Tangent: Something interesting (and frustrating) ... I went to the LinkedIn assessments to take the Python assessment and over half the questions were specifically about Numpy, it's API and matrix math. Which for me and what I generally do has nothing to do with "Python" and I was quite surprised to find that in the questions.

Post by jimbokun » Fri, Mar 03, 2023, 3:05 PM UTC

CipherThrowaway wrote: post #126

amelius wrote: post #66

Earlier quoted context omitted.

There are also programmers who are tired of chasing pointers and simply want to get stuff done. E.g. people who once wrote "robust" code in Rust but were "outcompeted" left and right by coworkers who churn out shiny new things at 10x the speed.

At some point, every engineer has heard this same argument but in favor of all kinds of dubious things such as emailing zip files of source code, not having tests, not having a build system, not doing IaC, not using the type system, etc. I'm sure Rust was the wrong tool for the job in your case but I find this type of get shit done argument unpersuasive in general. It overestimates the value of short-term delivery an…

Post by cauthon » Fri, Mar 03, 2023, 3:06 PM UTC

blensor wrote: post #173

CE02 wrote: post #169

One thing I’d add to this conversation, though I’m certain it’s already been stated: As many have mentioned, there is a large subset of the user base that uses Python for applied purposes in unrelated fields that couldn’t care less about more granular aspects of optimization. I work as a research assistant for international finance faculty and I would say that compared to the average Hackernews reader, I’m technologi…

I hate to admit that I very often start the python repl to just do some simple calculations. I always have multiple terminals open so instead of opening a calculator I just use python in one of the terminals.

Post by kaba0 » Fri, Mar 03, 2023, 3:08 PM UTC

codethief wrote: post #216

kaba0 wrote: post #179

Earlier quoted context omitted.

> What slows Python down is generally the "everything is an object" attitude of the interpreter Nah, it’s the interpreter itself. Due to it not having JIT compilation there is a very high ceiling it can not even in theory surpass (as opposed to things like pypy, or graal python).

I don't think this is true: Other Python runtimes and compilers (e.g. Nuitka) won't magically speed up your code to the level of C++. Python is primarily slowed down because of the fact that each attribute and method access results in multiple CALL instructions since it's dictionaries and magic methods all the way down.