nathan_long

> We don't really subsidize fossil fuels.

If we allowed a restaurant to dump its trash for free in a public playground, we would be subsidizing that restaurant with taxpayer dollars.

When we allow fossil fuels to be burned and dump pollution for free into the public atmosphere, we are subsidizing the usage of fossil fuel.

In the trash scenario, we'd make the restaurant pay for cleanup, pay medical costs for the kids who got ill, and pay for its future trash disposal. Burning fossil fuels causes asthma, climate change, flooding, etc, and remediation costs should be borne by those who cause the damage.

If you consider the billions of dollars we all spend dealing with fossil fuel companies' waste, it's quite a subsidy. The least we can do is make them compete on a level playing field.

> Carbon taxes are artificial barriers to using fossil fuels.

> On the other hand, when technology improves so that electric cars cost less per mile than gasoline cars, people won't necessarily buy them to be green, they'll buy them because they're a cheaper form of transportation that happens to be greener.

Carbon taxes are like trash disposal fees. If your business dumps trash into the landfill or carbon into the atmosphere, the public should not have to subsidize your business by paying for that. You should pay to manage your own waste.

Gas cars are cheaper than electric at least partly because we're all subsidizing them by allowing them to dump waste for free into the air that we all own, and paying on their behalf for all the damages that causes (asthma, climate change, flooding, etc). A carbon tax would remove that subsidy and make fossil fuels compete on a level playing field.

And yes, once the subsidy is removed, the market can sort it out.

What's the concurrency story in PHP - does it use 1 thread per incoming HTTP request?

Can anyone give context on these statements?

> When combined with their previous development of “water-in-salt electrolytes (WiSE)”, they claim that they can achieve an impressive energy density of 460 Wh/Kg.

> Some soldiers have to carry between 15-25 pounds of batteries and this technology could significantly lower that weight

What's the energy density of current batteries and how much lighter would equivalent batteries be using this technology?

> while preserving safety due to the aqueous nature of the electrolyte

What does this mean - why could the new battery be safer?

See also: ARPANET, forerunner of the internet.

> The Advanced Research Projects Agency Network (ARPANET) was an early packet-switching network and the first network to implement the TCP/IP protocol suite. Both technologies became the technical foundation of the Internet. The ARPANET was initially founded by the Advanced Research Projects Agency (ARPA) of the United States Department of Defense. > https://en.wikipedia.org/wiki/ARPANET

"Where Wizards Stay Up Late" by Katie Hafner is an entertaining chronicle of its creation.

This example of tracking is tiny and harmless. But there's a wide spectrum of tracking behavior from sites.

> whiny, entitled users who think they have a right to use any website they want on their terms

Users do have a right to use any website they want to on their own terms. If I make an HTTP GET to your site, it's up to you to decide what HTML to return. Once you do, it's up to me whether to request the images, scripts, etc, and whether to read the sidebar, etc.

It's up to you to decide whether to show me any content of substance without first collecting payment. I can't demand that you publish content for free. I'm not entitled to that.

But it's up to me to decide what I consume. You can't demand that I view ads, send back tracking cookies, etc. You're not entitled to that.

If you don't like site visitors refusing to be tracked, then don't let them view your website. Nobody forced you to.

> What about Romeo and Juliet? What about the Bible ( Jesus )? What about Socrates? Our cultural icons committed suicide.

Jesus didn't commit suicide; sacrificing yourself for others is quite different from deciding you don't want to live anymore.

As to your other two examples, what of them? Maybe reading Romeo and Juliet is an unhealthy thing for depressed people to do. Has anybody studied that? "[New thing] can't be bad because [old thing like it] exists" isn't an argument.

It's also possible that watching a movie that's entirely about suicide, with dramatic music and visuals, has more of an emotional effect than reading a play that includes suicide.

> So we do simply block everything anyone can say is bad for a small segment of the population?

I wouldn't say "let's use the law to censor this". But I wouldn't celebrate, promote, or support it, either.

> In general language diversity at a company is a big negative

I agree. It really increases the difficulty of understanding the whole system. But it's a negative that has to be considered alongside potential benefits.

> If you have some developer that wants to write something in a new (for your company) language, or even worse goes off and does so without asking, because he wants to try it out, you probably want to fire that guy.

