1. Original logo has country charm and soul.

2. Replaced with a modern soulless logo.

3. Customer outrage!

4. Company (or open source project) comes to its senses and returns to old logo.

https://media.nbcboston.com/2025/08/cracker-barrel-split.jpg

(n.b. The Cracker Barrel Rebellion is sometimes associated with MAGA. I am very far from that, but I have to respect when people of any political stripe get something right.)

The old logo is much better.

Thinking about hand-rolled web services, I usually imagine either a stealth alcoholic's metal flask or a mad scientist's Erlenmeyer flask.

The old logo is classic and bespoke. I could recall it from memory. It's impressionable.

The new one looks like an unfunded 2005-era dorm room startup. XmlHttpRequests for sheep herders.

Thank you for the work you put in.

When I started my first job as a Data Scientist, it helped me deploy my first model to production. Since then, I’ve focused much more on engineering.

You’ve truly started an amazing journey for me.

Thank you. :)

But just now checking out the Mega Flask Tutorial, wow looks pretty awesome.

In theory, yes. In practice, no, because code is not just math, it's math written in a language with an implementation designed to target specific computing hardware, and computing hardware keeps changing. You could have the complete source code of software written 70 years ago, and at best you would need to write new code to emulate the hardware, and at worst you're SOL.

Software will only stop rotting when hardware stops changing, forever. Programs that refuse to update to take advantage of new hardware are killed by programs that do.

Not sure this is the best example. Mathematical notation evolved a lot in the last thousand years. We're not using roman numerals anymore, and the invention of 0 or of the equal sign were incredible new features.

Completely sidestepping any debate about the language design, ease of use, quality of the standard library, size of community, etc... one of its strengths these days is that standard code basically remains functional "indefinitely", since the standard is effectively frozen. Of course, this requires implementation support, but there are lots of actively maintained and even newer options popping up.

And because extensibility is baked into the standard, the language (or its usage) can "evolve" through libraries in a backwards compatible way, at least a little more so than many other languages (e.g. syntax and object system extension; notable example: Coalton).

Of course there are caveats (like true, performant async programming) and it seems to be a fairly polarizing language in both directions; "best thing since sliced bread!" and "how massively overrated and annoying to use!". But it seems to fit your description decently at least among the software I use or know of.

Consider how vastly more accessible programming has become from 1950 until the present. Imagine if math had undergone a similar transition.

>There's no reason we can't be writing code that lasts 100 years.

There are many reason this is most likely not going to happen. Code despite best effort to achieve separation of concern (in the best case) is a highly contextual piece of work. Even with a simple program with no external library, there is a full compiler/interpreter ecosystem that forms a huge dependency. And hardware platforms they abstract from are also moving target. Change is the only constant, as we say.

>Imagine having this attitude with math: "LOL loser you still use polynomials!? Weren't those invented like thousands of years ago?

Well, that might surprise you, but no, they weren't. At least, they were not dealt with as they are thought and understood today in their contemporary most common presentation. When Babylonians (c. 2000 BCE) solved quadratic equation, they didn't have anything near Descartes algebraic notation connected to geometry, and there is a long series evolution in between, and still to this days.

Mathematicians actually do make a lot of fancy innovative things all the time. Some fundamentals stay stable over millennia, yes. But also some problem stay unsolved for millennia until some outrageous move is done out of the standard.

Btw, equations and polynomials while conceptually are old, our contemporary notation is much younger, dating to the 16th century, and many aspects of mathematical notation are younger still.

Math is continually updated, clarified and rewritten. 100 years ago was before the Bourbaki group.

I understand some of your frustration, but often the newness is in response to a need for completeness or correctness. "As we've explored how to use the system, we've found some parts were missing/bad and would be better with [new thing]". That's certainly what's happening with Python.

It's like the Incompleteness Theorem, but applied to software systems.

It takes a strong will to say "no, the system is Done, warts and missing pieces and all. Deal With It". Everyone who's had to deal with TeX at any serious level can point to the downsides of that.

Even C/C++ introduces breaking changes from time to time (after decades of deprecation though).

There’s no practical reason why Python should commit to a 100+ year code stability, as all that comes at a price.

Having said that, Python 2 -> 3 is a textbook example of how not to do these things.

