sirclueless

XOR is not, by itself, a problem. Heck, the most secure encryption method on the entire planet, the one time pad[1], is just an XOR of some secret bytes with a plaintext. XOR is also one of two fundamental building blocks of the current state-of-the-art AES-256 encryption algorithm[2] (the other being a series of bit shifts).

The problem here is deriving something so simple from the key, and only applying it to the first 128 bytes. This is unforgivably dumb, when there are perfectly serviceable encryption services available as part of open source libraries, such as the aforementioned AES-256 algorithm.

[1]: http://en.wikipedia.org/wiki/One-time_pad [2]: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Th...

In general I am inclined to agree with you. Given two equivalent libraries, if one is standard and one is pulled from github, the standard library should be preferred. If it were just a matter of developer ergonomics, I would agree with you in this case too.

But the command line interface is the fundamental user-facing piece of a command-line program. If it's not intuitive and clean, the usability of the whole program suffers. The internal API is secondary (this is why I didn't try to "improve" anything here -- go's flag package is good enough and I'm not trying to reinvent the wheel). It's all about a good experience for users, and I don't think Go's stdlib flag package provides that.

Commandline programs written in Go shouldn't feel like idiomatic Go programs, they should feel like idiomatic commandline programs.

The go flag package has a nice API, but the user interface it creates is straight from its Rob Pike's Plan9 roots, and Linux users familiar with getopt command line interfaces will find it strange and perhaps even ugly.

I wanted to create command line programs that look like traditional GNU/Unix utilities, so I wrote the https://github.com/ogier/pflag package. It's a drop-in replacement for the flag package, just change the import line. It also adds some basic features, such as the common pattern of a flag with a long-hand form usable with a double --dash and a shorthand character with a single -d.

That's not actually true in this case. The author is correct about this.

When "int i = 10;" is encountered, the tentative definition behaves effectively as a declaration. If the compiler were to reach the end of the translation unit and the variable i was never defined elsewhere, however, "int i;" serves as a definition.

And this is precisely why I left SO. Without fail, the most interesting and useful questions for me on the site were more or less surveys of the population -- "What's a good library for reading XML in C#?", "XYZ looks like it was abandoned, is there a good replacement?", "Why is Python 3's virtualenv different" and that kind of thing.

Maybe that's just me, because if there ever is a question with one correct technical answer, it's easy to figure out on your own. The things I want to interact with a human to figure out are universally to do with historical reasons for things, ergonomic choices, and opinions on quality. I want a smart person with strong opinions, not a politically correct karma grinder who can type quickly.

Talking of other CS "bugs" that have turned into features, anyone who's never seen "surfing" should check that out.

Basically, you take the same air-strafing principles from this article, add a little bunny-hopping, and another "feature" of counterstrike where if you land on a steep enough slope you won't take falling damage or apply friction. Give this to some insane map makers and the end result is an incredibly skill-intensive obstacle course of sorts at tremendously high speeds.

Here's a good example of what I'm talking about: https://www.youtube.com/watch?v=o0Xv00yJhjs

There's a really dedicated community behind this stuff, you can find 64-man servers full of people playing this type of map in CS:GO and CS:Source.

No one doubts that Go is production ready at this point. But the performance requirements of a systems programming language are just very different from the requirements for a web server or applications language.

From my point of view, and the industry I'm in, the latency requirements of a web server stack look completely laughable. That's not to say there aren't challenges in a web stack, because many web servers have to handle orders of magnitude more I/O than we do, and efficient load balancing over a distributed system is extremely difficult and I am fortunate to rarely have to think about that kind of thing. But a requirement like "99% of requests need to have a response time of 200ms or lower" looks like fiddlesticks compared to a requirement like "a round-trip-time of more than 100us will be a large problem and get noticed".

My point is that Google's, CloudFlare's, and Dropbox's "performance-critical backends" don't require the same things as some other workloads. As a more mundane example, the latency requirements of Google's search engine are probably less stringent than the latency requirements of your text editor.

None of this should be taken to mean Go is slow or can't handle 99% of the world's performance requirements. But you can't just say "Go is high performance and fits in all of these company's critical paths. Try harder and it will work." Sometimes it might just not be cut out for it.

There's actually a constraint that no blue circle can be alone, which you can find by reaching an end board with a solitary blue that the game will prompt you about. So X red and Y blue would be well-determined.

However there does appear to be another constraint that is not mentioned explicitly, which is that there are no blue circles that are not in line-of-sight with a numbered circle.

