SomeCallMeTim

The trick is that it's better to have the extra guard rails. And all of Couchbase, Yugabase, and Citus support foreign keys even with sharding and replication, so that's not an issue when the DB supports it.

Back to looking at Couchbase, Yugabase, or Citus for my distributed SQL.

That's not even close to "lying".

"Misrepresentation" can be a grey area that blends into framing and emphasizing certain parts over others. I didn't include misrepresentation on my list, and that was intentional. You can disagree with how an event is reported without the report containing any actual lies--and that falls under "a matter of opinion."

Things bouncing around "Dem Twitter," whatever that means, are hardly the fault of the NYT or ACLU. Whatever was said, it didn't enter my bubble, in that I never saw a claim that Rittenhouse shot any black people.

But I don't find Twitter useful, so I don't follow anything on it. Instead I read the NYT, and while I don't always agree with their editorials, I generally feel the information they publish as news is as accurate as they can figure out how to make it.

> It'd be like ordering the USPS to open letters and report people if they plotted their stupid Dollar Store peasant rebellion using paper letters, or tapping everybody's phones.

No, it really, really isn't like that.

It's more like shutting down stations from using the licensed public airwaves to disseminate incitement to violence or to broadcast blatant lies--and then later argue in court that "no reasonable person" should have believed those lies. I'm sure you know the latter actually happened, and the former was the law of the land until Reagan managed to tear down the Fairness Doctrine. [1] Which was found to be compatible with the First Amendment, and the only reason we don't have law to replace the original FCC rule is that Reagan vetoed it.

Regardless, my point is that there is potentially a way to limit speech that doesn't prevent people from complaining about the government but that also prohibits people from outright lying about the government (or other facts).

[1] https://www.reaganlibrary.gov/archives/topic-guide/fairness-...

The article talks about keys being published as part of the web page configuration.

That's far worse than "they could hack a server and gain its credentials!"

There is no excuse.

It is a well-solved problem to handle secrets; there are better and worse solutions. An environment variable for a server can get exposed if the server is hacked; a secret sent to a client is exposed the second the server goes live. One of these is much worse than the other.

There are also better solutions than environment variables. A competent team would be aware of many options. Whoever coded this is not competent, full stop. It's not that they didn't finish; these services should never have accessed from the client at all.

But it seems trivially obvious that, if Musk owned Twitter, that account and ones like it that target Musk will disappear.

As much as I like Tesla and respect SpaceX, I do note that Musk rarely misses an opportunity to benefit himself.

The whole crypto market manipulation event is one obvious example; what abstract ethical behavior was driving that debacle? I say there was none and that it was a transparent attempt to make money while trolling the crypto community.

Not that I actually fault him for doing that. It just points out how broken the entire cryptoverse is. But my point is that he is prone to doing things for his own benefit and/or without regard for the consequences.

What I haven't seen is evidence that he would take some kind of high moral position on free speech absolutism against his own self interest. To me it's more a question of "prove that he won't do it" than to prove he will.

If he ends up buying Twitter, we'll find out either way.

They're bad because they're lying to people en masse and inciting rebellion.

And yes, I absolutely think that behavior that reaches that bar should be squelched. The dangers of enabling the spread of misinformation are entirely too visible in today's society.

The slippery slope argument is garbage in this case. No one has been banning political speech from major platforms. Heck, they bent over backwards to allow Trump and company to say the most outrageous things for years before finally stepping in and putting a stop to it.

And Parler being deplatformed for enabling the public organization of rebellion against the United States hardly seems like an "oh no, we're becoming Nazis!" moment.

It's only the most extreme views that result in deplatforming; "your view on taxes is different than mine" will never rise to that level, so there's no slippery slope.

So in what case can we justify enabling platforms to lie to people and incite violence? It simply can't be done.

"Keeps people on task" seems like management-think adjacent to "butts in chairs in an office" requirements: There's a fear that someone might be "wasting" time by being distracted, when you seriously need to contemplate problems sometimes.

