I mean, even Valve has tried it in the past, and it was a failure. Look up Steam Machines from 2010s. I consider the success of Steam Deck (thanks to flawless execution this time) as almost a minor miracle.
A failure they fully admit they learned from. Proton was the outcome of that failure, and I'd say they are well poised to make a bigger dent this time.
It's not very crazy to me. Most corporate teams are overrun with feature creep that "is very simple" (i.e. it takes 3x as long as estimated, because the codebase is a mixture of overengineered spaghetti for that one customer with edge-case requirements and legacy, combined with tests that are meant to be run in a jenkins job which takes 4h to complete).
Then, the engineers are expected to write the docs in between these tickets, and doc is seen as something "to be done within 30 minutes" - of course the docs will be comically (or tragically, depending on your perspective) bad.
Most people have 0 idea on how to write good docs, so in 30 minutes, they write stream-of-consciousness docs and return back to the ticket hell.
Most places I've been could have been upgraded with stream of consciousness. It's not surprising that they aren't all perfect, and the one place that was done to a very high standard was properly overdone, but at most places whatever counts as onboarding docs either doesn't exist, is essentially unusable, or directs me to legacy things that on day one I don't know enough to not bother with
When debugging multi-threaded env with debugpy & VSCode, VSCode jumps to code that is active in currently active thread. Is DAP something different? From briefly looking at the docs, it seems like DAP calls debugpy for Python debugging, so we're probably talking about the same experience?
- It'll be possible to print stack traces without modifying or stopping the program.
- It'll be possible to exec into a program at runtime without modifying it.
I'm not sure why the author mentions remote_pdb - this has been with Python for some time, and works since Py 2.7? Not sure what changes in 3.14 for remote_pdb.
What I'm hoping though is improved tooling around debugging Python. Currently, in my experience, VSCode (more specifically, debugpy) provides pretty much unmatched remote debugging capabilities, and I'm really hoping we can have a standardized way to connect any IDE to remote Python processes with the same UX as VSCode.
I would love to use something like Zed, but without remote debugging abilities, the IDE is pretty useless for me. Perhaps better devs don't need remote debugging, but I depend on it more than a junior in college CS program depends on AI :)
I thought the author mentioned remote pdb because it sounds like you can use it to attach to cpython now, and previously gdb would have been needed? I'm at last a few years behind on debugging cpython... But always used gdb.
> What I'm hoping though is improved tooling around debugging Python. Currently, in my experience, VSCode (more specifically, debugpy) provides pretty much unmatched remote debugging capabilities, and I'm really hoping we can have a standardized way to connect any IDE to remote Python processes with the same UX as VSCode.
This is what 3.14's remote debugging protocol gives us. And even more than that, because I believe that debugpy needs to be invoked beforehand!
The value of this tooling is you don't need to predict that you need debugging before running the program. All of your Python programs[0] can be debugged. No need to restart. No need to modify the launch parameters either: you don't need the "debug configuration" from vscode, you just need a PID.
[0]: so long as you're using the same version of Python and it has the remote debugging protocol enabled, and also you have the right OS permissions
After a certain number of years you learn that source code comments so often fall out of synch with the code itself that they're more of a liability than an asset.
> I am curious what they’ll show off at WWDC this year
Apparently, not much is planned, per [1]. I'd be very cautious about AI agents like these; from a user level, this has so many security vulnerabilities.
- Vaping damages lungs (more research needed on other possible conditions).
- Nicotine pouches damage teeth.
I suppose the healthiest way of ingesting nicotine would be nicotine pills, which exist to help people quit smoking (and which is why they are very expensive).
As I understand it, cause HR don't care about most of it.
It encourages you to put a lot of things in it which are generally not interesting, much like in the old days you'd list the ability to drive a car in your CV, or having finished the mandatory military conscription.
People prefer a one pager with relevant experiences than a five pages which include your id number, birth date and address.
You can of course do a Europass CV with less info, it's just not how people do it generally, according to the people who complained about it (I'm just reporting what I heard, I don't care about the CV format)
That's why you rotate everyone, not just those that "volunteer"... This way, you're spreading knowledge to everyone, e.g. if I'm forced to deal with an issue on code you wrote, I'm forced to learn about it.
Of course, I might have to ping you and get you to help me with it, so it's less efficient. Then again, if you leave the company, I have some knowledge about the feature, so... There's tradeoffs for sure.
In my company, we rotate every 5 months. So every 6th month, I get put into the customer-facing team for 1 month. Every other month, a different team member is on the customer-facing team.
This is still annoying, but gives you enough time to work on features, and enough time to try and crack some customer cases (though I could even see being in the customer-facing team for more than 1 month, as sometimes, this is not enough to debug the issue and provide a fix).
I've got to admit, as much as I dislike being on the customer team, it's certainly less annoying than working on features, and have constant customer issues interruptions though.