I think the author is trying to say that there is a concept of knowledge that is inherent to words "perfect forgery". That either someone knows the origin of an object and therefore it is not a perfect forgery, or all such knowledge has been erased and now there is no way to say that an object is not authentic.

I think this is something of a straw man argument. There is an entirely satisfactory functional definition for "perfect forgery" which is that an object is a perfect forgery if it cannot be distinguished from an authentic object by someone with no prior knowledge of the object's origin. This is what I believe common intuition would determine the word "forgery" to mean. An object does not fail to be a perfect forgery because its creator knows it is not real. It is a perfect forgery if it can fool everyone else into believing it is real.

Making zero knowledge of authenticity a prerequisite for a "perfect forgery" is to neglect that there are multiple independent minds in the world with their own viewpoints. I can know "that is a perfect forgery" if I know it will fool anyone without my private knowledge. Such knowledge is not incompatible with the object being a perfect forgery, because the most sensible definition of "perfect forgery" is that it would fool anyone else, not that it has already fooled everyone including me.

Not having access to a PDP-11 (maybe this works on an emulator?) is it cheating to ask what the output of this program is?

'mut' conveys the same thing you are trying to convey with 'var' in a much better way. The term "variable" in programming languages doesn't carry any connotations of mutability or immutability. All it traditionally means is "named value" or "named memory address".

It's actually entirely reasonable to have an "immutable variable" -- Rust uses this phrase in its error messages and it's perfectly sensible. For example, consider this snippet:

    pub fn is_even(x: int) -> bool {
        let y = (x / 2) * 2 - x;
        if (y == 0) {
            return true;
        } else {
            return false;
        }
    }

Not very idiomatic, forgive me, but would you say that y "varies"? I would say yes, it varies for each invocation of is_even(). If y didn't vary, "if (y == 0)" would be a nonsense statement. y is certainly immutable -- you can't go assigning new values to it -- but it's definitely a variable.

The opposite of "variable" is "a constant," not immutable. 'mut' means "mutable" and "mutable vs. immutable" is the choice here. Rust got this right, I think.

I assume this only applies to internet tech companies that should know better. If the non-technical guy outsourcing a company's IT got upsold on whois privacy, I'm not about to hold it against them.

There is a vital need for you to own a potato though. Humans need to eat plant food for sustenance, so we have moral reason to accept that at least some plants are allowed to be owned. Given that, there is nothing significant to recommend an alternative plant over a potato, so there should be no moral objection to owning a potato.

The point of framing the argument in the terms that konstruktor has, is to change the debate from, "Are apes sufficiently like humans to justify giving them rights?" to "Are apes sufficiently different from non-sentient entities to justify treating them differently." And I think this is a much more persuasive argument -- I think humanity is less willing accept freely that apes are equivalent to humans on some level, than they are to say that the act of viewing an ape for enjoyment does not justify locking up something that is clearly more intelligent and self-aware than your average apricot.

It's actually extremely likely. The chance that any two statuses are anagrams is miniscule, and even the chance that a particular status has an anagram among all other statuses is probably small, but the chances that there are no collisions at all is tiny.

See a description of the Birthday Paradox[1] for the mathematics behind this. For example, if you put 70 people in a room, there is a 99.9% chance that two people share a Birthday.

[1]: http://en.wikipedia.org/wiki/Birthday_problem

I think the parent comment is assuming ADT is short for "algebraic data types" and not "abstract data types", since the former is the subject of the rest of the thread. You used both long forms and the acronym without saying which you meant.

As to the meat of the discussion, algebraic data types imply that you can apply algebraic operators to types. Since this is traditionally a purely compile-time feature you can imagine why the parent comment is incredulous that you could implement this without language support.

Your specific statement, "data types and types are not the same thing," is particularly confusing. You are making assumptions that aren't warranted, for example that "data types" encompass both a compile-time type check and an interface allowing abstract operations, while "types" are simply static type guarantees on values. In fact, both terms can refer to either.

The point is that if Netflix throttles Comcast customers, the customers stream from Comcast On-Demand instead. They don't switch away from Comcast because they can't, which is what makes this an unbalanced situation.

I don't think it's meant to. The instructions are a bit ambiguous, but they mean just the pickles that are siblings to the bento, which you can see because only those are bouncing.

It's simpler than that. You are supposed to select the plate and bento, not the pickles on the plate and bento.

