When people talk about 'interface design', it seems they rarely mean anything more than where on the page to place the navigation... The crux being that we all assume a set of priors, and everyone asks "how do we make doing this easier?" instead of the more fundamental "what does the user want done?" I don't think that skill is necessarily related to other forms of design -- it's just a case of taking a step back.
Is it not possible that it's a bit of both? Given this scenario, which is clearly very likely, enforcing gender stereotypes could dissuade a child from walking a certain road down which their nature would have led them.
Boys and girls are naturally different, yes, but as demonstrated by the many women in science, that doesn't mean that all females want to grow up to become hairdressers or models.
Stereotypes do affect a child's development. Please don't limit their potential.
"Various studies have shown that software broadly contains something like 6-16 bugs per 1000 lines of code."
As more features are added, the number of bugs will increase, so in a sense everyone who is not on the stability team is on the instability team. Which means the stability team would need more developers as a counterweight...
I think this is getting a little beyond my linguistics skills...
Edit: I suppose which syllables are easily corruptable depends on the medium: written hashes would require a different set of graphemes than spoken hashes would phonemes, for example, while memorised hashes would likely be different again. I wonder if there's been any research or anything into this.
This seems to work by "compressing the input digest to a fixed number of bytes, then mapping those bytes to one of 256 words." So since there are only 256 words you end up with a lot less information than you put in, unless you have some 16 words.
It would be better if we had a much larger dictionary, since we could map more bytes to a single word -- with a list of 65,536 words we would need only 8 words per 16 byte hash, which I think is a lot more manageable.
I do completely agree with you that we ought to transition toward structural code editors (and therefore, I suppose, structural terminals), but as you say, that's a very hard problem -- I have yet to see one which isn't terribly clumsy to use.
A very good point. My prototype protocol, rwr, reads only the data in the file it has to know. Additionally, when one inserts a character it simply says "insert 'a' at byte 4", rather than having to stream the entire file. That's another benefit of running filesystem models as daemons on remote servers.
You don't seem able to see the forest for the trees... Taking quotes out of context and dismissing them is not sufficient to dismiss the entire article.
The concept of a view and a controller are distinct, a terminal simply happens to be both, because it can do both. Commands are solely controllers, and you're right, a read-only terminal would be just a view.
The submitter also retitled "The Rise and Fall of Bitcoin" to "The rise and... rise of Bitcoin". He seems to like pushing some agenda. http://news.ycombinator.com/item?id=3275203
Suggesting that it takes ten years to become "a programmer" is absurd. An experienced programmer, perhaps, but as soon as you can write and reason about programs (inferring what they do without a compiler), I would call you a programmer. Whether you're good is another matter, though a talented programmer can outpace one a decade their elder.
The C library does have an impact on the binary size. Compiling Hello World with Glibc results in a 3 KB binary on my system, while compiling with Musl results in a 1.9 KB binary. Compiling statically (no shared library dependencies) with Glibc results in a 498 KB binary, while with Musl it is only 4.6 KB.
I wonder whether it would be possible to optimise the Python interpreter to make deep copies copy-on-write. I suppose that would involve a lot of work for relatively little gain.
I always found iBooks' attempt at skeuomorphism really off-putting, at least on the iPad: the size of each page will change depending on whether you hold it portrait or landscape, and so the number of pages, and on which pages text can be found, will all change. I actually stopped using it shortly after downloading it for exactly this reason. It promises to behave like a book, but falls far short. No pages at all would have been preferable.
So if we have polymorphic types, and now polymorphic kinds, if we call those first- and second-order polymorphism, why can't we extend this to higher orders? For instance, third-order would be when our kinds' types are also polymorphic.
Well, in this instance you wouldn't need any work factor, since it would always take half a second. And if a zero work factor hash is taking half a second to complete, something is very wrong... But granted, for almost all cases it would be best just to bcrypt in every circumstance.
My earlier comment (which was for some reason downvoted) also solves this problem: you will always sleep for half a second, timer resolution is irrelevant, and if an attacker bogs down the system such that bcrypt takes longer than half a second, when the timer finished it would notice that bcrypt wasn't done and treat it as a failure.
It would be a bit of a hack compared to just using bcrypt every time, but it would save processing power, which may be useful in some contexts, like very energy-efficient devices, etc.
Admiring nature and animals doesn't lead to my becoming a biologist, nor drinking beer lead to my founding a brewery. You can appreciate something without having to really understand what is going on beneath the surface. We are just predisposed to an interest in technology, is all.
I much prefer to have vocals in my music, so my solution is to listen to songs in a language I don't understand or no language at all — Faye Wong, Cocteau Twins, Sigur Rós, etc.