cakoose

What? Something can be a distributed without being interoperable.

This article is humorously unbalanced. Sounds like someone venting. Even the counterpoint section is called "Perceived Advantages", haha.

Clearly, interoperability (or the lack thereof) can be taken to extremes; the hard part is finding the right balance. There's nothing in this article that helps with that.

There are two common uses for the word "impossible" that are relevant here. Solving the halting problem is impossible in the absolute sense. We have a proof.

But think about the (mind-blowing) discovery of asymmetric encryption. Before that, many things would have reasonably described using the word "impossible" in the sense of "nobody has any idea how to do that."

Do we have a proof that "golden key" thing is impossible in an absolute sense? If so, then it needs to be explained to non-technical people in a way that conveys that. If it's just that nobody knows how, then it's not actually impossible.

I think maybe people are interpreting the article as saying "if Google and Apple wanted to, they could do it this year" and of course that's incorrect. But I read it as them just lamenting that nobody even seems to be trying.

And I think their read on the lack of motivation is accurate. The people saying it's a bad idea from a technological perspective probably also think it's bad policy -- they wouldn't trust the government with a golden key even if it were possible.

So all the Washington Post can do is try and convince people that it's good policy. And it's fine to disagree with that, but it's unfair to call them stupid for thinking that there could possibly be a solution to the problem.

The new slicing syntax could have broken 3rd party pre-parsers or other tooling. Yet that change was considered backwards-compatible.

Based on what I'm reading, versioning is a serious pain point. Sure, you always have to make sure the payoff is worth the additional complexity (universally, not just in Go) but the author seems to categorically disqualify this option by incorrectly saying that it would break backwards compatibility.

Is Go's definition of "backwards compatible" different from the usual one?

Sure, the page gets the message across, but I think even non-technical people are at least subliminally aware of the fact that there's something low-quality going on.

If some smaller website did this it wouldn't be as surprising. It's just that this seems like an amateur mistake from a company that we all assumed to have competence in web design.

1. Sorry to everyone about the "his". Like most people guessed, I explicitly tried not to use gender, but I slipped up.

2. I didn't mean to imply you were bad at programming. The only goal of my comment was "if you're thinking about learning Haskell, don't be scared off by point-free style". I thought that providing more background would help people understand the temptation, but I should have divorced it more from your decision to use point-free style.

(What's funny is that these were things I was aware of and tried to handle well, but still managed to screw up.)

    inexactMatches xs ys = matches xs ys - exactMatches xs ys

    inexactMatches = pure2 (-) <**> matches <**> exactMatches

But over time I realized I was overusing point-free style. It was fun to write, but harder to read. If I were actually writing "inexactMatches" for something real, I would strongly prefer the first over the second. From what I've read, I think many people take a similar path when learning Haskell.

That said, I think everyone has a different threshold. For example, I've heard many people say that a for loop is more clear than something like "map" or "fold". I would disagree with that, but maybe that's just because I've gotten used to "map" and "fold".

So maybe the author's brain is just able to handle point-free style better than mine can, but I do think this particular example if far enough on the spectrum that most Haskell programmers would prefer the first version (for real code).

So if you're considering learning Haskell, don't be scared away. You will have to start getting used to point-free style, but probably not to this extreme.

But even so, I agree the wheels analogy is too extreme. I'd maybe say that it's like hearing that a car uses two motors instead of a differential -- "weird, I thought we solved that problem a while ago..."

Stupidity is one of the most commonly used disguises for malice.

For example, let's say you create a branch to work on a new bug fix. In that branch, you make the fix to the source code, and modify the bug status to "fixed". When you merge your branch back into trunk, both the code fix and bug status get merged atomically.

It definitely is possible to create a bug tracker that did these things but was still separate from the VCS. I remember seeing some early-stage bug trackers that stored all bug data as files in the repository (instead of in a separate database) and could be made to work with multiple VCS backends easily. However, since VCSes weren't designed for this, it was sort of of clunky to use.

Ideally, there would be some interface between VCS and bug tracker to make sure they're decoupled but still work well together, but nobody has figured out that interface yet. Until someone does, it's much simpler for Fossil to ignore the coupling issue for now and focus instead on making the best product they can.

If your new array is always a constant size bigger than the old one, then the total amount of work you do is O(n^2). If your new array is a constant factor bigger than the old one, the total amount of work you do is O(n).

This is ignoring memory allocator costs, which can change things a bit.

Request authentication in OAuth 2 is typically done by adding the HTTP header "Authorization: Bearer <access-token>" to every request. Pinboard does something similar but different. Sure, it would be nice if everyone used the same format, but it's so easy to stick a token in an HTTP request that I don't care if Pinboard uses its own format.

The app authorization flow is how a 3rd-party app gets an access token. (It's when the 3rd-party site redirects the user's browser to a Pinboard app approval page, where the they can click "allow", which tells Pinboard to give an access token to the 3rd-party site.)

Right now Pinboard just has you copy/paste a fixed token, which is fine, too. I think having an app authorization flow would make for a slightly better user experience.

The hardest part is designing an app authorization flow that is secure. Most of us are just not capable of doing that, so it's much safer to just use OAuth 2. As a side benefit, you can use existing OAuth 2 libraries, which will save you time on the server and on each client.

Yeah, the OAuth 2 spec is not written well. I had to jump back and forth a bunch trying to figure out exactly what the spec wanted me to do. But overall I think the benefits of using OAuth 2 for your app authorization flow outweight the annoyances.

I think the issue is more of a DRY thing, which could maybe be fixed with something like:

    type User struct {
        FirstName string  `form:lowercase_hyphenated`
        LastName  string  `form:lowercase_hyphenated`
    }

"Cap'n'Proto promises to reduce Protocol Buffers much like FlatBuffers does, though with a more complicated binary encoding and less flexibility (no optional fields to allow deprecating fields or serializing with missing fields for which defaults exist). It currently also isn't fully cross-platform portable (lack of VS support)."

[1] http://google.github.io/flatbuffers/md__benchmarks.html

I realize you probably have more context in your head but for everyone else the body of the post adds very little to the title.

For starters, the standard C++ string type is reference-counted, something that leans more toward convenience and simplicity than maximum performance. Well-designed C++ libraries that don't need to push the performance envelope are often pleasant to use.

Maybe the author wants things to be even simpler, but he's gotta provide examples. Or at least describe what his ideal Top C++ would consist of. That's the hard part. Simply saying "we should make a simple version of C++ that still lets you do low-level stuff when you want" seems vacuous.