sirclueless

There is definitely some mental cost. By making lifetimes explicit there are additional barriers in the way of doing certain things that are safe but involve invariants that are too high-level for rust's semantics. For example, taking mutable references to multiple elements of a container simultaneously.

I think part of the point here is that you are not just answering OP's question, which may or may not be an example of an XY problem. You're also answering everyone who searches answers using similar terms to those the OP used.

For example, let's say the title of the question is, "How do I reformat my hard drive on linux?" and the body of the question is "I accidentally screwed up my upgrade of Ubuntu by <doing XYZ> and now it won't boot. Can I reformat the hard drive and install again so I can boot?" If your answer is "Are you sure you need to reformat? Have you tried <solution to XYZ>?" then you may be solving OP's root problem but you will be making a useless landing page for anyone searching "How do I reformat a hard drive on linux?"

I've used PHP and I too make fun of it. It's a silly language made years ago without a lot of attention paid to normal software development practices and it shows. There is a laundry list of facepalm-worthy things the language does.

But it's just a language. Good software is made in bad languages all the time. And making fun of PHP is not the same thing as making fun of someone who is using PHP. I'm sure Rasmus Lerdorf will happily tell you PHP is full of expedient design choices that would be different in hindsight, but that doesn't make it OK to poke fun at people trying to get work done.

That's a terrifying thought. For example the DeepFakes scandal was based on convincingly plastering celebrity's faces onto other video. If you had good data on someone's fingerprints I imagine it's inevitable that at some point you could do the same to put their fingerprints onto a photo of a hand.

This is not parallel construction, assuming their "other reasons" for suspecting these people are legitimate and disclosed. Parallel construction is when law enforcement receives information about a crime in an illegal way or a way that cannot be disclosed, and reconstructs a plausible way in which the crime might have been discovered.

This is just building enough evidence to convict someone based on matching a photograph of a partial finger to a suspect's hand. Which sounds perfectly reasonable and legitimate (as legitimate as fingerprints can be). Just because there's not enough in the photo to match a national database doesn't mean there's not enough to be statistically certain it's a match with the suspect.

I vaguely remember writing question marks over equality signs when one was using an equals sign as a proposition.

The point here is not to stop malicious recipients from saving the data. The point is to stop sensitive stuff from showing up in discovery in a lawsuit 3 years from now because a recipient didn't know to delete it.

The typical way to avoid this particular problem is only to load the content via JavaScript while copy/paste are presumed disabled.

Dealing with companies outside the EU is only covered while you are currently inside the EU, regardless of where you reside.

No. It only covers residents ("data subjects") who are inside the EU or dealing with companies in the EU. People who aren't in the EU (including EU citizens currently in foreign countries) and are dealing with companies outside the EU aren't covered.

Heart of Darkness/Apocalypse Now also has a pretty remarkable adaptation in video game format called Spec Ops: The Line. It's the same story premise cast as a modern military shooter. The gameplay is a fairly generic (some say this is an intentional statement on the drudgery of video game violence but I'm not so sure) but the story is excellent and there are lots of audible and visual details that show the gradual descent into madness of the main character and his teammates -- your voice lines go from professional callouts to angry emotional outbursts, "Hunt him down!", "Got the fucker!" etc.

Because pressing on words involves taking your finger off the keyboard, and the text is anyways often too small to be precise. You can fix it with the control bars on the sides, but it's more finicky and more interaction and requires you to move your hands.

It sounds like a bandaid to paper over a poorly-conceived program of incentives while they work out something more permanent. They were using their power plant as a loss-leader to attract industry. Which explains why the local factory is "more allowed;" it's presumably because they expect the factory to generate more jobs and tax revenue than the bitcoin miner.

In experimental physics it does.

Two recent planned breakthroughs: Einstein's theory of general relativity predicted the existence of gravitational waves, and LIGO detected them in 2016. Bell predicted that entangled quantum particles would exhibit fundamentally nonlocal properties, and in 2015 the first "loophole-free" test demonstrating violation of local realism occurred.

These experiments were done with expectations of a result. That is not to say that they had foregone conclusions, just that there was some phenomenon that the scientists hoped to see, and confirmation one way or the other would be of interest to the community. Most experiments are like this -- of course scientists should keep their eyes open for unexpected discoveries, but in general pursuing expected results is more fruitful.

I really like this mechanism. It seems like it should be the optimal way to store a set of size k.