That may be true for familiar words, but a long, uncommon word is unavoidably going to take more processing. Flashing "unforgettable" is probably fine, but I'd want a split second pause on "periodontia" or "imbroglie".

> I mean could you ever imagine a fashion line modelling male PhD students?

Yes, I very well could imagine this. Geek chic is very much a thing and this would probably play just fine.

I think about this the opposite way from you: Why should having a PhD change the pressures one faces around fashionability and body image? Are you suggesting that people with PhDs have earned the right to be exempt from social pressure by virtue of succeeding in a graduate program?

Choosing some arbitrary and largely fashion-orthogonal dimension to slice up the population seems like a very reasonable way to try and advertise fashion to a wider audience. If you are decrying that the media is pigeonholing women as being more fashion-sensitive, or that they are cherry-picking some expected body type out of their chosen demographic, then that is a separate and perhaps valid issue. But I don't read this as having any bearing on the value of a PhD, except as a way to market to an audience that cares about intelligence.

It is documented. That's the strongest argument against changing it: it's a documented piece of user-facing behavior. The python developers are changing it anyways because they're practical people who have decided it is more likely that people wrote bugs into their code, than that they wrote code that depended correctly on the falsiness of UTC midnight.

It sounds like a very purposeful and directed "fuck you" to me. He's not being rude or crass, he's making the concise and vehement point that if you are a bad actor on Tor, you are harming everyone and he will hate you for it.

Enlightening debates don't come about when everyone mutes their politically incorrect emotions and speaks in platitudes, they come about when people respect each other and can speak simple truths as they would to their peers. Evidence is always useful, but rational argument is equally important.

Doesn't this have the same problems as the DELETE+INSERT from OP? Namely, a concurrently executing transaction will see a brief moment in time where no valid (e.g. CreatedOn < NOW() < InvalidatedOn) UserProfile exists.

There's also a bunch of weird corner cases you need to expect. For example, you can have multiple valid UserProfile objects at once if two transactions insert concurrently. If you LIMIT 1 and sort by CreatedOn that may not be a huge issue, but it will look weird if you try to look at historical data.

In particular, the code snippet from the blog post,

    if (size && size > SIZE_MAX) {
        errno = ENOMEM;
        err(1, "overflow");
    }

is a total no-op. It can't ever be true, the compiler might as well just remove the whole thing.

Does anyone have a good explanation as to why this is supposed to be hard to achieve? What incentive do miners in the distant future have against inflating a cryptocurrency?

For example, take Bitcoin after the cap has been reached and mining bitcoins only gives fees. If 50% of miners cooperate to make blocks worth real bitcoins again, they will suddenly start raking in more profit. They will be devaluing everyone's stores of bitcoins to do it, but people who hold bitcoins have no say in it, only computing power does. If we assume that miners will be the main owners of bitcoins for all eternity then they will probably never agree to this, but if there are a lot of miners with very little in reserve then why wouldn't they accept devaluing bitcoins a little bit to get more per block mined?

It's nice to hold up League of Legends as a shining example of IAP done right, but the fact is that there are plenty of excellent games with vibrant communities that couldn't even dream of having 5 million concurrent players. Riot does fine with very little marginal revenue per player, but not many other games can do the same, especially on mobile.

I wish there was a better way to switch between pencil marks and writing final answers. I put up with multiple clicks on my phone because I only have one finger, but I have a keyboard and a mouse with two buttons -- maybe holding spacebar would toggle, or right-clicking or something.

Pyret doesn't actually have an indentation-based format (so far as I know) it just happens to look like python.

If I were starting a company to provide service for this protocol, or if I were an email provider considering supporting this protocol, I would be much more happy if it were called something other than Dark Mail.

If this really is just a protocol, and not a marketing name, then the main thing it needs to do is be inoffensive and distinguishable. Honestly, I would be much more comfortable starting a company around a protocol named something super-dumb like MURP or another non-descript acronym.

There are probably names that are just as bad for other reasons, but one of the top goals of naming something like this should be avoiding getting targeted as something intended for illegal use.

You're being downvoted for some reason, but you are right. This is a variation of the Gambler's fallacy, where the miner thinks that because it has mined on branch 0 for some time, the expected time to mine a block on branch 0 in the future will be shorter than on branch 0'.

By way of directly illustrating this, consider slot machines with identical payouts. Grandma has been inserting coins into slot machine A for twenty minutes, when suddenly slot machine A' is turned on. There's no difference between continuing to pump coins into slot machine A and switching slot machine A', the expected payoff is the same either way.