Hacker News Reader

Comment by ActorNightly | Hacker News Reader

> Are there any serious technical reasons not to do it?

Yes.

First is startup time. REPL cycle being fast is a big advantage for development. From a business perspective, dev time is more expensive then compute time by orders of magnitude. Every time you make a change, you have to recompile the program. Meanwhile with regular python, you can literally develop during execution.

Second is compatibility. Numpy and pytorch are ever evolving, and those are written a C extensions.

Third is LLMs. If you really want speed, Gemma27bqat that runs on a single 3090 can translate python codebase into C/C++ pretty easily. No need to have any additional execution layer. My friend at Amazon pretty much writes Java code this way - prototypes a bunch of stuff in Python, and then has an LLM write the java code thats compatible with existing intra-amazon java templates.

View on HN

I really hope I'll never need to touch code written by people who code in python and throws it at a plausible randomiser to get java or C

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

I get the "old man yells at cloud" vibes from your comment. Who cares how he got the result? I thought our job is to create working software. If this flow works for him and creates code that meets company standards, then more power to him.

However, if the output quality is crap, then well, maybe his creativity should not be rewarded. I've seem hefty amount of Map<Object, Object> in Java, written primarily by JS developers.

As an old man myself, I am quite sure the other old man has a good reason to yell at this particular cloud. Software is tremendously complex. It is one thing to write it, it is another to amend the thousands and thousands of bugs that inevitably follow, and implement the even bigger amount of adjustments and improvements successful software requires. The latter is the bane of any kind of code generation, whether is RAD, no-code, low-code or LLM ported codebases.

Any kind of code generation that proves incredibly productivity in the writing of software is kind of like saying you have a lot of money by maxing out your creditcard. Maybe you can pay it back, maybe you can't. The fact that there is no mention of future debt is exactly the kind of thing that old men get suspicious about.

I'm not saying the old men are correct. I'm just pointing out the reason for the yelling.

"Software is incredibly complex"

Who sold you on that lie? Software is anything but complex. Literally guys without any kind of degree could do it. You should try hardware design, validation, with one of them FPGA platforms. Start with something easy like a PCIe core... :-) It will plant you back in reality real quick.

The biggest scam is SWE's convincing themselves that whatever they're doing is soooo complicated!

"Who sold you on that lie? Hardware is anything but complex. Literally guys without any kind of degree could do it, just buy a breadboard and some arduino-pi or whatnot."

That's you, that's what you sound like.

"create working software" is usually just a tiny bit of the job. That software then exists and needs to be extended and maintained.

If the result is great and maintainable code, great. I imagine it won't be, as no one has actually understood it even once.

LLMs are there to get the meat of the software in. Fine tuning it is easy when you already have all the syntax written for you. With enough prompting on how you want the code laid out, the modern models do a really good job of getting it right with very minor things you have to tweak.

Repl I get it. Possibly valid point. Yet I guess same issue are valid to node.js which seems much faster in many cases and still has valid dev experience.

C compatibility / extension compatibility - nope. First, it is an issue of limited resources. Add more devs to pypy team and compatibility bugs gets fixed. Second, aren’t people writing C extensions due to python being slow? Make python fast - as pypy - and for some cases native code won’t be that crucial.

So I don’t see a real issue with pypy that could not be solved by simply moving all the dev efforts from CPython.

So are there political, personal or business issues?

>C compatibility / extension compatibility - nope. First, it is an issue of limited resources.

No, its an issue of reinventing the wheel. Native code is native code. Numpy stuff isn't going to be faster running in pypy, neither is any of the ML stuff. Stuff like FastAPI or Uvicorn aren't going see much speed increase.

In the modern world, there is basically no need for middle ground performance. In the past, when you had single core processors, making things go fast was advantageous. Now, if you need to go fast, you most likely need to go REALLY fast, at which point just go full native. Otherwise, you are going to be slowed down by network calls and other factors.

So while PyPy is a cool projects that can be an optimization on top of regular python, its not worth while trying to make Python into something it will never be

Reply on news.ycombinator.com