But you have a point, and it's not just "our industry", it's society at large that has abandoned the old in favour of incessant forgetfulness and distaste for tradition and history. I'm by no means a nostalgic but I still mourn the harsh disjoint between contemporary human discourse and historical. Some nerds still read Homer and Cicero and Goethe and Ovid and so on but if you use a trope from any of those that would have been easily recognisable as such by europeans for much of the last millenium you can be quite sure that it won't generally be recognised today.

This also means that a lot of early and mid-modern literature is partially unavailable to contemporary people, because it was traditional to implicitly use much older motifs and riff on them when writing novels and making arguments, and unless you're aware of that older material you'll miss out on it. For e.g. Don Quixote most would need an annotated version which points out and makes explicit all the references and riffing, basically destroying the jokes by explaining them upfront.

Most of my python from that era also works (python 3.1)

The problem is not really the language syntax, but how libraries change a lot.

Anyhoo, remarks like this are why the real ones use Typst now. TeX and family are stagnant, difficult to use, difficult to integrate into modern workflows, and not written in Rust.

And numpy is a) written in C, not Python, and b) is not part of Python, so it hasn't changed when 3.14 was released. The goal was to evaluate the Python 3.14 interpreter. Not to say that it wouldn't be interesting to evaluate the performance of other things as well, but that is not what I set out to do here.

If you for some reason do this, please keep the python around so I can at least look at whatever the human was aiming at. It's probably also wrong as they picked this workflow, but there's a chance it has something useful

So why not move all the resources from CPython to close the gap with features faster and replace CPython entirely?

Since this is not happening I expect there to be serious reasons, but I fail to see them. This is what I ask for.

Not only that, it is a lot easier to hack on. I might be biased, but the whole implementstion idea of PyPy seems a lot more sane.

    fib(n-1) + fib(n-2)

That said, of all the reasons stated here, it's why I don't primarily use PyPy (lots of libraries still missing)

Can't wait for PyPyPi.

When doing bioinformatics we had someone update/rewrite a tool in java and it was so much faster. Went from a couple days to some like 4 hours of runtime.

Python certainly can be used in production (my experience maintaining some web applications in Java would make me reach for python/php/ruby to create a web backend speed be dammed). Python has some great libraries.

    def fibonacci():
        a, b = 0, 1

        while True:
            yield a
            a, b = b, a+b

Ha. Undeniable proof that we had them backwards all along!

> You could rewrite that in Rust and it wouldn't be any faster.

I was asked to rewrite some NumPy image processing in C++, because NumPy worked fine for 1024px test images but balked when given 40 Mpx photos.

I cut the runtime by an order of magnitude for those large images, even before I added a bit of SIMD (just to handle one RGBX-float pixel at a time, nothing even remotely fancy).

The “NumPy has uber fast kernels that you can't beat” mentality leads people to use algorithms that do N passes over N intermediate buffers, that can all easily be replaced by a single C/C++/Rust (even Go!) loop over pixels.

Also reinforced by “you can never loop over pixels in Python - that's horribly slow!”

I'm not going to even go into the comp chem simulations I've been running, or that about 1/3 the stuff I do is embedded.

I do still use python for web dev, partly because as you say, it's not CPU-bound, and partly because Python's Django framework is amazing. But I have switched to rust for everything else.

And you're now forced to spend time hunting down places for micro-optimizations. Or worse, you end up with a weird mix of Cython and Python that can only be compiled on the developer's machine.

But this current quest to make Python faster is precisely because the sluggishness is noticeable for the task it's being used for most at the moment. That 6 second difference you note between the Optimal Python and the optimal Rust is money on the table if it translates to higher hardware requirements or more server time. When everything is optimal and you could still be 4x faster, that's a tough pill to swallow if it means spending more $$$.

Which was true, but maybe not the strongest argument. Why not use a faster language in the first place?

But it's different now. There's huge classes of problems where pytorch, jax &co. are the only options that don't suck.

Good luck competing with python code that uses them on performance.

Those are actually pretty good bets, better than most other technological and business assumptions made during projects. After all, a high percentage of projects, perhaps 95%, are either short term or fail outright.

And in my own case, anything I write that is in the 5% is certain to be rewritten from scratch by the coding team, in their preferred language.

Didn't help Microsoft axed several folks on that team too...