Live data from Hacker News

Why Python keeps growing, explained

github.blog

151–160 of 459 posts

Re: Why Python keeps growing, explained

#151
post #7

Eh, they're just a lot of ways to say "path dependence". Scripting languages are basically the same exact technology with respect to each other. In the alternate universe where numpy and scipy are, let's say, numruby and sciruby, wouldn't we be here asking why Ruby keeps growing? That's not a sales pitch for python, it's a sales pitch for the concept of a scripting language; it's like saying "you should really buy a…

I think that experiment is taking shape with Elixir:

https://github.com/elixir-nx/nx

I don't see how it could ever overtake Python, but it could establish itself as a viable niche alternative.

Re: Why Python keeps growing, explained

#152
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 completely agree - but you say that like it's a bad thing. I work as a developer alongside data scientists, who might have strong knowledge of statistics or machine learning frameworks rather than traditional programming chops. For the most part they don't need to know about concurrency, memory efficiency etc, because they're using a library where those issues have been abstracted away. I think that's what makes py…

But this is a false dichotomy. The space of options isn't C++/Rust or Python. There are languages which attempt to give the best of both worlds, e.g. Julia.

> they're using a library where those issues have been abstracted away.

I work in Python, and while libraries like numpy have certainly abstracted away some of those issues, there's still so much performance left of the table because Python is still Python.

Re: Why Python keeps growing, explained

#153

Earlier quoted context omitted.

Damn! Is the rule of thumb really a 10x performance hit between Python/C++? I don’t doubt you’re correct, I’m just thinking of all the unnecessary cycles I put my poor CPU through.

Outside cases where Python is used as a thin wrapper around some C library (simple networking code, numpy, etc) 10x is frankly quite conservative. Depending on the problem space and how aggressively you optimize, it's easily multiple orders of magnitude.

Those cases are about 95% of scientific programming.

This is the first line in most scientific code:

    import numpy

Re: Why Python keeps growing, explained

#154
post #70

Earlier quoted context omitted.

You're right. What matters is that explicit block markers are easier to learn (from the student's perspective). Being easier to teach (from the teacher's perspective) doesn't matter as much.

Sure, but without the white space defined blocks it is entirely on you to teach them about the importance of formatting their code to ensure readability.

That's right. That's the other side coin. But I'm not convinced it matters that much nowadays when most languages provide code formatters.

Re: Why Python keeps growing, explained

#155

Because its easy. Because it has an interpreter. Because it has notebooks. Because it has huge set of libraries & easy library import. Because schools are teaching it. Because a lot of cloud native tools support it / prefer it.

No, because academics or professors don't care about real software enginneering and best practices.

Re: Why Python keeps growing, explained

#156

Earlier quoted context omitted.

I completely agree - but you say that like it's a bad thing. I work as a developer alongside data scientists, who might have strong knowledge of statistics or machine learning frameworks rather than traditional programming chops. For the most part they don't need to know about concurrency, memory efficiency etc, because they're using a library where those issues have been abstracted away. I think that's what makes py…

But this is a false dichotomy. The space of options isn't C++/Rust or Python. There are languages which attempt to give the best of both worlds, e.g. Julia. > they're using a library where those issues have been abstracted away. I work in Python, and while libraries like numpy have certainly abstracted away some of those issues, there's still so much performance left of the table because Python is still Python.

I'd say if you do data-intenstive computation with Numpy you are not leaving much on the table due to Python.

Re: Why Python keeps growing, explained

#157
post #130
post #57

It's interesting that people keep claiming that indentation-based blocks makes Python easier to learn and read. I've been teaching programming to students in banking, finance and insurance for a few years, using Python, and my experience with them is the opposite. They have been struggling with that a lot. They didn't pay too much attention to white spaces and tabs, probably because they are "invisible", and couldn't…

On the other hand, back in college I was a TA for an intro to programming course that used Java. This: > They didn't pay too much attention to white spaces and tabs, probably because they are "invisible" can get so much worse than people imagine, when the language doesn't enforce it. It was that experience that made me lean towards python being a good introductory language, to help people get used to correctly indent…

Agreed. Zig for example is considering triggering an error for incorrectly indented code/misleading indentation:

https://github.com/ziglang/zig/issues/35

Re: Why Python keeps growing, explained

#158
post #134
post #7

Eh, they're just a lot of ways to say "path dependence". Scripting languages are basically the same exact technology with respect to each other. In the alternate universe where numpy and scipy are, let's say, numruby and sciruby, wouldn't we be here asking why Ruby keeps growing? That's not a sales pitch for python, it's a sales pitch for the concept of a scripting language; it's like saying "you should really buy a…

Why did Rails get outcompeted by newer (and also some older) alternatives in the long run, when numpy and scipy did not? Ruby would have a much bigger market share these days if library path dependence was that powerful.

> Why did Rails get outcompeted by newer (and also some older) alternatives in the long run, when numpy and scipy did not?

Chiefly, because big money corp invested massively elsewhere.

Also by now it’s easier to find developers who are cheaper and already (only can) use javascript/python?

I think that actual technical merits are dwarfed compared to other forces at stake here.

Re: Why Python keeps growing, explained

#159
post #142

I wish I could wave a magic wand and replace all the Python in the world with JavaScript. The languages are practically equal in terms of features. They're both typeless with layered-on crutches available to make the runaway dynamism less painful. They both have weird footguns and ugly syntax and annoying design flaws, but these are different for each. So if you're forced to use both languages, it's an endless pain i…

Here's how out-of-the-loop I am: I'd don't know the command line method for invoking the JS runtime on my computer! What it is? I regularly image my laptop, so I'd like to know what the system JS command line is. (I use Linux & macOS.)

The CLI runtime that 99% of people use is Node.js, available via the same package manager where you'd get Python 3.

Its dependency management story is not great, but in general better than the horrible mess on the Python side.

On macOS there's a system runtime called JavaScriptCore.framework. It's actually a very good and useful engine. If you're writing native code, you could link to that. But of course it doesn't provide any of the Node.js API, just the JS standard library which is tiny. So the most typical use case would be to embed a JS API into your application.

Re: Why Python keeps growing, explained

#160

Earlier quoted context omitted.

I completely agree - but you say that like it's a bad thing. I work as a developer alongside data scientists, who might have strong knowledge of statistics or machine learning frameworks rather than traditional programming chops. For the most part they don't need to know about concurrency, memory efficiency etc, because they're using a library where those issues have been abstracted away. I think that's what makes py…

Most programmers don't actually need to know about that stuff, either. And most programmers who do need to know about that stuff, don't know about it.

Solving race conditions is QA's problem right? ;)
Post reply on HN