Out of curiosity, do you know of an efficient way to calculate this without sorting first? Or even better, without knowing k ahead of time? If you can sort your input first it's trivial, but even though it seems like a super efficient way to store a set of numbers I don't know how to use it to solve, for example, the other problem in these comments of sorting 1M 32-bit integers in 2MB of RAM (you can store them with this mechanism in about 1.7MB of RAM, but only if they were already sorted).

How are you encoding the deltas exactly?

How is this relevant? A bitmap of size 2^32 is 512MB in size and you only have 2MB of memory.

You're sort of on the right track, but of course you have to encode those counts very carefully because 1M counts will exceed 2MB of memory unless you work hard.

Can you elaborate on the second part? Are you saying you're going to expand the size of the universe by a factor of 2^(k-1) to use as locations of the "bars"?

It sounds like you just haven't properly learned to account for the strategy of the game, or are not correctly tracking win conditions and using them to inform decisions.

If you just blithely play out a self-centered strategy and are somehow surprised when Charlie claims the Longest Road card and declares himself the winner, then sure it might feel disappointing to lose.

Instead try to be aware that for the last two turns Amanda has been 2 ore away from completing her last city and winning, but someone would need to roll exactly a 9 to do it on her own, while Bob has already completed all his cities but is unable to build more roads and Caroline is staying one Knight ahead of his army size through the help of Amanda giving her resources for the greater good. Maybe your win-con is going to have to be to steal Amanda's longest-road card and build another settlement which is gonna be a long shot but maybe given Amanda's desperation for ore and everyone-but-you's unwillingness to trade with Bob, you can do it. Maybe you can beat the odds and come from behind, maybe you can't, but either way an abrupt "it's over you lost" can never happen -- only someone executing their win-con better than you did, with the table unable to stop them.

You're living in a fantasy world. You're looking at the status quo: some guy has invented a better floating point circuit, and you think there are two options. 1) The guy releases it to the public for general use, or 2) the guy patents it and holds a monopoly over its use.

Obviously 1) is a greater public good than 2), but in reality these are not the only options.

Here's some other realistic situations: 3) With no incentives to make things public, this guy either stops working on this much earlier, doesn't tell anyone, or throws it in the garbage. 4) This guy goes and talks to Intel about his design. They quietly pay him some money or hire him and implement it in secret. Two years from now they launch a processor with this feature and for the indefinite future, until their competitors spend costly time reverse engineering the secret hardware, only Intel processors have this circuit. 5) Same as 4) except Intel says, "Haha, thanks for being a sucker" and doesn't pay anyone.

This is the patent system at its best: incentivizing some guy to work on this invention, then publish his work and describe it in detail. For the next 20 years, he can license it to anyone he wants and profit from his work. After that point everyone can implement it as a public good.

I don't think there's any particular reason to apply the label of "bug" to erroneous reasoning that cannot result in erroneous behavior.

If you can't in actuality cause a flaw in a program despite the presence of unsafe operations or faulty reasoning, then I would say that by definition there is no bug. Rather I might say that the code is brittle and perhaps unmaintainable, with risks for people who modify it later. Which is of course bad, but thinking pragmatically there's not much different between a latent pitfall like this and some poorly documented or gnarly spaghetti code that is equivalently difficult to maintain.

Fixing what the author calls "Level 1" and "Level 2" problems is sort of a mandatory imperative, as you can't realistically ship software with prominent issues at these levels. But shipping software with latent "Level 3" problems is something that happens every day, and it might be entirely correct to do the hacky and expedient thing rather than the "correct" thing at this level -- this is not a luxury you can afford at other levels, which makes this level fundamentally not a "bug".

That doesn't mean it's not worth thinking about erroneous reasoning. Erroneous reasoning is often the source of actual bugs that slip through a test suite. And if you're using loose reasoning and relying on assumptions holding true in the future, this is the sort of thing you should be documenting next to the code for the benefit of future maintainers. And indeed we should be working to write more maintainable, safer software, but not under the guise of a "bugfix" -- this is just good software engineering practice.

Thinking about "Level 3" problems is good. But be pragmatic. The reason you're doing it is because they make software difficult to reason about, and hence maintain. Investing time into fixing these problems helps future maintenance, but there are probably a lot of things you can do to improve software maintainability and you do need to actually ship the software at some point.

