January functional kats
Details
We're going to tackle a fairly straightforward problem this month.
The task is to write a function that performs the Luhn checksum of credit card numbers. You can see a description of the problem and even source code (if you choose to peek) on Rosetta Code.
http://rosettacode.org/wiki/Luhn_test_of_credit_card_numbers
One of the most common complaints about functional code is that it's difficult to read, and the response is often, "You have to get used to it".
Let's put that to the test this month with a focus on producing the most readable solution possible. In other words, as long as the function is correct, readability trumps performance and all other concerns.
We're aiming for code that you don't have to "get used to".
This isn't a big function so if we start promptly we should be able to stop and compare code, pick up a few tricks from each other and then take another run at it before presenting our final code at the end of the night.
We're interested in seeing if any of the languages we use have features or idioms that help or hinder readability.
Feel free to pair up with someone on the night. It might be interesting to have one member of the pair be familiar with the language and the other not. This could raise interesting readability questions.
Finding Us:
Engine Yard's offices are at 35 Barrow Street, see attached street view. It's through that blue gate, and in the building on the left.
January functional kats