WTF#: Curriculum for F# part 1, thinking about curriculum for CS
No picture today, the Community server didn’t want to host it.
What the F#, umm, does that work? Oh well, I’ll stick with it for awhile. After all blogs like this are not broadly read, so I figure I can talk about anything I want to. Ok, on to curriculum and pedagogical discussions:
- So what should a curriculum for a class that uses F# look like?
- Should it be curriculum for Computer Scientists or can a new path be adopted?
- If a new path is adopted then will it be accepted?
- Should I care if it is accepted? (Answer: Yes)
After all, I have read most of Minsky’s papers and posts over the past 50 YEARS and he doesn’t seem to really care what other people think. Of course, he is a tenured professor and I have to think about profit and audience.
So what would be a source for representative curriculum? OCAML classes come to mind, the excellent work done at UCSD on OCAML might be a good source, but on thinking about it, why? F# and OCAML are very similar except that F# is tied to the .NET Framework and OCAML isn’t, the Light Syntax is the same.
But what about the structure of the class, if the market is to be engineers and scientist does the class have to be difficult, or should it be a fun way to re-attract the students to programming? A honeypot would be a class that is fun and informative, with an eye to the student getting a very positive experience out of the classroom.
In starting my curriculum development, I will review the “Seven Deadly Sins of Introductory Programming Language Design[i]”. Although neither F# or OCAML was designed to be a first language, for engineers and scientists, it might very well be the only programming language this group of students will deal with in the future. The domain knowledge for engineers and scientists, not to mention the large load of “general education” in the US, means that the undergraduate engineering and science students may only have one programming classes at many schools. So in developing the curriculum the rules in the Seven Deadly Sins need to be avoided.
1. Less is More:
- Much of the problem solving that students do in the real world is procedural
2. More is More:
- “..syntax vs semantics, static vs dynamic structure, process vs data, puts a big cognitive load on the student….”
3. Grammatical traps:
- “…confusing syntactic and semantic constructs which are present in most introductory languages…”
4. Hardware dependence:
- ”… novice programmer is often forced to contend simultaneously with the constraints of the underlying hardware…”
5. Backwards Compatibility: “
- …languages which attempt a significant degree of historical consistency inevitably perpetuate some problematical constructs.
6. Excessive Cleverness:
- “…some languages (ABC, Haskell and Python, for instance) use indentation to specify scope. This eliminates the need for grouping constructs...”
7. Violations of Expectations:
- In this case the beginning programming language may do something that is not expected or uses a non-institutive rule such as always sorting lists upon input or violating semantic rules
In a future post I will review how these rules impact F#, which could be a great first programming language for non-CS, the bulk of the rest of students would clearly benefit from a functional language similar to F#.
The big question is this: How do you motivate the students who only want the programming language to solve domain problems and aren’t into the programming for programming sake?
[i] Conway, D. and McIver, L. Seven Deadly Sins of Introductory Programming Language Design. Department of Computer Science, Monash University. <http://www.csse.monash.edu.au/~damian/papers/PDF/SevenDeadlySins.pdf>.
Conway, D. and McIver, L. Seven Deadly Sins of Introductory Programming Language Design. Department of Computer Science, Monash University. <http://www.csse.monash.edu.au/~damian/papers/PDF/SevenDeadlySins.pdf>.