kannanvijayan
Joined 16 years ago
Joined 16 years ago
Saying that this revolution is another one of those is true in a general sense, but misleading in the specific sense. Just as saying that adding 1c heat to some body of water is "more of the same" can be true in a general sense, but misleading when the water's basis temperature is 99.5c.
That is to say, periodic or gradual change induces large changes at inflection points.
It feels similar to the progression from post-WW2 technological utopianism that arose with the adoption and deployment of massive advancements in materials and mechanical, and electrical technology, to the cold-war dread of nuclear and ballistic technology.
I think the 90s saw the end of the cold war which lifted a bunch of that dread. The optimism of those days has been worn down over time.
What I remember back then is at least the pretense being sold that the technology would improve people's lives by giving them more leisure and enjoyment. That the productivity gains would be reflected in some improvement in quality of life. I think the main difference now is that this expectation has been lost by most people.
I suppose the various JIT projects are trying to come at that from different angles incrementally, but that's a genuinely hard problem as you don't see real benefits until multiple complex pieces of infrastructure are in place and with good coverage over the language.
Anyway, my hot take was misplaced.
> Sorry, that sounds a bit vague and not too different from what CPython already is doing.
With slots being available, I can see where I was misled. I went looking for a type structure that modeled the dynamic properties on an object which would be used as a typeguard, but the class itself functions as that if you're restricting the optimization to slotted properties.
Appreciate the clarfication!
More digging led to this: https://peps.python.org/pep-0659/ which seems to be what the effort is organized around?
Python's object semantics are broadly similar to Javascript, bar the prototypical inheritance chain, but with the extra complexity of potentially needing to handle dynamic `__*attr__` overrides. Optimizing for this would require a tree of hidden map objects much like JS JIT engines use. I dug around the codebase a while back looking for something like that but didn't find it. `OrderedDict` seemed promising but after more investigation that turned out to just be adding property ordering to dictionaries.
The thing is, you can build that entire hidden type structure out, AND optimize against it, without ever having to mess with things like bytecode replacement. Once you have the hidden type model, you can modify the property lookup algorithm in the VM itself (as in cpython c code) to use some annotation structure hanging off of the bytecode to look up inline caches of type-guarded fastpaths. It would be an optimized fastpath that integrated directly into the C code that interprets the GETATTR opcode.
Python is a mature production language with a lot of users. Even before it was huge - like 20 years ago when I was in college - getting a small backwards compatible API change into a python extension module (gnu readline in my case) required convincing GvR personally that the API change was necessary.
Every JIT attempt I've seen for python just tries to cut too deep in the first pass, and scope themselves too large.
I believe any successful attempt at optimizing python performance from JIT will FIRST start with a 100% semantically compatible hidden type model for optimizing object property access and method dispatch.
The single biggest performance delta in most dynamic language jits come from that, not from optimizing guards off of bytecode operations or from compiling to machine code. It's from converting hashtable lookups into constant-time guard + offset lookups.
The hidden type model is also a hard nut to crack. It needs to perserve dict semantics which have very dynamic behaviour via the various `__*__` methods, and handle exotics scope objects since scoped name lookups are the most common ones which have their own exotic behaviours (I remember python providing some ability for callee frames to inspect caller scopes in some limited ways).
What does good enough look like for various use cases, when do we hit it, and can these companies guard that territory?
I was genuinely considering whether or not I still liked programming - the excitement and risk of technical failure had dropped off. Most failures were for other organizational and process and management reasons. I respect the value of executing those aspects well, but I have no interest in becoming fluent in solving that class of problems. It just bores me. I want to build big beautiful, complex, intricate machines.
The agentic tools are, for me, a step up into tackling broader projects I had put on the shelf as "not doable without investment". I can self-fund my ideas now. Things I anticipate would have taken about a decade or so to play around with and build out as a sole developer, I'm taking on as a sole developer.
But that said, I do appreciate that we can't be sure of what exactly this churn will produce. The other factors that go along with the technical achievement aren't too rosy.
GitLab's model is different - at least it was when I moved over to it. They charged for public repositories and gave you a free private ones as a sampler for trying out the platform. That approach is far less prone to getting overrun by millions of slopositories.
GitLab never tried to be the social media of software development. Theirs is a much simpler, classical model - one of the reasons I switched to them: you pay them money, they provide you services for that money.
I guess you are asserting that this other thing is equivalent to that?
Also, where did you get the impression that trolling required the underlying opinion to be falsely held? Whoever taught you that was doing you a disservice.
Point being, I don't really think that "the US considers" carries a whole lot of weight these days.