HN user
Work out how many bowling alleys there are and how many of them are in the market for an upgrade or a fresh install, trying to get to be the king of that hill is a lot of work and risk for not really life changing rewards compared with what a self-avowed SRE could make just pulling paychecks
My guess:
1) New cars are too cheap to make at scale.
2) Old cars are quite unsafe to drive, comparatively (airbags, backup cameras, lane departure alerts, blind angle alerts, etc)
With respect to bowling alleys, for things like professional shows or food safety it's a bit more than "nobody got fired for buying IBM". The stuff's gotta be able to survive field conditions and not cost millions of dollars in refunded show tickets or spoiled foods. Manufacturers test and make themselves accountable for this. Cheap, customized modules work until they don't, and by then the engineer who put the custom system together in the first place isn't there to fix them. Who would you call when some quick-and-dirty integration code that was burned into these embedded modules without ever being put in a source versioning system fails in some weird edge condition? OP is an SRE, it's ok for him, but the average farmer or show operator doesn't have the skill.
I've worked with similar tools and while they're impressive, it's too often the case that the LLM literally makes up fake but realistic looking data and pretends that it's real. This includes pretty deep fakery like setting up mock database connectors so that it looks like you're fetching data from the right place, but it's just getting synthetic data
How does this guard against that?
I agree that a lot of progress in math comes from refactorings and novel concepts that generalize neatly. My point is that those breakthroughs don't happen through refactoring in a vacuum, they happen because the refactoring is undertaken with a specific motivation. It often ends up having more general applications than the original motivation, but doing it without a specific motivation doesn't usually yield progress.
It's the same as with software refactoring. If you refactor without a sense of what you want to get out of the refactor, how do you know whether you're refactoring the right things?
(Also just my opinion)
All this would be way more interesting if it actually helped to demonstrate a novel mathematical fact. Right now it's more like notational play.
The boat seems to go faster with the sails on the wrong side (back winded), that doesn't make a ton of physical sense to me
Besides the legal requirement, the reason these companies go public is often to provide liquidity for early investors or employees. So they do want to have as good of a margin story that they can, at least in terms of unit margin.
Terminal? We don't know if worse is yet to come.
They only have the power to mess up dozens of kids' futures each...
Just serialize stuff to text if somebody wants to "edit" and then parse it back when they are done. What happens to the text in between of course is the programmer's problem.
I think that's working against the way that a lot of people write code.
You need things like syntax highlighting and code completion even while typing something like "my_var = " on a line. A normal parser doesn't work here, and bailing out to make it the programmer's problem leaves the programmer with a lot of work
How does this work in the many cases where in-progress edits result in an unparseable structure?
Until it had backup storage. Which ended up being useful in 2011 when tens of thousands of mailboxes were deleted due to a software bug and needed to be recovered from tape...