undefined | Better HN

0 pointseesmith6y ago0 comments

I can't help but interpret your response as "Python 3 is better in every way ... for the ways I think are important."

For some of my programs, Python startup time is the main overhead. I avoid NumPy and SciPy if at all possible because they have a huge startup overhead.

Some of this is inherent in those packages. NumPy internally imports everything so someone can do "import numpy as np; np.package.subpackage.module.function()" without doing the intermediate imports.

This means NumPy is optimized for programmers (especially novice programmers) using NumPy in long-lived processes where startup cost is a negligible overhead.

Which isn't all use-cases for numeric computing.

15 years ago I supported a CGI-based web app. It was very important to pull out all the stops (delay imports until needed, use zip packages) because it was easier to do that than to re-write everything for another architecture.

The dog does count pretty well after all.

> It's the job of library and app authors to update.

Why? Linus Torvalds doesn't agree with you, for one.

As Hinsen points out,

] Unfortunately, the need for long-term stability is rather specific to scientific users, and not even all of them require it (see e.g. these two tweets by Titus Brown). So while Python 3 is probably a step forward for most Python users, it’s mostly a calamity for computational science.

Some scientific code has been able to run unchanged since the 1970s, through multiple new Fortran language releases.

Now, yes, I know the reasons for the changes to Python. I know the funding and organizational realities.

But why not recognize that for some situations Python 3 is not better?

Hinsen also comments on your proposal:

] The implication is that breaking changes in the infrastructure layers are OK and must be absorbed by the maintainers of layers 3 and 4. In view of what I just said about layer 4, it should be obvious that I don’t agree at all with this point of view. But even concerning layer 3, I find it a bit arrogant. The message to research communities with weaker code development traditions, and thus fewer resources, is that their work doesn’t matter.

> Could Hinsen (and others) not just version their deps?

He addresses that, I think. One of the other commenters gives a more complete reply at https://metarabbit.wordpress.com/2017/11/18/numpy-scipy-back... ending "Freezing the versions solves some problems, but does not solve the whole issue of backwards compatibility.".

> Time to forget all about this and build cool stuff, please please please.

I'll quote Hinsen again "I find it a bit arrogant. The message to research communities with weaker code development traditions, and thus fewer resources, is that their work doesn’t matter."

