codahale

In the meantime, I benchmarked Yoink's PeristentHashMap against 2.8.0.RC2's immutable.HashMap by a) creating a map of 100,000 sequential keys and then removing them all, and b) creating a map of 100,000 random keys and then removing 100,000 random keys. In the first case, Yoink was 20.7041% (±1.83693%) faster. In the second case, Yoink was 24.7834% (±4.17055%) faster. (Student's t distribution, 95% confidence interval, source is in src/test on the GitHub project and I used ministat for the statistical analysis [a cross-platform port of which is also available on my GitHub page].)

So to summarize, I have a provably faster hash array mapped trie at almost zero cost right now because I spent a few hours with a "good learning experience."

In contrast, Clojure's PersistentHashMap dates back to 2007 and was in both the 1.0 and 1.1.0 releases.

I'm also slightly confused as to why you think reusing stable, proven, and reviewed data structure implementations is a "good learning experience" as opposed to being SOP.

Ok, and I've seen Java apps not do that. Argument by anecdote is bankrupt.

The you that lifts your arm and the you which feels like it decided to lift your arm are on different schedules.

Here's a real prediction, with actual confirming evidence: giving someone with a high MADRS score an SSRI will reduce their score.

That's beyond seeing and naming depression, it's beyond recording patients' reactions to SSRIs, it's beyond spotting patterns in their reactions, it's even beyond making falsifiable theories about its mechanism of action. It's making predictions which are confirmed on a statistically significant basis.

Does this mean you think psychiatry has the same epistemological standing as physics?

Agriculture dates back to at least ~10,000 BC (the "Neolithic revolution"). Effective farming (i.e., not dying of starvation) requires planning for changing weather conditions. If you think Neolithic farmers didn't have a vested interest in detecting patterns in weather cycles, you're sadly mistaken.

Hell, the term "meteorology" was coined by Aristotle... in a book he wrote... called Meteorology... in 350 BC.

How long do you think people have been watching the weather for?

If you're confused, I'd highly recommend Practical Cryptography by Niels Furguson and Bruce Schneier: http://www.schneier.com/book-practical.html

It will give you much better advice than the internet will.

A system which uses an adaptive hash function like bcrypt is ~6 orders of magnitude less effed in the event of a compromised database than a system which uses a standard hash algorithm and a salt, ceteris paribus.

I would hope you agree that those ~6 orders of magnitude could well be the difference between "not noticeably effed" and "profoundly effed."

As far as CPU exhaustion, there are some huge sites which use bcrypt (like, in the top 10)[1]. It is not a problem, provided you choose your work factor carefully.

As far as complex passwords, use them. Try to get your users to use them. But it's an orthogonal concern: your attacker will still be able to work their way through the gigantic keyspace of your monster passwords at 1,000,000x the rate of what they could do if you'd have used bcrypt.

[1] Just looked this up. Not the top 10, but the top 15 for sure.

NIST expects SHA–3 to have a security strength that is at least as good as the hash algorithms currently specified in FIPS 180–2, and that this security strength will be achieved with significantly improved efficiency.

http://csrc.nist.gov/groups/ST/hash/documents/FR_Notice_Nov0...

Which, uh, is an objectively verifiable fact.

[1] http://www.imperva.com/docs/WP_Consumer_Password_Worst_Pract...

I'd love to recommend its use over bcrypt, as memory constraints are much more expensive than computational constraints, but recommending something most developers don't have access to would result in more weak hashing schemes in production.

In general, a password algorithm, whatever its cost, should execute with near optimal efficiency in any setting in which it sees legitimate use, while offering little opportunity for speedup in other contexts.

PBKDF1 and PBKDF2 both rely upon general-purpose hash functions, which are much faster in dedicated computing environments such as FPGA or GPU clusters. The Eksblowfish algorithm at the heart of bcrypt is extremely resistent to optimization.

This is crucial for password storage, since if a CUDA implementation is 3-4 orders of magnitude faster than the implementation your application uses, you've just chipped off a huge chunk of the advantage offered by your hash function.

They should refund him his money.

If you're storing a password, use bcrypt or I'll bite your thumbs off.

If you're making sure something hasn't been modified by someone and you absolutely can't use a signed GPG message, use HMAC-SHA256 and a constant-time comparison algorithm or I'll bite your thumbs off.

All the business about hash functions is like advice on how to build your own car brakes using a backyard smelter and a sand cast. You might get something of roughly the right shape and weight but someone's going to get hurt down the road.

From his link: Joshua Blankenship is a designer living in Anderson, SC.

If the upstream owner doesn't accept patches the project is hosed, regardless of how it's hosted.

The big difference with a DVCS is that those chaotic forks are public and can themselves accept patches. Developers can still pool their bug fixes, added features, etc., and perhaps the project can rise from the ashes.

If the project is hosted on a centralized VCS, all of those bug fixes and new features languish as one-off forks in private repositories. Instead of being a chaotic mess, it's moribund. You still have the same issue of having to maintain your own fork; you just don't have any help in doing so.

For example, "blah"[0] should return an Object instance which represents "b". Could be a Fixnum. Could be a String. Could be a JPEG of some ASCII art representing the essence of "B." Any of those responses would be valid according to RubySpec.

What happens when you shadow a local variable with a block variable is unspecified, too. In 1.8.x, it overwrites the variable. In 1.9, it doesn't.

Even with a "RubySpec-compatible" implementation, you have no way of knowing if your application will run or not, which kind of defeats the purpose.