I get what you're saying; resume-driven development can ruin your systems. But at some point between "we wrote this new banking system in COBOL" and "every developer who knows COBOL and could maintain our old system is now dead", there needs to be an accepted way to experiment.

The thesis itself is at http://erlang.org/download/armstrong_thesis_2003.pdf

But people are paying it.

I tweeted this about Joe:

> I wish I'd gotten to meet @joeerl. So bright and enthusiastic. Erlang embodies so many insights that seem obvious in hindsight. Eg, you can't prevent all programmer mistakes. You can't ensure computers never die or get disconnected. All you can do is make a system that copes.

> Many programming languages and tools exist to deal with the basic fact that humans make mistakes. Type checking, encapsulation, TDD, etc - all because without help, we will do dumb things. Erlang taps us on the shoulder and says "and ALSO your computer could melt. Start there."

> In Joe's words, "To guard against the failure of an entire computer, we need two computers." Obvious. Brilliant.

> The only place you can handle failure of a process on Machine A is in a process on Machine B, which can't share any memory with the first process and can only pass messages to/from it. And for consistency, Erlang handles all failures that way.

> Then you notice that these shared-nothing processes are easy to run concurrently because neither can mutate the other's state and cause race conditions. And that this scales beautifully when you have multiple CPUs.

> These are some of the insights I got from reading Joe's thesis. I'm sure I missed a lot of others and hope to re-read sometime. I wrote up some of what I learned at https://dockyard.com/blog/2018/07/18/all-for-reliability-ref...

As a Ruby dev turned Elixir dev: no. I mean, they both have `do..end` blocks, which I don't love in either language. But the similarities pretty much end there.

Here's the view of someone who went from Erlang to Elixir: https://www.theerlangelist.com/article/why_elixir

> I doubt we’ll start using Erlang though, it’s just too risky when you can’t hire anyone

Can you train them?

Friendlier tooling and documentation are a couple of reasons.

Elixir's whole reason for existence is to make the Erlang programming model easier to use. Try it and see if it does.

You can use Plug instead of Phoenix if you like, but why do you object to Phoenix? It's quite customizable.

Generate a new Phoenix app. Open up the endpoint file. Don't want routing? Comment it out. Don't want logging? Comment it out. Keep what you want, discard the rest.

I don't recall ever hearing that Facebook made a mistake which decreased the amount of data they collected or their usage thereof. Can anyone provide an example?

Presumably he enjoys running a powerful business built on privacy violation more than he thinks he'd enjoy philanthropy.

The BS you refer to is his creation, not some accidental thing that happened to occur in his company without his intention.

