[pas]

It seems Victor's vision has a hard dependency on an environment that makes this kind of meta-manipulation very natural and easy. Basically it seems his vision is the UX extension of this lower-level DX vision:

https://www.youtube.com/watch?v=8Ab3ArE8W3s "Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022)

Of course this kind of runtime freedom/power/access probably has a performance cost, aaand I have a hard time figuring out how it would work in a real-life setting.

So yeah, instead of this super-universal tinkerability what's really needed (at least in the short term) are better tools. A better strace/tcpdump, better frameworks (better batteries included in more places). More care for "post hoc" error investigation. (Yeah a 2000 line exception going back to EveFactory(AdamsRib) factory is great, but what was the incoming HTTP request? What was the value of the variables in the local scope? What was the git commit that produced this code? Etc.)

[rtkwe]

One big reason errors like that are usually unhelpful is for security. I would love it if my SQL errors printed the offending row out but that row also has PII so it can't be saved to a log. They'd need to be encrypted or stored in the database itself somehow to not ruin 10 layers of PII protections.

[VHRanger]

That's not the case or the issue for the vast majority of developers

[rtkwe]

Not everyone has to work with PII but the general rule to not log your data to generic log or stack traces still applies to everyone. On top of that tools like languages or frameworks don't know what the data they're working with does so they default to the secure option of not writing data out on errors. If you know the data isn't and it's a common spot for errors you can have the data logged by tossing a try catch statement around the pain point in your code.

[krageon]

If you write an application that makes money in a manner that involves transactions from people somehow, it will be the case for you. That is in fact the majority of developers.