Now I hear you, but just think about what happened in the food industry when they found out customers would not pay higher prices, but would gladly eat shit if it came in the same box as their childhood reward foods.
To what are you alluding?
I suggest:
First offence: Have to watch CSPAN for 5 hours a day, for a week, without sleeping through it - evidence to be provided in court
Second offence: Have to sing Miley Cyrus songs and Baby Shark on TikTok - sober
Third offence: License to practice and all memberships of country clubs and golf courses revoked
It baffles the mind that Microsoftware - known for decades for being unreliable shit - is allowed on space missions at all, no matter how uncritical the role. The potential for malware alone is ludicrous. "Hey, pay us 2500 bitcoins if you want your space capsule back".
Then again, I figure the days when NASA did the right stuff are long past.
The real reason we will never be able to "fix" the drought is because the American West is not in a drought right now.
Basically everyone who lives in the area or studies the climate or hydrology would tell you that you're insane.
The West's rapid aridification isn't being caused by a "once-in-a-century" weather event
More like a once-in-a-millennium event. Though I suspect it's going to be considerably more common going forward.
What we're dealing with in the West is not a drought because the current lack of rainfall isn't "abnormal" for a desert. Dry is the default setting. And you can't call it a "drought" because you wish deserts were wetter.
Deserts have some amount of normal precipitation, too. And when you get a lot less than normal, that's called a drought. Yes, even in a desert.
Repeat the 1200 number a few times more, you're not making yourself look stupid enough.
No one on the planet has reliable rainfall data for even last 120 years.
We do have pretty good data from tree rings. Unless you think the trees came from somewhere else?
They tried that with Apollo 13. And.... that actually did work, sorta.
Each time some nerd says "Let them censor I have a VPN" he forgets that the next step is to crackdown on VPNs. Technical defenses against political problems only give you a bit of time, but will eventually fail.
Even worse is when they compromise the VPN operators and then monitor your usage until you do something that makes them decide to crack down on you.
People erroneously think of VPNs as privacy protectors. They aren't, not unless you have very good reason to trust whoever is running the server. If you don't, then they're concentrators for likely subversive traffic and its origins.
So you have two political parties pushing candidates at you.
The solution to this is to join a party and get involved in the decisionmaking. It's a lot easier than you might think, and you can have a lot more influence that you might expect, precisely because not that many people do this.
Thus enter my version.
Its very simple.
Entirely consistent.
Completely unrestrictive.
Easy to apply.
The âoeNo problem Bugroffâ license is as followsâ¦
The answer to any and every question relating to the copyright, patents, legal issues of Bugroff licensed software isâ¦.
Sure, No problem. Donâ(TM)t worry, be happy. Now bugger off.
This is one case where the sky daddy freaks could be useful to stop an extremely dangerously stupid move "forward." Because we live in this world, in this time, if this goes forward, it will 100% be used to extend the lives of the ultra-rich, while the rest of us remain fodder for their machinations.
Meh.
It would undoubtedly be very expensive at first, and therefore only available to the very wealth (probably not ultra-wealthy -- even without automation, caring for such a clone wouldn't be a full-time job, so call it maybe $30k/year -- within the reach of the upper middle class). But competition would drive automation, and we already have most of the techniques required, having developed them to deal with coma patients and the like, but at lower cost because this case would be dealing with a fundamentally healthy body. My guess based on some napkin math is that cost could be driven down as low as $10k per year. Maybe lower.
$10k per year is expensive, sure, but having an immunologically-perfect organ donor could absolutely be worth it for someone making as little as $200k per year.
If the cost could be driven down to $5k per year... then it's in the range where most middle-class Americans could afford it, even if it meant that they'd have to cut back a little somewhere else; maybe drive an older car rather than leasing a new one, or similar.
So, no, this cluster of patches doesn't tell us anything in particular beyond what we already knew: That emergency patches are relatively common.
Considering that Microsoft has been promising this exact same type of improvement since the release of XP Service Pack 3, the words spoken now are worthless platitudes provided to ensure the smoothness of the theft of your money. There is zero reality behind any of their promises.
I'm just talking about statistical patterns. I know little about Microsoft patches. I abandoned Windows in 2001, right around the time XP was released, and have never looked back.
The LLM and the compiler and the formatter will get the low-level details right.
Maybe in about 90% if you are lucky. That still leaves about 10% error rate which is way too much.
Not remotely similar to my experience. Granted I'm writing Rust, and the Rust compiler is *really* picky, so by the time the agent gets something that compiles it's a lot closer to correct than in other languages. Particularly if you know how to use the type system to enforce correctness.
Your job is to make sure the structure is correct and maintainable, and that the test suites cover all the bases,
Depends on the definition of "bases". Passing test suite does not show your program correct. And if your test suite is also AI generated then you are again at the problem whether the tests themselves are correct.
Yes, you have to know how to write tests. A few decades of experience helps a lot. I find I actually spend a lot more time focused on the details of APIs and data structures than the details of tests, though. Getting APIs or data structures wrong will cost you down the road.
Also, I suppose it helps a bit that my work is in cryptography (protocols, not algorithms). The great thing about crypto code is that if you get a single bit wrong, it doesn't work at all. If you screw up the business logic just a little bit, you get completely wrong answers. The terrible thing is that if you get a single bit wrong, it doesn't work at all and gives you no clue where your problem might be.
Of course that's just functional correctness. With cryptography, the really hard part is making sure that the implementation is actually secure. The AI can't help much with that. That requires lots of knowledge and lots of experience.
and then to scan the code for anomalies that make your antennas twitch,
Vibe error detection goes nicely with vibe programming. That being said, experienced programmers have a talent to detect errors. But detecting some errors here and there is far from full code review. Well, you can ask LLM to do it as well and many proposals it provides are good. Greg Kroah-Hartman estimates about 2/3 are good and the rest is marginally somewhat usable.
Deep experience is absolutely required. My antennas are quite good after 40 years.
then dig into those and start asking questions -- not of product managers and developers, usually, but of the LLM!
Nothing goes as nicely as discussing with LLM. The longer you are at it the more askew it goes.
You really have to know what questions to ask, and what answers not to accept. It also helps to know what kinds of errors the LLM makes. It never outright lies, but it will guess rather than look, so you have to know when and how to push it, and how to manage its context window. When stuff starts falling out of the context window the machine starts guessing, approximating, justifying. Sometimes this means you need to make it spawn a bunch of focused subagents each responsible for a small piece of the problem. There are a lot of techniques to learn to maximize the benefit and minimize the errors.
My point is that 25k LOC a month (god forbid a week) is a lot. It may look working on the outside but it is likely full of hopefully only small errors. Especially when you decide that you do not need to human-review all the LLM generated code. But if you consider e.g. lines of an XML file defining your UI (which you have drawn in some GUI designer) to be valid LOC then yeah. 25k is not a big deal. Not all LOCs are equal.
Yeah, I am definitely not doing UI work.
its during those sprints when I'm pumping out thousands of lines per day that I write the code that turns out to be the highest quality, requiring the fewest number of bugfixes later
yeah, all of us write (or copy/paste) great boilerplate code. that's not really something to be proud of.
we all make mistakes when writing business functions which are never 25k LOC in a week.
Speak for yourself. I wrote Android's Keymaster implementation in less than a month, and it was about that size, and then re-wrote most of it in a week when it turned out I'd made some core assumptions that Qualcomm couldn't match in their implementation. It was relatively bug-free for a decade -- even when a third-party security research lab spent a month scrutinizing it. They found a handful of things, but nothing serious. I was amazed, especially since I'd seen the reports they turned in on some other code.
That's just one example. In my nearly 40-year career I've had a half dozen crazy-productive weeks like that, and usually when working on particularly-complex bits. If you haven't had that experience, that's unfortunate. It's not something I could do frequently (or would want to), but it's a glorious feeling when you're that deep in the zone.
That surprised me, too. TypeScript is a very poorly-congealed ("designed" seems a bit strong) language.
Of the two popular scripting languages - python and ruby - python probably makes more sense as you can compile into actual binaries if you want.
For speed and parallel processing, which I'd assume they'd want, they'd be better off with Tcl or Erlang, both of which are much much better suited to this sort of work.
Then they should have used Tcl.
Evolution is a million line computer program falling into place by accident.
