It's a "stop shooting yourself in the foot" win-win.
Like, the last time I did a back-of-the-envelope, physical spam mail was also a surprisingly large (but still tiny) fraction of US CO2 emissions. We could just stop sending spam mail, and save like a quarter percent of the US CO2. Not big, but you're also not losing anything of value.
> Ending crypto mining is the easiest no-brainer in the history of energy systems.
Ending any profit-generating activity is incredibly difficult. I suspect you're not referring to ending it, but allowing it to be transferred offshore and losing the ability to regulate it. But if it's banned in the US, good luck getting every other country on earth to ban it in solidarity.
Considering how broadly unpopular the idea is to average people who don't aspire to own cryptocurrency (especially after FTX publicly ate its own organs) I don't see it being particularly difficult to find support for such laws in more liberal places such as the EU.
If you reduce it by 50% you save 50% waste. If you reduce it by 75% you save 75% waste. You dont' have to entirely wipe it out to save a lot of waste, just make it harder and/or more costly.
Attack the supply side, attack the demand side: tax it, regulate it, cap it, replace it. All of these can reduce the mining so they are all useful.
edit: to answer your idea that they will just move...
If these other places were as good or better for mining than where they are now, they'd already have moved. If you make them move to a worse mining situation, that's just proof that what you're doing is working.
I have had some good experiences with 3rd party recruiters. You obviously need to keep the fact that they will say whatever to get you to take the job they find. But equally they will push the company to hire you.
But isn't that how they get you? By lumping in some common sense good stuff with some dystopian crap. If they really wanted to fix the issue at abortion clinics they could have done that in a small quick bill.
It is a smaller scale version of the cameron government that cut everything to the bone, but they legalised gay marriage (though needed labour votes to actually get it done) so they aren't the bad guys, right? (obviously that was separate bills but I think the point works on a larger scale too)
Guessing here but I think the implication is that courts in the US are unable/unwilling to enforce workers rights even when laid out in a contract. In a post-union US there is not enough organised support for workers unless they are very rich.
Obviously employees all (maybe almost all) have employment contracts
Not everyone with vision or vision processing issues is blind. Being able to configure custom tab stops is an easy way to control what level of indentation is useful and clear.
Python has syntactic blocks as well, and editors totally can (and do) muck around with their formatting. I don't see any reason why they couldn't handle customizable indentation.
> The solution is to use tabs for indentation, and spaces for alignment.
It's the second step that drives me nuts. Why can't/doesn't alignment happen at first step? The inconsistencies of alignment using true tabs, in a monospace plain text environment, grosses me out and decrements my faith in the underlying systems. I appreciate editors w/ settings like `insert spaces when pressing tab` and `the number of spaces a tab is equal to`.
This is one of those things that started out as good advice, and then got turned in to an oversimplified parody of the original argument.
If you have something like:
var (
x = foo
other = bar
)
Then clearly you should use spaces to align those "="s, no matter if you use spaces or tabs for indentation. Similarly, "hanging indents" like:
coolFun(arg1,
arg2)
Can only be done correctly with spaces, and it doesn't really matter if you use tabs or spaces for indentation; this will still align correct no matter the tabstop size:
If you had used tabs, changing the tab size would make it align all wrong.
The problem is when you start doing stuff like:
if (one) {
------>if (two)
bar();
------>else
xxx();
}
And then, depending on the tabstop size, things can start looking very misaligned and confusing; this is why Python 3 forbids mixing tabs and spaces in the same function, because it's so easy to make something appear wrong and there are no braces to clarify things.
That's what people mean with "don't mix tabs and spaces", not "if you use tabs then the space shall never appear in the file under any condition".
To understand tabstops properly, you need to throw away the "They always expand to N spaces." idea. If you have access to a mechanical typewriter with tabstops, then go and look at how it works (with tabs being set by protruding pins on the carriage). Tabstops in terminals in the Unix and Linux worlds work this way.
> > If you had used tabs, changing the tab size would make it align all wrong.
> This is clearly false. You said this after giving a perfect example of how it's done with tabs.
I believe the post you're replying to meant "used more tabs". That is, if you used any tabs beyond the code indentation, they would get altered when you change the indentation size and ruin the alignment.
When I made my original comment I thought what I was replying to was an example of "tabs to indent and spaces to align" immediately followed by a statement that the only way to use tabs is to both indent and align.
The basic idea is that you use tabs to align "blocks" (ie, multiple lines at the same indent level), and then spaces from there to align line "elements")
Aligning lines in the same block
____var a; // indented with a tab
____var b; // indented with a tab
Aligning elements of a line with the previous line
____var a, // indented with a tab
____----b, // indented with a tab, then aligned using spaces
The idea being that tabs are used where it makes sense that you could change them for preference and not have things look wonky... and then spaces are used in situations where a specific number of characters is necessary.
Another alternative is elastic tabs, where tabs are used for both of those, but are converted to an indentation/alignment number of characters semantically. I like the idea, but I've yet to see a good implementation.
Personally I'm a fan of all spaces, but that's mostly because every company I've worked at has used that.
> The real problem is that using spaces for indentation is an accessibility issue.
The problem of leading spaces not changing their size can be solved through programming.
Those programmers who have such a problem and need leading space to be rubbery, if those programmers are worthy, will solve that problem instead of complaining that everyone should adapt to them.
The use of tabs is detrimental to code bases. Whenever tabs creep in, invariably people use different tab settings and make a dog's breakfast out of the code.
Code exhibits indented sub-structures that are internally indented, but not themselves not aligned to a tab stop, but aligned with something. One kind of example is something like:
function_name_of_random_length(lambda (a, b) {
if (a < b) {
indented();
}
},
arg2);
While that may be true, "spaces for alignment" is nigh unsupported by all editors I've seen. They insist on replacing 8 (or N) spaces with tab even if in an alignment region.
int foobar(int a,
___________int b) // should only ever have spaces (using _ here because HTML)
But good luck finding an editor that won't insert a tab when you use the tab key here (willing to be wrong).
The other issue I have is that diffs break alignment between undented code and anything with tabs because the tabs "eat" the leading space, but unindented lines are offset by one.
When I'm working in Git, Go, or Linux code, Vim (and NeoVim) uses `expandtab` in conjunction with `softtabstop` and converts any `tabstop` spaces into a tab (with `noexpandtab`) regardless of whether or not it is "alignment".
I've not done lots of development with other editors, but Kate didn't do it and the few times I used Visual Studio, it also had similar behaviors (I'm assuming VSCode inherited that stuff).
I used to tout "tabs for indentation, spaces for alignment" until I started working primarily woth lisps. Idiomatic lisp indention isn't compatible with regular tab-stops, so the only solution is to go with spaces (maybe losing accessability) or, preferably, to go elastic.
Indeed, it is always good to know the science but we should balance that against the benefits. I like this quote from David Spiegelhalter[0]
"Given the pleasure presumably associated with moderate drinking, claiming there is no 'safe' level does not seem an argument for abstention," he said.
"There is no safe level of driving, but the government does not recommend that people avoid driving.
"Come to think of it, there is no safe level of living, but nobody would recommend abstention."
I don't see it as a good quote and was puzzled as to its inclusion. It is simply a play on the words 'safe level' and equating it to other things. My best guess is that it's meant to appeal to the "I hear you but wish to continue drinking anyway" thought process, which is fair. This kind of equation is not.
Not necessarily. Driving for example is dangerous, a fatal crash can occur even if all parties involved are driving safely and are in complete control, and for that matter anything has a risk carried with it, but you balance out the risks and the rewards, just as you would with alcohol
