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.
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.
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 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).
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.
Honestly, I'm still not sure how I feel about Red Hat/IBM's journey. On one hand, RH killed (i.e. "gave to IBM to rot away") a lot of products I liked (recently, the whole JBoss stack they had, see [1] for more details).
On the other hand, a lot of the products that RH gave to IBM were really painful to use. Let me preface this by saying that I mean no disrespect to Geoffrey and his amazing work! And, also, I suspected I was too dumb to understand OptaPlanner in particular.
But OptaPlanner was definitely amazingly painful to use. The docs seemed horrible to me at the time, and the UX of the product was on the level of "the source code is there, to solve your problem, just understand the code base..." To model your problems meant that ideally, you'd pay for Red Hat's consulting, which would give you indirect access to the dev team, which would help you put your problem model into OptaPlanner.
A lot of the JBoss products I really liked were like that. Now, they'll die by slow death over at IBM with nobody giving a damn. I guess such is life.
I wish Geoffrey all the best with Timefold! I truly hope you'll turn it into whatever you desire, and that you'll always have more customers knocking at your door than you can handle!
What is the actual engineering discipline that goes into creating prompts? Other than providing more context, hacking the data with keywords like "please", etc?
Oh wow, thanks for this, had no idea there's a credit limit.
More annoying to me is that you have to use up your credits before cancelling your sub. If you have credits and you cancel your sub, you lose the credits.
With the advent of various car renting apps, I was so excited about not owning a car, and basically using just-in-time renting option. Turns out, at least in my part of the world ([0]), that it's such a PITA.
When you plan ahead, it's manageable. Sometimes, a car for renting is not available long term because people plan for the same time (e.g. holidays) and the provider doesn't have big enough car fleet to cover these peaks.
When you have an unexpected trip though, e.g. suddenly needing to go to Ikea, a spur-of-the-moment trip, etc., that's when this all falls apart. In my town, this was then 40:60, favoring no cars being available.
In the end, I just bought a car. 5 days out of the week, it sits on the street and depreciates in value. We take it on trips for the weekends, though, and have been absolutely loving it.
[0] central Europe, don't really need a car for daily life, but it's nice to have sometimes
To be honest, it's insane to me that there's no law about this. If you're a subscription business and you see 0 activity on a paying customer for 60 days, you should be required to ask them whether they want to continue using your service (and no answer should result in service cancellation).
If the streaming services did this, I'd probably have pretty much all of them. Then, instead of paying monthly, you essentially have a tab open with everyone, and you pay for whatever you stream.
Indeed, this would make me way less annoyed at the thousand and one streaming services popping up like mushrooms after a rainy day.