I'd need to see that "actual evidence" that we're allegedly discarding. Two programmers with two computers clearly could produce twice the productivity if they're both strong programmers. When I've been pairing with people I simply do all the work. I might get 1-2 comments per hour about a missing semicolon that I would have discovered the moment I tried to build. The claims of the pairing advocates are pretty hard to believe, and I don't see extraordinary evidence to back their extraordinary claims.

As I intimated above, the only way it would work is if the developers are junior (or mediocre) enough to be prone to contributing 0.5x or less productivity left to their own devices, so that the two developers' inadequacies at programming complement each others' and you get a 1.5x productivity out of them combined or something. And I do suspect that companies use that fact to hire less competent developers and make them at least reasonably productive; Pivotal does 100% pairing, and sells it hard, but note that they're paid per developer hour and so actual productivity per-developer isn't what they're necessarily what they wanted to optimize.

As to your Edit: The exact thing I'm objecting to is 100% pairing, which is practiced at some companies like Pivotal. Or worse, 100% mobbing, which is more than two people at one screen.

It's the 100% pairing, or worse, 100% mob programming (up to six people with one screen!) that I can't believe would ever be more efficient than the programmers working independently.

Sure, have a party and mob-program for fun for an afternoon, or solve a particularly sticky problem that way, or use it to transfer knowledge about the system to the wider team. Have a blast, and teach everyone something useful at the same time. By all means.

Just don't pretend (as pairing/mobbing advocates do; not you) that two people sitting at a computer can be as efficient at day-to-day coding as two people coding separately, unless at least one of the two is a junior or near-incompetent developer who would contribute negative productivity on their own.

I absolutely can pair for such an event. I'll pair for knowledge transfer. I'll pair for fun. If every second counts, or if the goal isn't maximum productivity throughput, the sure, pair away.

My point is not that it can't help for world-class developers, but rather that two world-class developers working on routine coding are absolutely not more efficient than two world-class developers working separately.

And people who advocate for pairing typically advocate for 100% pairing. Which can be fun but it won't be more than 2x as productive as two world-class developers working independently.

I don't ever let them leave my pocket, of course, so I'd need to forget my pants to forget my keys...but we did agree not to get started on personality disorders. ;)

99% of the app dev happens on Android, and I just test on iOS when I need to--and for that I have an older, cheap, MacMini.

I haven't lost a laptop screen to dropping it, though I have had a laptop screen spontaneously fail--two in fact. Both were HP laptops. Not buying those any more.

So yes, you're correct.

Lets say, hypothetically, that you can use it to ramp any programmer up to being an expert on the system. Maybe that takes two months? Or even six months? Once you have a team full of experts, you're now spending two programmer hours to do every bit of work that could have been done in one programmer hour by a single expert.

Unless you have such incredibly high turnover that the period to transform a developer into an expert is close to or less than the average tenure of an employee, in which case your team has other issues that likely need to be addressed, because why are people jumping ship so quickly if it's such a great place to work? (For example: If it takes six months to produce an expert, you'd need to have an average tenure of less than or equal to six months to really benefit from pairing; anything more and the 50% performance penalty has to eat into your overall productivity.)

On top of that, I have never been at a job where it's taken me more than a week to get up to speed on a system, or at least to the point where I can simply ask the occasional question of the experts on a team to get me unstuck. Even if the average developer took a month or two, pairing beyond that point is simply fun and not more productive than two programmers developing independently.

Unless one of the developers is otherwise likely to produce negative productivity on their own, I suppose. I've worked with that kind of developer as well, and the right answer is to eject them from your team, not pay other developers to babysit them.

And code bloat, as I've said elsewhere, is vastly overblown as a problem. Another commenter pointed out that link-time optimization removes most of the bloat. The rest is customized code that's optimized per-instantiation.

