I didn't know these fancy dashes existed until I read Knuth's first book on typesetting. So probably 1984. Since then I've used them whenever appropriate.
It's an externality because the entity that sold it to you doesn't have to pay the consequences of dealing with the trash. OP said "dispose of it properly," which could mean a lot of things, all of which are better than leaving it on a beach.
Trash disposal (to regulated landfills, not beaches) is enormously inexpensive and increasing the cost of every item through a laborious return program doesn't improve anything.
> Nearly all the plastic humans have made still exists.
And it just doesn't matter. It's a tiny amount of mass / volume.
> The great garbage patch in the Pacific is growing fast.
Ocean plastics are almost entirely a consequence of (particularly Indonesian) fishing net waste, not Western consumer products disposed of in managed landfills. The "great garbage patch" is also very much overstating the scale of the problem; it's a slightly higher plastic density region of ocean.
The main thing about plastic is that it’s made from oil, and oil already exists in the ground. Putting it back into the ground is basically neutral minus the pollution involved in manufacturing.
Geological strata vs shallow landfill sitting above aquifers and subject to near-term erosion.
Disposing of this stuff in deep mines seems like it'd be fine, unfortunately we haven't yet, at a society/economy level, found the discipline to do so. Presumably after a few mya of heat and pressure it'll be indistinguishable from other petrochemicals (which aren't particularly nice to begin with).
I don't think disposing of stuff deep in mines would be a good idea as it would be easy to contaminate the ground water. Modern landfills are generally well engineered and don't contaminate the surroundings too badly.
It doesn't go "back in the ground" though, does it? It gets scattered all over the ecology. When you take something that was buried deep and scatter it all over the surface - especially when that something is oil - that's usually considered an ecological disaster. Deepwater Horizon, the worst oil spill in history, has had catastrophic effects on the local wildlife, and it is still dwarfed in scale by the amount of plastic annually strewn to the four corners of the Earth.
7 billion kg at the density of water would fit in a cube 200 m on each side.
All the plastic ever produced could be stuffed back into one medium size coal mine. There are thousands of such mines and they are already ecologically disruptive.
It's a large amount when you think about the logistics to move it around the world, but a small amount compared to the total amount of stuff we take out of the earth.
I'm confused—how does putting in a master switch for those who want to opt-out entirely from the AI revolution occurring at the moment not matter? Are you saying that new features will fail to respect it?
Voters: please reconsider your ups and downs. I think the “Are you an expert” question triggered a lot of downvotes when it was in fact asked in good faith to judge the person’s perspective of easy and hard.
And I would say there is no way to ask that question in good faith. (Tedious proof by cases left as an exercise for readers.)
The correct question would have been, does anyone else agree with the statement.
In this particular case, the amount knowledge needed (of e.g. Lean language, math and Erdos problems) means any credible statement about the difficulty requires an expert.
It doesn't require an expert though. That was kind of my point. If you've taken an intro proof class (so the intro class for math majors/the topic), and if you've fiddled with Lean a bit (e.g. played some of the Natural Numbers Game another commenter linked), you'll know it's easy (source: I did math in my undergrad, and have fiddled with Lean a bit). Honestly I expect intro proof classes will start to be centered around something like Lean soonish if some aren't already incorporating it, and we'll see math majors more explicitly making the connection between program and proof.
Like if someone were incredulous that we could reasonably analyze running time and memory usage of something like merge sort and I said that's a standard example in an intro algorithms course, presumably people would be like "yeah it is".
I generally agree, but see some more nuance. I think feature-flagging is an overloaded term that can mean two things.
First, my philosophy is that long-lived feature branches are bad, and lead to pain and risk once complete and need to be merged.
Instead, prefer to work in small, incremental PRs that are quickly merged to main but dormant in production. This ensures the team is aware of the developing feature and cannot break your in-progress code (e.g. with a large refactor).
This usage of "feature flags" is simple enough that it's fine and maybe even preferable to build yourself. It could be as simple as env vars or a config file.
--
However, feature flagging may also refer to deploying two variants of completed code for A/B testing or just an incremental rollout. This requires the ability to expose different code paths to selected users and measure the impact.
This sort of tooling is more difficult to build. It's not impossible, but comparatively complex because it probably needs to be adjustable easily without releases (i.e. requires a persistence layer) and by non-engineers (i.e. requires an admin UI). This becomes a product, and unless it's core to your business, it's probably better to pick something off the shelf.
Something I learned later in my career is that measuring the impact is actually a separate responsibility. Product metrics should be reported on anyway, and this is merely adding the ability to tag requests or other units of work with the variants applied, and slice your reporting on it. It's probably better not to build this either, unless you have a niche requirement not served by the market.
--
These are clearly two use cases, but share the overloaded term "feature flag":
1. Maintaining unfinished code in `main` without exposing it to users, which is far superior than long-lived feature branches but requires the ability to toggle.
2. Choosing which completed features to show to users to guide your product development.
(2) is likely better served by something off the shelf. And although they're orthogonal use cases, sometimes the same tool can support both. But if you only need (1), I wouldn't invest in a complex tool that's designed to support (2)—which I think is where I agree with you :)
reply