This doesn't really work as a blanket statement. Future proofing and trying to guarantee bug-free code is worth something -- for example if I'm building a space shuttle to go to the moon, I want some degree of certainty that software bugs will not cause that mission to fail, and I might be willing to spend a lot of time and money to ensure that doesn't happen.

I think a more accurate statement of this sentiment is that investing time and effort into preventing future bugs and problems stops being worth it after a certain point (and perhaps earlier than many software engineers would think).

I suppose it's a sort of shallow reference to keeping a child locked up in a tower away from the world. Not sure it's a great comparison since the woman raising Rapunzel disowns her when she discovers she's been sleeping with a prince, and blinds him. But they find each other by her voice, her tears heal his eyes, and he takes her back to his kingdom. So I guess the moral is if you keep your innocent child locked away from the world the only people who will make an effort to find them are gallant princes.

From an economic standpoint, this doesn't sound very uplifting. Any full time servant you hire is probably going to have less social mobility than you, and less education. And they are necessarily going to earn a fraction of your wages.

Employing someone full time to clean and maintain house isn't really uplifting anyone in a societal sense. Option 1: 30 families eschew automation and hire a full-time maid. Option 2: 30 families own a vacuum cleaner and a dishwasher and hire a cleaner once every other week for 3 hours to maintain their house. The latter is what happens in western communities and it results in 29 more productive workers looking for gainful employment in the workforce. If you don't see why that is an uplifting thing for society, you should take a good hard look at your understanding of economics.

As for your anecdote of the family member with cancer, house nurses are indeed common and affordable in western societies, we generally call this service "hospice." And while I may not employ a cook, there are 150 restaurants in my city that will deliver meals to my doorstep within 30 minutes.

I think a lot of people would disagree with you. There are obviously many methods besides proof-of-work to achieve consensus, but a blockchain cannot properly be called a "blockchain" unless there is some consensus protocol. Not every DAG of digital hashes is a blockchain.

Under your definition, every CBC mode stream cipher could be called a blockchain, which just makes the term meaningless. It was coined for a specific purpose: to describe how Bitcoin and related cryptocurrencies operate at a technical level, especially how they guarantee integrity and prevent double-spending.

Basically, when I load up your ship, I document all the stuff I am loading on to the ship in a Bill of Lading. You agree that all of that stuff is present and you're now responsible for it. At the other end of the shipping route you present the Bill of Lading and show that all the goods are present and intact.

If this document is digital, then I might get screwed if you lose stuff or stuff gets damaged and you remove it from the Bill of Lading and say you never saw the goods. Or you might get screwed if I add new stuff to the Bill of Lading after you load the goods and claim you didn't deliver it. So one way to solve this is to put the document and both of our signatures in a blockchain, and now we all agree that this is what we saw on that date.

They can guarantee that some data that indicates it was recorded yesterday was in fact recorded yesterday and not changed at any point since yesterday.

There's literally nothing a blockchain can do that a trusted central database couldn't do. So you only need a blockchain if you can't trust a central database. As a result, the answer to the question you've posed is always going to be a political one, not a technical one. ("It lets banks that don't trust each other keep a shared database of transactions." "It lets citizens who don't trust their various governments exchange currency." "It lets shipping companies that don't trust each other digitize their manifests." "It lets scientists prove their papers were published on a certain date.")

The common consensus for the term "blockchain" is not based on the 1991 paper, but on Bitcoin's use of similar technology to make a distributed ledger. The term itself is relatively recent, and was not used until well after Satoshi's paper. For example, Harvard Business Review describes it this way:

"At its most basic, blockchain is a vast, global distributed ledger or database running on millions of devices and open to anyone" [1]

That incorporates at least two concepts that are typically associated with the term "blockchain" that go beyond the basic cryptographic data structure: they are distributed, and they are open. Lots of technologies use a similar data structure; git uses a similar data structure. But when a silicon valley startup comes to you and pitches you on their "hot new blockchain tech" they probably don't mean git.

[1]: https://hbr.org/2016/05/the-impact-of-the-blockchain-goes-be...

Yes, only one block is the winner. It is whatever the maintainer of the git repository chooses as HEAD. This property is maintained by any number of out-of-band mechanisms such as Github pull requests and company-wide mandates never to "git push --force".

Seriously though, it just seems like a question of semantics. Is a blockchain just a specific sort of Merkle tree -- thus making Bitcoin a blockchain plus a distributed consensus protocol? Or does calling something a blockchain necessarily imply some consensus protocol already.