Slow compiles are an issue with C++ templates. They're literally a Turing-complete code-generation language of their own, and they can perform complex calculations at compile time, so yes, they tend to make compiles take longer when you're using them extensively. But the point I was making was about runtime performance. That's why C++ compilers often perform incremental compilation, which can limit the development time cost.

Debug builds can simply be slow in C++ with or without templates. C++ templates really don't affect debug build runtime performance in any material fashion; writing the code out customized for each given type should have identical performance to the template-generated version of the code, unless there's some obscure corner case I'm not considering.

I've used C++ templates effectively as a code generator to layer multiple levels of abstractions into completely customized code throughout the abstraction.

Inlining happens with or without template classes.

It can in the naive implementation. Early C++ was famous for code bloat and (apparently) hasn't shaken that outdated impression.

In practice, monomorphization of templates hasn't been a serious issue in C++ for a long time. The compiler and linker technologies have advanced significantly.

So no, generics do not de facto make code slower.

There is a reason that most companies make it hard to talk to a human before you've already exhausted all other support channels.

Make something like that a right and people will use it. Maybe 99% of the time you won't need a human for a particular service in a month, but there will be users who are on the phone every day, maybe multiple times per day.

And your monthly fee would need to exist to pay for the users who abuse the right.

I think you underestimate how many services you rely on that wouldn't be able to survive with a legal requirement that they were required to take calls from any human that wanted to contact them. Presumably those services are useful to you and you wouldn't want them to be closed down, yes? And similarly, you wouldn't want to be paying the $50-100/month for each service that would likely be required if every single one had to support a fully-staffed call center to deal with not only customers but potentially affected non-customers (as in the Giphy example in the parallel comment thread).

It may need (I don't know if they have this already, and I don't care to do the research) a "Report" button with various options including "Hate speech" and "Takedown Request: Moral Rights" and similar.

Think about it: A political image that's offensive to one side or another could generate hundreds of thousands of protest calls, if everyone had the right to speak to a human. I mean, if you knew you had this right, and you wanted them to take down an image, then of course you're going to demand the right to talk to someone. To say that you don't like the image.

Which they could just as easily handle with a Report button and a single review of the image by a human to check to see that it satisfies the ToS.

And that's just one image. Every one that goes viral could result in hundreds of thousands of calls.

No, it really just doesn't scale. If you give people the means to call you, you need to be able to handle way more people calling than you have customers, and some companies that provide a valuable service simply don't have the margin.

Now if someone successfully publishes a hack that steals everyone's data and/or creates a botnet everywhere it's installed, there's no way to actually pull it down and override it.

Unless there's a centralized authority with the ability to do that, in which case it's not decentralized and we're just changing who controls it.

>In day to day development our decentralization increases reliability (leftpad is a sore memory)

...leftpad became a problem when a commonly-used deep dependency was ripped out of the ecosystem. And because npm is centralized, they can now prohibit anyone from causing that kind of damage again, ever.

Whereas in a decentralized system where people are pointing at random GitHub accounts? Yeah, they could totally delete the GitHub account (or force-push an empty repo) and cause the same exact problem as leftpad.

They are claiming to solve a problem using decentralization that was caused by too much decentralization. And then using Deno as an example install...which has the exact same problem in its ecosystem.

Fail piled on to more fail.

> Q. What are the penalties for violating the CAN-SPAM Act?

> A. Each separate email in violation of the law is subject to penalties of up to $46,517, and more than one person may be held responsible for violations. For example, both the company whose product is promoted in the message and the company that originated the message may be legally responsible.

https://www.ftc.gov/business-guidance/resources/can-spam-act...

That's ... not a trivial amount of money.

Wait for them to send you a dozen spam, and it's even more substantial.

And just because you don't understand it doesn't mean that it isn't some peoples' life experience.

Reference: I know a child who is not at all rebellious or attention-seeking but who expresses this as their inner experience.

Dismissing that experience is rude.