Planet Money did an episode (https://www.npr.org/sections/money/2018/06/27/623990036/epis...) about fake reviews and talked with the creator of ReviewMeta (https://reviewmeta.com/), which attempts to distinguish real reviews from fake ones based on things like similarity and clustered posting.

Of course, if it has or gets traction, fake reviewers will adapt, just like spammers do.

> IMHO, all the technology investment should be put into processing and validating ballots after they've been filled out

I think the opposite. When filling a ballot, the voter can use a machine with a touchscreen. The person with poor sight can use huge fonts, the blind can use a screen reader, etc. The output from this is a printed paper form, filled out with perfectly legibility. No hanging chads, ambiguous marks, etc.

At this point, the voter (or an assistant) can verify the form just as if a human had filled it out for them.

From there, these perfectly-filled forms can be counted the old-fashioned way with many witnesses.

That's true. Fiat money is a good example. But in this case, losers have incentive to claim the system doesn't work. You want the average person to be able to refute that claim, or else suspicion will run rampant.

That's great. But that sounds like failing to meet what could be an objective quality standard, enforced by something like CI. I don't think anyone objects to that kind of gate keeping.

The contention here (true or false) is that Apple tips the scales so that good apps lose to Apple's competing ones.

Poor reliability is a theme in IoT, self-driving cars, and here.

We are all accustomed to the fact that computers are flakey. Our computers and phones sometimes need rebooting to fix weird behavior. My printer just forgot how to connect to WiFi for no apparent reason. Everyone has stories like these.

What's tolerable for many popular products is not tolerable for others, though. Leaving aside whether having a gun actually protects you, people own guns for that reason. If your gun won't fire when your life is in danger, or if your car won't swerve when a truck is in the road, or if your thermostat won't turn on when it's bitterly cold, that's unacceptable.

Clearly there exists highly reliable technology: plane and spaceship controls, for example. My understanding is that an extreme focus and expenditure on reliability is required to achieve that.

I think that some of these consumer product categories where it's critical that the thing actually work will require the same kind of rigor before people can trust them.

> since electronic elections are not verifiable in any meaningful way

As I once saw someone point out here, the crucial thing is that they be verifiable by the average person.

Imagine a technically perfect electronic voting system, immune to tampering, preserving anonymity, etc. It's provably perfect - but only to the handful people who can understand the proof.

Average people could not have confidence in such a system, so it undermines democracy. (This may also be a barrier to using vote counting systems better but more complex than "first past the post" unless they can be explained clearly.)

"Put your paper ballot in that bin everyone can see and we'll all count them together at the end of the day" is a process that anyone can see is legitimate. So that's what we should do.

People may say alarming things while practicing their lines for a play, too. You can probably think of other plausible reasons. But Amazon workers can't know the context.

If Amazon workers hear something that sounds like a situation the cops should intervene in, they're in a tough situation. Not calling the cops could mean letting someone die. Calling the cops could embarrass someone or, somewhat less likely but possible, get someone killed because the situation unintentionally escalates.

Calling the cops definitely draws attention to the fact that Amazon was listening in the first place, which I would argue is a good thing and which Amazon would really like you to forget.

My feeling is that for the sake of the workers' humanity, they should be allowed to call the cops if they are concerned about the user's safety; otherwise you're asking them to ignore their conscience, which is dehumanizing and likely to haunt them.

And if users plan to say alarming things, they should turn off their AI microphones first. Having them know to do this brings healthy attention to the true nature of the devices.

> I believe ICE should be responsible for illegally attaining this information. They should also bear the cost of educating the Motel 6 workforce on their rights to resist requests from law enforcement agencies.

Totally agree. A hotel worker would be a hero for refusing to comply with an illegal request, but it's not reasonable to expect them to know what's legal or not here.

Citizens should be able to assume that those who enforce the law also obey the law, and when that's found not to be true, the agencies should be in deep trouble. Without law abiding law officers, the whole system falls apart.

I've wished for this myself. We replaced a refrigerator, and I thought "what a waste - 95% of the mass of that thing was non-moving parts that could've lasted centuries".

> There is still R&D to be done to update for modern manufacturing techniques, but an upstart that simply built old classic designs and added a 30-year warranty would do well. Bonus points for standardized dimensions (for easy replacement years from now).

Extra bonus points for publishing manuals and 3D printing plans for replacement parts and ensuring they remain available long term - eg, creating a web site and funding a foundation to keep it running + seeding torrents with the info.

Why would we go beyond step 2? As a taxpayer, I could buy the argument that the govt needs a new font, and that, having made one, it should make said font available for free so taxpayers can get the benefit.

I don't see why my taxes should fund a public CDN, though.

Everything is a tradeoff.

You say:

> sometimes you don't have a name ready and it's actually better to defer naming the thing until you know what it is

You can do that without this feature; you can use throwaway variable names like "x" and "y".

Taking an example from the post:

> (1..9).each_slice(3).map { |x, y, z| x + y + z }

vs

> (1..9).each_slice(3).map { @1 + @2 + @3 }

The shorthand saves you 7 characters in the rare case when you truly have no idea what to call your block parameters (even a single-character name can be descriptive, eg if x and y are coordinates). That seems minimally useful.

Meanwhile, you've made your block parameters look like instance variables, and everyone else (including all tools that work with Ruby code) has to learn why they aren't.

Seems like a poor tradeoff to me.

Verifying a user's email by collecting their password is ineffective for users with 2FA enabled and reckless/malicious for those (the majority) without it.

Accidentally log that data somewhere, and you've opened a way for attackers to take over your users bank accounts, social media, and pretty much every other online account, as they all rely on email verification.

If we had privacy laws with teeth, somebody at FB would be calculating how many millions in liability each piece of data collected represents. This one would be astronomical and an automatic "no" by those calculations.

Arguably, giving up your email login is worse than giving up your banking login, since attackers could use your email to reset the password on other accounts, possibly including bank accounts.

For banking, a better system would allow you to generate some kind of token in your banking site which would allow the kinds of permissions you want to grant to a third party, and which you could unilaterally revoke at any time.