Earlier quoted context omitted.
You can spin up a model locally and pay yourself. Who will maintain the project if the passionate sole maintainer burns out?
Which model works well?
Qwen 3.6 27b at q6 works decently well on 24GB of VRAM
Python 3.14 compiled to metal – no interpreter
131–140 of 140 posts
Re: Python 3.14 compiled to metal – no interpreter
#132Lol, all the people squawking about how this means nothing and this is a worthless project amuses me. A lot of people just don't see it yet. This is coming for literally everything and it is so exciting. The next decade is going to be awesome.
Most of the value proposition of Python is that it calls into fast native modules. Compiling Python itself helps a little, but it isn't that big of a deal. The most prominent Python JITs have been a failure because of the tight coupling between CPython and native modules. Basically the entire Python ecosystem has deep integration into implementation details of CPython, if there was a runtime independent api like HPy,…
This isn’t about Python
Re: Python 3.14 compiled to metal – no interpreter
#133Re: Python 3.14 compiled to metal – no interpreter
#134Lol, all the people squawking about how this means nothing and this is a worthless project amuses me. A lot of people just don't see it yet. This is coming for literally everything and it is so exciting. The next decade is going to be awesome.
You can see it cause...you're a prophet right?
Not a prophet at all, but can you imagine 5 years ago, thinking that this was even possible?
Re: Python 3.14 compiled to metal – no interpreter
#135Earlier quoted context omitted.
Who will pay if someone, somewhere is not passionate about it?
You can spin up a model locally and pay yourself. Who will maintain the project if the passionate sole maintainer burns out?
I strictly use only local models, so I agree, but the project was built with Fable so my argument hinges on the assumption that the maintainer is going to continue using Fable and needs to pay for it.
Re: Python 3.14 compiled to metal – no interpreter
#136Earlier quoted context omitted.
This isn't about the shell of a calculator though, but the functionality. Like if the only operations are addition and subtraction, theoretically you could derive the effects of other operations but it's extremely limiting.
So yeah, half of Python might still be Turing-complete, but it wouldn’t really be Python for any practical purpose. Just like how a device that can’t multiply or divide is not a 4-function calculator; it’s more like an adding machine. Many of which did multiply by serial addition.
If you write a program in python, say a hello world:
'
def hello_world():
print("hello, world")
Is that not python? Yet it uses a subset of python?
That program can be run by either a python runtime, or a python subset runtime.
Now if you were to run a python subset program, like a hello world, you would get:
'
def hello_world():
print("hello, world")
Whoah, it's the same thing.
Turns out every program you write with a subset of a language, is valid for the super language.
Subjectively also, if the subset is big enough, it feels like that language, if it uses 'def' for functions, that's python. 'I know it when I see it' kinda deal.
I think the confusion comes from the mathematical folk reading "subset of X is X", and implying that "subset of X=X". But this is natural language, not mathematical language, when I say that "dog is mammal", I'm not saying that "dog = mammal" I'm saying that "dog ∈ mammal", and "subset of python ∈ python"
Re: Python 3.14 compiled to metal – no interpreter
#137Earlier quoted context omitted.
For a project like this, relying on AI assistance also makes it effectively dead in the water.
Good luck implementing and then maintaining a project of this size and complexity at ~100 lines of verified code per human developer per day.
I wonder how you arrived at that number. Is it perhaps a number that we should aspire to, if we want to write high-quality, maintainable code by hand?
Re: Python 3.14 compiled to metal – no interpreter
#138Earlier quoted context omitted.
Good luck implementing and then maintaining a project of this size and complexity at ~100 lines of verified code per human developer per day.
I wonder how you arrived at that number. Is it perhaps a number that we should aspire to, if we want to write high-quality, maintainable code by hand?
I've been doing some reading recently around what the literature expects a professional software engineer to produce in a day.
In ~1976 Mythical Man Month era it was around 5 lines of fully debugged assembly.
Code Complete 2nd edition ~2004 bumped that up to 10-50 delivered lines of code per day.
I found other estimates of around 20-60. I need to pull them altogether into a cited article.
Based on that plus my own experience I think 100 lines per day of production-level, reviewed and debugged code was a reasonably higher target for a professional software engineer up until just a couple of years ago.
Today I'm frequently pushing 2,000 to 4,000 - and that's not vibe coded junk (I can easily hit 10,000+ if I'm not reviewing anything), that's code that I've reviewed and am happy to put my name to.
Obviously counting lines of code is a stupid, easily gamed metric. But I still think there's signal there. If you want to build a sophisticated piece of software you're going to have to write a bunch of code to do it. Writing at 1,000+ lines of code per day vs 100 will get you there faster.
Re: Python 3.14 compiled to metal – no interpreter
#139[flagged]