Your implicit statement is that mmtk (Hinsen's code base) isn't "cool stuff". Why? Simply because it's old, or because you don't know about it or need it? What other cool old stuff will die because it's part of a community without the resources to update?

Instead, accept that that loss is part of the trade-offs, be empathetic to those who suffer, and bear those lessons in mind for future work you do.

0 comments

3 comments · 1 top-level

camgunz6y ago· 2 in thread

Well, I'd like to start off by saying I think we agree overall. I do think Python 3's advantages didn't merit its disadvantages until many years after the initial release.

Second, I admit to engaging in hyperbole when I said "Python 3 is better in every way"; usually I'm on the other side of these, but I'm just so fed up with people complaining. But you're right, there are still ways Python 3 isn't "better". I'd love to have productive, technical discussions about them, but we can't seem to get beyond the "Python 3 was a super bad idea" stuff, and I'm totally uninterested in that.

But beyond that, you and I are mostly talking about different things. Python 3 isn't NumPy or SciPy. If you're building extensions on top of them, you need to look at their compatibility commitments. If you want them to make more commitments, you have to convince them. This isn't specific to software engineering; this is due diligence for anything you're gonna put years of work into.

Django's page [1] is a great example of this. Python has one too [2]. I don't have any idea about SciPy/NumPy; It looks like SciPy 1.2.0 was an LTS release supported until 1/1/2020, but what do I know.

But importantly, the end result of this "hey, do 100x the work otherwise our science won't be reproducible" stuff will be to force people out of producing free software for scientific computing. And the non-free stuff is expensive, good god. Surely this isn't what you want.

A better tactic here is to work with the developers in establishing more compatibility between releases. You probably aren't gonna get Fortran levels of compatibility--a language and platform that's seen very, very little change over the decades. But then again, the core selling point of scientific Python is that you get to use a modern platform with modern features. Asking for that along with a 50 year compatibility guarantee is a laughably tall order: you can't have it both ways without exponential amounts of work. So just like you're asking other engineers to be empathetic and respect your need for more compatibility with your extensions, you need to be more empathetic and respect their resources. And the best place to do that is probably their contact page [3], not Twitter, HN, or random blogs.

[1]: https://www.djangoproject.com/download/#supported-versions

[2]: https://devguide.python.org/#status-of-python-branches

[3]: https://www.scipy.org/scipylib/mailing-lists.html

eesmithOP6y ago

You write "we can't seem to get beyond the "Python 3 was a super bad idea" stuff, and I'm totally uninterested in that."

Perhaps your "fed up"-ness means you overlook conversations which do go beyond that? Or do you put me into that category as well?

> Python 3 isn't NumPy or SciPy. ... this is due diligence for anything you're gonna put years of work into.

Hinsen's essay discussed these issues related to "software layers and the lifecycle of digital scientific knowledge". He put Python in layer 1, and NumPy/Scipy in layer 2.

In his essay he also said "I would like to see the SciPy community define its point of view on these issues openly and clearly. ... It’s OK to say that the community’s priority is developing new features and that this leaves no resources for considering stability. But then please say openly and clearly that SciPy is a community for coding-intensive research and that people who don’t have the resources to adapt to breaking changes should look elsewhere. Say openly and clearly that reproducibility beyond a two-year timescale is not the SciPy community’s business, and that those who have such needs should look elsewhere."

So I'm not convinced that we are talking about different things as you are making points I already referred to, albeit indirectly.

I'm also not sure you understood all of Hinsen's points. I say this because you wrote ""hey, do 100x the work otherwise our science won't be reproducible" stuff"

But Hinsen said "Layer 4 code is the focus of the reproducible research movement" and "the best practices recommended for reproducible research can be summarized as “freeze and publish layer 4 code” -- a solution you mentioned earlier.

It's just that reproducibility isn't the only goal for stability.

Another is to be able to go back to a 15 year old project and keep working on it, without taking the hit of rewriting it to a new, albeit similar, language.

I also have a small amount of umbrage about your comment:

> So just like you're asking other engineers to be empathetic and respect your need for more compatibility with your extensions, you need to be more empathetic and respect their resources.

I earlier wrote "Now, yes, I know the reasons for the changes to Python. I know the funding and organizational realities."

Did you overlook that because of your '"fed up"-ness', or was that not enough for you?

camgunz6y ago

> Perhaps your "fed up"-ness means you overlook conversations which do go beyond that? Or do you put me into that category as well?

I do put you in that category, because you seem to be focused much more on the negative, rather than being constructive and trying to find solutions to problems.

> I'm also not sure you understood all of Hinsen's points. I say this because you wrote ""hey, do 100x the work otherwise our science won't be reproducible" stuff"

I've read and directly disagreed with his essay. His points are:

- Python 2 going away orphans a lot of software, because there's a lack of resources/willingness to port to Python 3.

- Python 3 didn't provide enough value to the scientific community to justify all the breakage (this is true for almost every community, btw).

- SciPy breaks compatibility roughly every 2-3 years, which is a bad fit for the pace of scientific computing.

- Beyond that, breaking compatibility threatens reproducibility.

- The SciPy community doesn't seem to know or care about compatibility concerns.

- Projects written on top of SciPy libraries ("Layer 3" code) have to keep updating, and they don't always have resources/willingness to do that.

- It would be cool if SciPy laid out a support schedule.

- It isn't cool that SciPy says, "hey use us", and then breaks compat all the time.

- There are some languages/platforms that haven't changed in decades, this isn't an excuse.

Here's what I've said:

- Agree Python 3 didn't provide enough value.

- If you want to build something on SciPy that you expect to last for decades, you should look for a compat guarantee. If you don't, that's on you.

- If you want new features plus decades of compat, that's a ludicrous amount of work.

- If you want to find a way forward, start a dialogue with SciPy devs.

Hinson's examples of Fortran and Java are illuminating. Fortran's a platform that's seen very minimal evolution over its history. That's exactly the reason people want to use SciPy instead of Fortran. Java's a platform with... billions of engineering hours? It's ironic that a guy who doesn't want to spend the resources to update his own software is asserting that someone else can continually deliver a modern scientific computing platform with new features while never breaking compat, they just don't feel like it ("It's all a matter of policy, not technology"). That's wrong, it's a question of resources.

---

My diagnosis here is communication breakdown. Everyone here wants the same thing: use a modern software stack for scientific computing. So again I'll say get on the mailing lists, get on IRC, go to the conferences, and talk to the engineers. Be constructive.

j / k navigate · click thread line to collapse