> Also FYI for people on Linux, you need to enable unsafe WebGPU features for this to work.
Browsers on macOS do not require you to enable this feature. Does it mean it's on by default?!
136 karma · joined September 28, 2024
Browsers on macOS do not require you to enable this feature. Does it mean it's on by default?!
This is the part of contracts that I don't understand. I suppose you could (1) runtime validate any user input to the program and then (2) chain multiple functions like `safe_sqrt` that provide pre and post conditions.
In theory, this should allow the static analyzer to reason about any arbitrary input. However, this to me raises even more questions: is this practical, is this possible and why would I not try to achieve the same through types ("make invalid types unrepresentable"). Maybe I'm completely off the mark here.
How realistic is the "all function calls" part? Maybe I just don't see the bigger picture, but I would expect most function calls arguments to only be known at runtime, which of course makes static analysis not possible?
That's well put.
> But good enough hence the real question is value aka time& money invested/quality.
There's time invested SO FAR and time that will have to be invested to maintain it. In my experience, even with Fable, it's not there yet. It's the reason why it's easy to vibe code an app from scratch, but at some point when complexity significantly increases, the codebase becomes a mess.
If I extrapolate this example to my professional life, this code now manages millions of dollars, a single mistake can wipe it all out, it has to be maintained by 5 other engineers and understood by 5 other domain experts.
Both are impressive, of course, but they're hardly comparable.
who claimed that? Are you suggesting that the rewrite did not introduce any new bugs? The correct answer is, by the way, that no one knows since it's millions of lines of code no one has properly read.
> smaller, faster
I thought this has already been debunked. You could just write better zig and make it smaller, faster (and have fewer bugs!)
This is basically what LLMs do on really hard tasks. Prompt it a million times on a really hard problem and it might output the correct answer once.
I am literally LOLing at HN right now
:-) I hope you read those tests before claiming it's "scary good"
Half of HN commentators probably work on basic CRUD. Armchair experts, maybe.
Next time, please check how many Poles left Poland for western EU since they joined.
That code they're writing now will need fixing tomorrow, not 5 years later.
Most engineers realize that there's currently more tech debt being created than ever before. And it will only get worse.
I feel sorry for whoever has to work on that codebase. This is the literal definition of tech debt.
> Like are programmers and engineers using LLMs completely differently than I'm doing
No, but the complexity of the problem matters. Lots of engineers doing basic CRUD and prototyping overestimate the capabilities of LLMs.
That's definitely in the training data
People on HN are seriously delusional.
AI removed the need to know the syntax. Your grandma does not know JS but can one shot a React app. Great!
Software engineering is not and has never been about the syntax or one shotting apps. Software engineering is about managing complexity at a level that a layman could not. Your ideal word requires an AI that's capable of reasoning at 100k-1 million lines of code and not make ANY mistakes. All edge cases covered or clarified. If (when) that truly happens, software engineering will not be the first profession to go.
You can't seriously believe laymen will try to implement their own tax calculators.