devnullbrain

The US will be slower than most places due to the federation and ideological individualism.

It gives you readability. It's not what I'm used to, so it feels like reading French to me. Generally, if I see something without a namespace, it has a local scope.

I'll remember to prioritise 0000 to 2767 for your PINs, then.

Yep. I don't have much experience doing it with my macbook but on Windows it's source of rage. 2 options:

- physically block the hot plug detect pin on all of your display cables. Now you can turn off your monitor!

- PersistentWindows (slow to put everything back, jumps around virtual desktops)

Bonus points for everything related to 'windows' and 'virtual desktops' being un-googleable terms.

There are people who know more Chinese glyphs than just the numbers, implying it is possible to learn 60 glyphs.

Wrong way around.

Less than 1% of what Chinese has

Both are the same in their own base. 9+1 isn't inherently easier in arbitrary bases - do you know what 10000 is in hexadecimal without working it out?

Fewer thank you'd think. It turns out the poisonous ones are bad for PR.

>Construction work is required to retarget beam.

If you mount two of them like a gyroscope, inside a spherical opening, the planes could overlap into a target-able beam.

>that occasionally delivers mail

Roughly once every two weeks, here.

It's a strange warping of preservation that means you'd rather the book be inaccessible but complete than accessible but complete in content.

That's not actually the reasoning given in TFA.

As a Marine, you are probably aware Marines assisted the toppling of the famous Saddam Hussein statue?

SMS verification seems to be broken. Nothing reported on the status page.

https://status.anthropic.com/

It's not frowned upon, it's the normal way of doing anything non-trivial in Windows land. You don't get something from a repo, you go to the Foobinator Tools website to download BarApp Pro

It depends if skipping means questions not answered or if it means questions skipped to answer later questions. But either way it's more like playing gameshow host than making a meaningful exam.

It's practically impossible to defeat cheating on a technical front with their current design. Anti-cheating methods strike me as depending on emotions: I can probably find a way to cheat successfully but, if my future depends on it, my fear will make my body language stick out like a sore thumb. I also wouldn't do it to begin with since it's unlikely to have a better EV than putting the same effort into studying, especially if I actually need the knowledge in the future, or if there are social repercussions. Some won't have this hurdle but the combination of 'needing to cheat' and 'being skilled enough to get away with it' is rare.

The big problem is when cheating is so easy and widespread that everyone knows it. Then it becomes the low friction path. This would explain what I've heard about some Indian school exams.

There are probably a lot of people doing minor cheating and a few people doing major cheating. In most cases, it's not enough to undermine the reputation of the qualification.

Oh, it's the same shape as the fraud problem that's popular here:

https://www.bitsaboutmoney.com/archive/optimal-amount-of-fra...

It's not a simple wrong answer. It's a poorly designed system that causes a pattern of wrong answers, on this question and others. For comparison, consider the consensus on this site when that system is Google search giving wrong results.

Oops, shared_ptr circular reference.

Oops, null smart pointer.

Oops, UB made my reference null.

Oops, invalidated iterator.

Oops, aliased pointers.

Oops, race condition.

Oops, recursion.

Oops, moved-from object is partially formed.

You need to use a less general term than 'emulation' to make that claim.

Your OS emulates. The companies that made the chips you run them on emulate their own hardware. The company in the headline emulate their own video game hardware and sell it to their customers.

It's also just something that all engineers do. EEs don't concern themselves about the power-draw of an LED on a space heater. MEs don't work hard to make a piston last 100 years in an engine that will last 10. It boils down to 'focus on important things, not unimportant things'.

>Write the simplest code first - get it right, if too slow or uses too much resource then set a measurable goal what a good speed or resource needs to be and then optimise until you reach that goal.

So you write the code with algorithm X. You potentially might not know the complexity, depending on how extreme you are with this philosophy, but let's say it's O(n^2). You run it on your test data. It's too slow because of some unneeded deep copies. You change that. Now it's fast enough. It gets merged.

3 years later, you're experiencing integration test failures, because scaling up your system has caused this algorithm to make things time out. No problem: you'll simply look into it and optimise it. Except you can't. Thanks to leaky abstractions, threading-models, or just an inherent quality of the code, changing this algorithm to something with a lower complexity becomes a major refactor. Pray you don't have external APIs or stakeholders depending on it.

So, not only have you wasted the time polishing the O(n^2) algorithm, you also now have a huge technical debt from what can simply be described as inadequate forethought.

The 'simple code now, polish later' process - which is really just 'move fast and break things' in a different shade of paint - means you never learn to internalise the easy wins. It also paradoxically portrays optimisation as both too complex to do initially but trivial to do later. It's not the latter. Having a good gut-feeling of algorithms or the Kafkaesque way memory works is not something that is learned over the course of a JIRA ticket - it's learned over the course of years, treated as any other code-quality concern. For comparison, you could close many tickets quickly by using a global variable to pass data around. But you don't. You make sensible, idiomatic changes to make sure things are stored and accessible where makes sense. Optimisation is the same: there is a lower bound below which it's unacceptable, even if it's not something that fails requirements.

StructuredProgrammingWithGoToStatements was written in 1974. It doesn't track well to modern computing models. I have more L1 cache than he had main memory. I do accept that the vast majority of bugs were from this, 50 years ago. I don't accept that's still true today. It's still a useful thing to teach new learners so they learn how to prioritise their development but as professionals creating novel things we need to have a certain level of planning ahead. And pride.

It's also a tautology. If the optimisation is worthwhile, it's not premature. If the optimisation is noncritical, it's premature.

My example above is not fanciful, by the way. Off the top of my head, Windows, Python and C++ all had/have trouble with some performance loss due to the fallout from earlier decisions and difficulty rectifying it once the world is built on top of it. I've run into similar problems at my own jobs, particularly anywhere that uses microservices. You can't avoid all of these but you should avoid those you can.

Empirically, companies are very bad at evaluating this cost. If they weren't, upwardly-mobile job hoppers wouldn't exist because the previous company where they generate positive value would have increased their salary over the salary they could get elsewhere. In practice we see that the companies are reluctant to give raises, hiring costs are considered capex, and there are inefficiencies in salaries because frictions cause employees to stay in roles that are not financially optimal, meaning there's a premium to accepting the risk of moving jobs.

There's an odd phenomenon where people become hiring managers and begin to think they're the sole authority on what other hiring managers care about, despite all evidence showing that it's an inconsistent, inexact science. Hard truth: if you're not a job-hopper, you have less varied experience of what it takes to get hired than those who are.

And all we have to show for it is a 1600% increase in GDP.

>when AVX is used

spoiler: it isn't

Rough, try getting directions to your hotel and nobody can tell you.

And it's a good law elsewhere? :)

You're also welcome not to buy a phone for your parents. It would be disingenuous for me to suggest you actually do so, because we all make choices under duress or with limited options.

Not only do I think it's relevant, I think it's the whole point. The security argument is the outcome of finding the most useful, contentious point that would support them continuing to make the gobs of money. It's the same way 'think of the children' is used for arguing in favour of various types of censorship - everyone in the know is aware it's not the real reason but we live in a society where calling someone out for BSing is considered rude, or bad politics. So the rest of us have to nod along while being treated as fools.

The TAM is saturated. Taking share from Android is difficult. Making more humans use smartphones is difficult. Making more humans is difficult. Extracting more rent is not. So the idea that the security is more important for future revenues than the ability to exploit the userbase doesn't hold up, particularly when there isn't and can't be an alternative with a different security model.