QOTD

Teaching for understanding didn't offset the destructive effects of telling them how to get the answer. Any step-by-step instruction in how to solve such problems put learners at a disadvantage; the absence of such instruction was required for them to understand.

-- Alfie Kohn

From: Education's Rotten Apples

Apple store error

Just wanted to find out the status of my Snow Leopard order. Nice fonts though.

R Resources

Been learning to use R for a stats subject. These links were useful.

• Quick-R


• R programming for those coming from other languages

Other things I have stumbled across along the way.

• R - Resources


• Rattle GUI for data mining in R


• SNA in R Talk, Updated with [Better] Video


• Revolutions blog

Update 1/11/2009
For completeness I should also have included An Introduction to R that comes bundled with R, as well as the official R Wiki. Also discovered RSeek.org as well as this MATLAB / R Reference.

FsCheck xUnit integration

I am using xUnit.net at work on an F# project. I wanted to incorporate FsCheck and check properties via xUnit.net, but there is no built-in integration. I tried this from Matthew Podwysocki, but it is out of date with respect to the versions I am using (xUnit.net 1.5, FsCheck 0.6.1).

EDIT 28/09/2009: Here is the new and improved version based on Kurt's comment.

module FsCheckXunit

open FsCheck
open FsCheck.Runner 
open Xunit 
   
let xUnitRunner = 
    { new IRunner with 
        member x.OnArguments(_,_,_) = ()  
        member x.OnShrink(_,_) = ()
        member x.OnFinished(name, result) = 
            match result with 
                | True data -> Assert.True(true)
                | _ -> Assert.True(false, testFinishedToString name result) 
        } 
        
let config = {quick with Runner = xUnitRunner}

Below is the first version I adapted from Matthew's post and the FsCheck source code.

module FsCheckXunit

open FsCheck
open FsCheck.Runner 
open Xunit 
   
let xUnitRunner = 
    { new IRunner with 
        member x.OnArguments(_,_,_) = ()  
        member x.OnShrink(_,_) = ()
        member x.OnFinished(name, result) = 
            match result with 
                | True data ->
                    Assert.True(true) 
                    data.Stamps |> Seq.iter (fun x -> printfn "%d - %A" (fst x) (snd x)) 
                | False (data,_,args,Exception e,_) ->
                    Assert.True(false, sprintf "%s - Falsifiable after %i tests (%i shrinks): %A with exception %O"
                        name data.NumberOfTests data.NumberOfShrinks args e) 
                | False (data,_,args,Timeout i,_) ->
                    Assert.True(false, sprintf "%s - Timeout of %i milliseconds exceeded after %i tests (%i shrinks): %A"
                        name i data.NumberOfTests data.NumberOfShrinks args) 
                | False (data,_,args,_,_) ->
                    Assert.True(false, sprintf "%s - Falsifiable after %i tests (%i shrinks): %A"
                        name data.NumberOfTests data.NumberOfShrinks args) 
                | Exhausted data ->  Assert.True(false, sprintf "Exhausted after %d tests" (data.NumberOfTests) ) 
        }
    
let config = {quick with Runner = xUnitRunner}

Erik Meijer's influence on mainstream programming

Many people are trying to influence those in their field. In Confessions Of A Used Programming Language Salesman (Getting The Masses Hooked On Haskell) Erik Meijer talks about his journey and how he achieved massive influence on mainstream programming.

For many years I had been fruitlessly trying to sell functional programming and Haskell to solve real world problems such as scripting and data-intensive three-tier distributed web applications. The lack of widespread adoption of Haskell is a real pity. Functional programming concepts are key to curing many of the headaches that plague the majority of programmers, who today are forced to use imperative languages. If the mountain won’t come to Mohammed, Mohammed must go to the mountain, and so I left academia to join industry. Instead of trying to convince imperative programmers to forget everything they already know and learn something completely new, I decided to infuse existing imperative object-oriented programming languages with functional programming features. As a result, functional programming has finally reached the masses, except that it is called Visual Basic 9 instead of Haskell 98.

Infiltration is the key! Obviously Erik is a very smart guy who has put in the hard yards and knows his stuff. However to achieve major impact required joining an influential organisation and working on the inside, rather than an external activist or confrontational approach.

The whole paper is worth reading, although a large portion is naturally Microsoft orientated on .NET language/CLR features. Below are just a few interesting quotes.

From section 5.2 Standard Query Operators

It is quite surprising that Haskell is one of the very few languages that allows higher-kinded type variables. If, on the term level, parametrizing over functions is useful, doing the same on the level of types sounds like an obvious thing to do. As far as we know Scala is the only other language besides Haskell that also support higher-kinded types.

From section 6.2.3 Contracts

The static type systems of most contemporary programming languages are actually not that expressive at all. They only allow developers to specify the most superficial aspects of the contract between caller and callee of their code.
...
From a program-specification point of view, most programs are extremely dynamically typed!

It is a real shame Erik decided to join Microsoft rather than Sun or IBM. Although I guess he probably wouldn't have had the same level of influence on the JVM and associated languages.

Learning - context and details

My mathematics lecturers often try and introduce a new topic with a motivating example. I think this is a great idea. I am a slow learner and find that an initial concrete example is the best way to approach a new abstract concept. I realise that this can sometimes pose challenges further on, i.e. in generalising from the concrete to the abstract, but this way seems to work the best for me.

Unfortunately, there are many times that the motivating example is not that motivating. I view teaching as often building a bridge from the student's current position to where you want to take them. To achieve that, requires providing an initial high-level context in terms that the student can relate to.

As an example, earlier this year I studied introductory linear algebra that included eigenvectors. Kudos to the lecturer for trying to motivate with a modern example (search engine page rank). Even though I am a professional programmer, this example didn't really work for me and I finished the subject with only a vague idea about them.

Recently I read this article which introduced them with simple physical examples. The second paragraph of the current wikipedia page nicely related it back to matrices and vectors and it all fell into place.

Some mathematical ideas are represented as a sequence of steps, e.g. calculating Maximum Likelihood Estimators in statistics. Once a good motivating example is done to provide context, things can proceed between two extremes.

1. Present high-level steps and then dig down into the details of each step


2. Work through the details of each individual step and bring it all together at the end

In the latter approach, I sometimes miss the high-level steps if I get lost in all the detailed algebra and reasoning underlying each step. Can't see the forest for the trees. I prefer the former approach as it provides more purpose and is therefore more motivating. It also makes it easier to isolate difficult sections that can be returned to later, so as not to get bogged down and lost for the remainder of the discussion/lecture.

I wish I had utilised these ideas better in my Intro to Functional Programming talk a few weeks ago.

Re: Static Typing and Functional Languages

I unsuccessfully tried to post a comment on Static Typing and Functional Languages.

First thing to note, is that Functional Java ‘looks’ so ugly, because Java is not naturally suited to expressing these abstractions.

Secondly, type inference appeared in the 1970s, well before Java existed.

Thirdly, the assumption that functional programming implies static typing is difficult. Type system research has been largely motivated by a number of factors over the years, including compiler optimisations for program performance and theorem proving.

GMail down