The problem is that it’s relatively easy to brute-force attack even a salted hash today.

On the first day, people stored passwords in plain text. If someone got access to your database, they had all the passwords.

On the second day, people decided to hash the passwords so that people couldn’t unencrypt them. Then the attackers created rainbow tables that correlated each hash with its associated password since the password would always hash to the same value (so you have “109BCA” in your database, but they have a table that has that hash and that “12345” hashes to that value).

On the third day, people decided to salt the hashes to render the rainbow tables ineffective. Now, each password would hash to a different value so they couldn’t just look up the password for a given hash. However, as computing power increased it became easy to just brute-force the password. You have the hash and you have the salt so you can just try every password with the hash until you get a match.

  hashed_password = "ACBDEF1234567890"
  salt = "12345"
  possible_passwords = ["password1", "ilikesheep", "micro$oft"]
  possible_passwords.each do |pass|
    if Digest::SHA1.hexdigest("#{pass}#{salt}") == hashed_password
      real_password = pass
    end
  end

The problem is that code like that has gotten really cheap to run and it’s incredibly parallel (you can have loads of machines each take a piece of the workload – oh, and hopefully no one will make a joke that you’d never write that in Ruby; I just felt that would be easy pseudo-code to demonstrate). You can just try combinations of passwords at random, but there are lists of more common passwords that you can try first making it go even faster. Hashing algorithms are meant to be fast because they’re meant to be usable on a large piece of data. As such, it also becomes fast to brute force check all sorts of combinations.

On the fourth day, people started using things like bcrypt because bcrypt was made to be slow. The fact that bcrypt is slow means that if someone wants to brute force it, it will be very slow going for them. If one can check 10,000 SHA1 hashes in a second, but only 10 bcrypt hashes in a second, it will take 1,000x longer to crack the bcrypt stored password (those are just made-up numbers as an example).

Salting is better than not salting because they have to brute force the password. However, as computing power increases it isn’t so much better because brute forcing is becoming easy. One needs to use a slow algorithm to make sure that cracking it will also be slow (prohibitively slow). Bcrypt also allows you to specify how much work you want it to have to do. This way, as computing power increases, you can increase the amount of computing power needed to compute the bcrypt. By contrast, hashes are meant to go fast and so every day they’re getting less secure.

Bobby Fischer was completely obsessed with chess and played and studied it incessantly.

9 years of manic dedication and he “suddenly” got good.

His mother spoke something like 8 languages and his father was a Hungarian physicist who headed the Theoretical Mechanics section of the Naval Ordnance Laboratory and was an expert in elasticity and fluid dynamics.

One famous story about his memory:

“One day when he was in Iceland, Fischer called Frederick Olaffson, Iceland’s only Grandmaster. Olaffson’s Icelandic-speaking daughter answered the phone and explained her parents were out and would return at suppertime. Fischer understood nothing that was said because he did not know the language. But he listened, apologized and hung up. Later that day Fischer met with another Icelandic player who spoke English. He explained what had happened and repeated every Icelandic word he had heard on the phone, imitating the sounds with perfect inflection. The Icelandic player translated the message word for word for Fischer.”

Despite being prodigiously “intelligent”, it still took years of dedication to get good, and years more to get really good.

Plenty of average people undoubtedly beat him at chess when he was a kid. When you think about it, it should be obvious that he was always that smart. Just because you’re a kid and don’t know anything yet doesn’t mean you aren’t smart. “Smarts” is not the same as skill.

Incidentally, his record as the youngest grandmaster in history lasted for many years until it was broken by Judit Polgar, whose father was explicitly running an experiment with his daughters to prove that prodigies are made, not born. All three daughters became chess experts. He explained that Judit, the youngest, was the most successful because she worked the hardest. She’s the only female ever ranked in the top-10 of the “Men’s” ratings list.

I swtiched jobs from being a computer programmer to being an ESL teacher in Japan. Japan is somewhat famous for churning out students who know a lot *about* English, but can’t order a drink at Mac Donald’s. We used to have a name for those kinds of people with regard to programming languages: language laywers. They can answer any question you put to them *about* a programming language, but couldn’t program to save their life. These people often make it past job interviews easily, but then turn out to be huge disappointments when they actually get down to work. I’ve read a lot about this problem, but the more I look at it, the more I realise that these disabled programmers are just like my students. They have a vocabulary of 5000 words, know every grammar rule in the book but just can’t speak.

My current theory is that programming is quite literally writing. The vast majority of programming is not conceptually difficult (contrary to what a lot of people would have you believe). We only make it difficult because we suck at writing. The vast majority of programmers aren’t fluent, and don’t even have a desire to be fluent. They don’t read other people’s code. They don’t recognise or use idioms. They don’t think *in the programming language*. Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel. And so our programs are needlessly complex.

Those programmers with a “spark” are programmers who have an innate talent for the language. Or they are people who have read and read and read code. Or both. We teach programming wrong. We teach it the way Japanese teachers have been teaching English. We teach about programming and expect that students will spontaneously learn to write from this collection of facts.

In language acquisition there is a hypothesis called the “Input Hypothesis”. It states that *all* language acquisition comes from “comprehensible input”. That is, if you hear or read language that you can understand based on what you already know and from context, you will acquire it. Explanation does not help you acquire language. I believe the same is true of programming. We should be immersing students in good code. We should be burying them in idiom after idiom after idiom, allowing them to acquire the ability to program without explanation.

One day Alice came to a fork in the road and saw a Cheshire cat in a tree. ‘Which road do I take?’ she asked. ‘Where do you want to go?’ was his response. ‘I don’t know’, Alice answered. ‘Then’, said the cat, ‘it doesn’t matter’.

A good (non generic) answer to “What should I learn?” (asked by a self educated programmer here) depends on the answer to the question “What (kind of programmer) do you want to be?” Step 1, answer the Cheshire cat! )