Simon Peyton Jones gave a talk at the Cambridge BCS-SPA group on testing with functional languages (esp. Haskell). (Someone’s already posted the video and slides; careful it’s large!).
Some important points:
- Future of programming will be about “Control of (Side) Effects”
- Programming languages will become more functional than imperative
- Purity is good for understanding, verification, maintenance,
- Purity pays back in performance, parallelism, testing
- Functional/value-oriented is easier to test than object-oriented stateful
- Functional is good for generating tests (domain-specific language)
After a short intro into Haskell (10 min Haskell 101:)) SPJ moved onto testing in Haskell. In his demo, he tested a programme that would pack 7-bit words into 8-bits, so that eight ASCII characters would take up only 7 byte instead of 8. This sort of space saving is done in SMS where bandwith is precious.
One fundamental test tried to assert that
unpack(pack(x))==x. After testing some hand-written cases, which succeeded, the test started to use randomly generated words and started to fail after after a few hundred attempts. Due to its random nature, it took a randomly varying number of cases, but typically it failed after less than a 1000 cases. (It turned out that words of 8-byte length ending in a particular bit sequence were not correctly packed.)
The beauty of the underlying Haskell testing framework was that it took very few lines of code to express a generic testing framework.
The talk also showed that sometimes testing with large random test data is necessary to find bugs; something we rarely do!?
Overall, I found the speaker very engaging and the talk enjoyable even if I won’t claim of having understood or remembered everything.
Had to find some strings (varchar2) in a table that were just blanks with optional end-of-line characters thrown in.
Luckily, regular expressions make that an easy task. Here is the query:
FROM myTable x
WHERE REGEXP_LIKE( x.myColumn, '(^[[:space:]]*$)' );
A short explanation:
^...$ says that pattern applies to the string from start to finish, i.e., it’s not just a sub-string pattern,
[...]* says that pattern occurs 0 or more times (could also have been […]+ in this case),
[:space:] defines a pattern of all white-space characters, including blank, \t, \r and \n.
Sometimes, regular expression just make tasks like these very easy.
The perennial question: Should I buy an Apple or a Windows-based laptop? The question came up recently for me since my old systems were getting a tad too old, and I also happened to come across this blog (a bit outdated of course by now, see below).
Some basic facts as they are available today (March 2008) in the table below. I chose a Dell since it is widely available and a very common and representative competitor.
||Dell XPS M1530
||2.4 GHz Core 2 Duo (?, 3MB L2-cache)
||2.4 GHz Core 2 Duo T7700 (800 MHz FSB, 4 MB L2-cache)
||2 GB memory@667MHz DDR2 SDRAM
||3 GB memory@667MHz DDR2 SDRAM
||GeForce 8600M GT, 256MB SDRAM
||1440 x 900
||1280 x 800
||320 GB@5400 rpm
||Mac OS X v10.5 Leopard
||MS Windows Vista Home Premium
The Dell version has been customised slightly by choosing a faster matching processor.
This is the best match in terms of hardware components I could find. They are quite close: the Dell scores better in the memory and hard-drive specs, the Apple in the resolution.
Hence, we are down to Max OS vs Windows Vista, the various bits of pre-installed software, the quality of the components (hard to judge from the outside) and the very personal matter of taste.
Currently, I personally just can’t get myself to pay a 40% premium for the Apple. One problem for me is that Apple seems to update its hardware specs only infrequently while others constantly upgrade or adjust prices (downwards). And so the Apple laptop starts to look more and more expensive over time. I will keep looking and comparing …