Hacker News Reader

Comment by GuB-42 | Hacker News Reader

I think it matters because a lot of people are doing math in python.

And if good optimizations can help run a small simulation in 1 minute instead of 2, multiplied by the number of python users, it is a lot of time gained.

And I suspect, the fib(n) situation is actually quite common. I mean, not everyone who writes python is a "real" developer, there are a lot of scientists who just want the computer to run their formulas, and they write them it the most straightforward way possible. They won't bother with high performance libraries and optimizing their algorithms just to save a few minutes, but they would appreciate if the language could make things a little faster.

And it doesn't matter in the way of "hey look, Python slow, use JS". But it is good information for Python developers and advanced users, the people who non-specialists rely on.

View on HN

Yeah, but it's like comparing the effectiveness of a shovel vs a spade when it comes to hammering nails. You should obviously use a hammer. If it's not worthwhile to get a hammer, then does it really matter whether you use the shovel or the spade?

If a lot of people use a shovel as a hammer, the people making shovels should start considering that use case. The spade manufacturers already did so they could take inspiration.

Real life tool manufacturers take "wrong" use into account. One of my preferred anecdote is the IMI Galil assault rifle, which has a built-in bottle opener. It was done because they noticed soldiers used magazines to open bottles, and it could cause damage.

Of course, it is not about choosing between a shovel and a spade, people who have a choice will use a hammer. But it doesn't mean we shouldn't do a favor to shovel bearers.

But what's the implication here if not that people should use JavaScript for better performance? That the Python Software Foundation should invest more in the performance of the reference interpreter, CPython?

The Galil magazine example has an obvious, easy-to-implement, low-cost solution with an obvious ROI. If that weren't the case, don't you think IMI would have just cautioned soldiers about potential damage to the magazines and instructed them to use a bottle opener instead?

> If a lot of people use a shovel as a hammer, the people making shovels should start considering that use case. The spade manufacturers already did so they could take inspiration.

I completely disagree.

Your example of soldiers and their multi-tool use falsely conflates utility with necessity.

First, civilians generally don't have access to assault rifles (to even consider using it as a bottle opener) - i.e. soldiers are an edge case. Secondly, civilians who have direct access to bottle openers don't even need assault rifles - i.e. most people don't need edge-case solutions.

In the real world, when people want a hammer, they buy a hammer. They don't use shovels for hammering, unless they're forced to use one, or have no other option.

In the programming world all popular programming languages are virtually free. Programmers can choose and select between them. Modifying a language just so that it can do every specific thing (rather than the few things it is good at, or which its ecosystem is good at) is architecturally poor language design. And an excellent way to mess up the language - e.g. see PHP.

A tool should not need to accommodate to the whims and needs of every user. To use your analogy, if the shovel users have easy access to hammers, then they can grab the hammers when they need it, not force shovels into hammers.

To do otherwise is a stupid choice on the part of users, and is in no way a weakness of the design/utility of the language/tool itself.

Reply on news.ycombinator.com