Kamq
Not sure if there's something for the apple equivalent.
This is, however, one of the reasons Germany is hit so hard by the current spike, I'll give you that.
When you're developing, there's a ton of degrees of freedom, and security encompasses only some of them. To be sure, if you set up a quickly verifiable test for every security flaw, you could probably get LLMs to satisfy them somehow, but there's a lot of those, and it's not necessarily practical.
As an example, let's say you have two functions A and B. A only works properly if B has never ran for some reason. Let's say they both accept a reference to a value C, and B changes C's value somehow. Because this is rust, we can't have data races, so we wrap it in an ArcMutex or what have you. That doesn't impact the ordering of A and B at all.
If we spawn threads that execute A and B at the same time, it's up to the scheduler if A functions properly.
That being said, that doesn't mean the majority of the situations you're in are completely novel, just that there's a reasonable chance of at least one occuring.
I think it probably is inevitable, but it probably happens the reverse of the direction that the quote implies.
That is to say, I think our definition of justice bends towards whoever wins historical conflicts.
Let's say that 95% of individual humans can pass it and only 2% of bots. For someone maintaining a website, who has to decide between using this system and shutting down their site because of the increased costs, that may very well be good enough
I mean, you're comparing a black card to the set as a whole? And you think that's fair?
Here are 3 of the top 6 black commanders:
https://cards.scryfall.io/display/front/d/6/d67be074-cdd4-41...
https://cards.scryfall.io/display/front/4/f/4f087b1c-97e0-43...
https://cards.scryfall.io/display/front/7/2/72e4548b-c171-4f...
The culture of magic (and nerd-dom in general) has definitely changed, I won't argue that. But when you use an example like this, it kinda undercuts your entire point.
That being said, the better coders I've seen aren't looking for a speed up, they're generally looking for something to bounce ideas off of, or to get a first draft going to defeat writer's block or something (I guess this is technically a speed up, but not the way people mean when they describe slinging tokens around). It's generally to wind up at a better solution at the end than to get a sustained speed up (which seems to only be possible in boilerplate heavy domains, but those were previously slowed down by the boilerplate and are really only coming up to speed with everything else, at significant cost).
That seems slightly weird, but that sounds like there's some large fixed costs that they can spread over the entire subscriber base, so the extra data centers are picking up some of those fixed costs.
I don't think that's average right now.
Entirely fair, but let's not pretend the situation is symmetrical. Canonical doesn't have monopoly on the linux or broader *nix world the same way that Microsoft has on the Windows world.
You'd have to prove that the CEO knew that it would hurt the company and still did it or that it's so ridiculously negligent that any sane person should have known.
And there are very few large public companies with active enough investors to oust a CEO over this, and even fewer that have both active and activist investors that would be interested in such a thing.
I agree. I just don't think code reviews are as load bearing as everyone seems to think. They're important, but not nearly enough.
Yes, and there's often a benefit to having a human have an understanding of the concrete details of the system when you're trying to solve problems.
> That has increasingly shifted to "just" reviewing code
It takes longer to read code than to write code if you're trying to get the same level of understanding. You're gaining time by building up an understanding deficit. That works for a while, but at some point you have to go burn the time to understand it.
This speaks like someone who has never been outside of a heavily bureaucratized regime. People don't get "approval" for things, they just do them.
Well, yeah. Those companies will pay to send their ad to all middle aged men. Those companies could slice and dice more to get better demographics, but they don't think it's worth it.
Google's business isn't to slice and dice the demographics to show you better ads. It's to slice and dice the demographics in any way that the advertisers will pay for.
Because the people who are willing to pay money are, ultimately, the customers.
It does occasionally, although I'll push back on the "often". Go's simplifications allow most of the codebase to be... well... simple.
This does come at the cost of some complexity on the edge cases. That's a trade off I'm perfectly willing to make. The weird parts being complex is something I'm willing to accept in exchange for the normal parts being simple, as opposed to constantly dealing with a higher amount of complexity to make the edge cases easier.
> There's no free lunch here
This I'll agree with as well. The lunch is not free, but it's very reasonably priced (like one of those hole in the wall restaurants that serves food way too good for what you pay for it).
> the compromises Go makes to achieve its outcomes have shown themselves to be error-prone in ways that were entirely predictable at design time.
I also agree here, although I see this as a benefit. The things that are error prone are clear enough that they can be seen at design time. There's no free lunch here either, something has to be error prone, and I like the trade offs that go has made on which parts are error prone. Adding significant complexity to reduce those error prone places has, in my experience, just increased the surface area of the error prone sections of other languages.
Could you make the case that some other spot in design space is a better trade-off? Absolutely, especially for a particular problem. But this spot seems to work really well for ~95% of things.
This thread is talking about the Senate. The senate isn't gerrymandered. Both senators are state-wide races.
If you want to view it that way, you can view the senate as "pre-gerrymandered". But the last time that was an option was in 1959, and both of those are just "the entire area the US owned, but wasn't a state yet. To get senate gerrymandering, you have to go back to 1912 and the admission of New Mexico/Arizona.
Have you looked at the state of the world recently?
You've obviously never worked food.
It is absolutely incredible from a technical perspective, but your next statement does not follow.
In a lot of (most?) fields, juniors are negative ROI, and their main value is that they will eventually be seniors. If AI isn't on the road to that, then the majority of the hype has been lies, and it's negative value for a lot of fields. That changes AI from a transformative technology to an email summarizer for a lot of people.
Based on the quality of candidates that get through at other companies, I'm guessing our problem isn't atypical. Or at least, good devs often aren't getting through their pipelines at all. It's possible that in trying to reduce the false positive rate, they screened out all of the actual positives, but that doesn't paint a good picture of the industry.
> How do you scale interviewing everyone if you don’t pre screen?
We do pre-screen. The fact that they haven't encountered a tricky algorithm before isn't a problem. For ones where the syntax is valid, a dev at my company does a code review on it.
This is the part I disagree with. It hasn't been true for years. Anyone with the free version of ChatGPT can pass a hacker rank today.
> but that doesn’t matter to the outcome of your company
It does for mine, because we've hired all of the good developers that get through the process you're describing and it isn't enough. We actively moved away from what you're describing and turned the interview into a 2-3 hour pair programming session where the person completes a mini version of a ticket.
This has much more predictive power than what you're describing.