Academic Cross-Training

Cross-training is not a new idea.

In most professional sports cross-training is incorporated into the usual training regime. Although weight-training and swimming are popular there are more exotic options around. Some Australian Rules footballers have even dabbled in ballet.

In cultures that emphasize the development of the individual as well as excellence, breadth and depth are valued. And for those who like the etymological definition of philosophy -- love of learning -- this is a bit of a no-brainer.

Now, if you are focussed on a narrow goal over a wide-ranging journey the diversions of breadth may prove a waste of time. But if the converse holds you will find that there is much to learn by exploring other disciplines. Here's what happened when physicist Richard Feynman ventured into biology.

If two academic disciplines are dealing with similar material at a deep level, chances are that each has something to offer an individual who crosses over from the other side.

Of course forcing everyone to compulsorily study X, usually leads to resentment from a significant proportion of those so conscripted, so when I say should study, I really mean should be encouraged to study.

In terms of excellence, someone should make a list of people who have achieved excellence after switching fields.

* * *

In sports, it is well-known that gymnasts do well after switching to diving and ski-jumping. From this I infer that gymnastics teaches transferable skills.

What are the nominations for the gymnastics of academic disciplines?

The Programming Djinni Grants Wishes

As a commercial product develops the wish-list grows longer and longer. User suggestions and feedback are collated and prioritized. Pretty soon you have a very large list.

The tragedy of the C cases
Here's the problem: Lots of worthy but little items are continually pushed to the bottom of the pile, by the latest big feature.

I call this "the tragedy of the C cases". These items of functionality may languish, if proper discipline is respected, never bubbling to the top.

There are disciplined ways around this use Scrum and XP style planning, but these require buy-in from the non-programmers and may not be achievable within your organization.

The magic approach
Here's a simple and fun alternative for a small company or department: One day per month -- customarily on the 23rd (or the nearest weekday) -- one or more programmers turn into djinnis who attempt to grant reasonable and achievable wishes to one lucky person in the company.

This breaks up the usual routine (a good thing as per the Hawthorne effect), is engaging for the lucky person -- who sees some immediate results -- and it is also good for the programmers, who get the satisfaction of working directly with a tangible person for a change rather than through a mediated priority list. And the software gets nicely polished.

Try it: See how you go; let me know.

Re-write or re-factor?

On individual projects I have usually found that a re-write leads to smaller, cleaner, faster solutions.

I attribute this to learning acquired from the previous attempts/versions, which I can incorporate in the form of improved abstractions and better trade-offs subsequently.

Some re-use of "golden nuggets" from earlier iterations may also be possible, and is certainly desirable.

Some lessons learned can be incorporated incrementally through re-factorings, but there are times when incremental improvement takes you to a local maximum and traps you there.

On big commercial projects other considerations come into play. Until the new code-base is up you need to contend with the cost of parallel development, and this period will be longer the greater the legacy. Unless, of course, your new abstractions are brilliantly efficient, and/or you can cut away a lot of stuff that was not needed.

Once a project is sufficiently large, given finite resources, it may eventually be too late to ever re-write!

Here's some more useful discussion by Adam Turoff on these issues prompted by survey question by Ovid.

Is Law a Branch of Computer Science?

I studied Law as well (as Science) early in my University career before relinquishing it on account of near-terminal boredom during Contracts (the content of the first third of which ironically proved quite useful to me subsequently).

I remember a visiting lecture by a Government draftsperson, whose job it was to draft legislation. He also happened to be blind. Aha, I thought, this is why legislation is so appallingly structured. That was undoubtedly unfair.

Later I came to the view that lawyers should study programming in order to learn how to structure large descriptions about processes and contingencies.

Now, Dave has come along with this brilliant comparison of legal language and programming languages. It is funny because there are several truths in there.

So, perhaps in the 21st century it is time to include a compulsory "programming for lawyers" unit, along with "legal process" as an introductory subject?

This would extend the wider view of Computer Science as a Natural Science, to cultural endeavours such as Law.

Calculus? Which Calculus?

In high school and University I learned Calculus, by which I mean the Differential and Integral Calculus of Newton and Leibniz, and their extensions. I do not think that I really grasped the meaning of a continuous function until I studied metric topology.

I like calculus, I have used it professionally, and it is a glory of the modern age, but I do question the cost/benefit of teaching it to millions (billions?) of children on account of its difficulty.

What makes calculus hard?
I would say the relatively high level of abstraction, and in particular becoming comfortable with with either limits or infinitesimals (hello: non-standard Analysis). These things strain our intuition.

Why is calculus taught in high-school? My guesses:

• It is essential for physics and engineering, and other quantitative fields
  
• It is very beautiful and powerful (but you will not see that at high school)
• It is challenging
  
• It has a filtering effect on students
  
• Tradition

Since it has to be re-taught at College / University, I wonder whether it might be time to start teaching other Calculi in high school, just to mix things up a bit.

Perhaps a progressive school could hold a "calculus bake-off" and try to gauge the suitability and broad benefits of teaching and learning the various calculi?

Which other calculi could be taught?
Some might opt for the predicate calculus (also known as first-order logic), but my vote goes to the lambda calculus, which is fundamental to the theory of computing, and useful in practice. In fact there are computer languages such as Scheme (a Lisp dialect), ML, and Haskell that are essentially souped-up forms of the lambda calculus.

And if high-school sounds a bit late to get started with such an important subject, here is a game designed for eight year-olds that introduces the essential ideas.

There is no such thing as Computer Science

Not my words, but from a rather enjoyable rant, What's wrong with CS research. Here's the bit containing the best quote (my emphasis):

So here's the first thing that's wrong with CS research: there's no such thing as CS research. First, there is no such thing as "computer science." Except for a few performance tests and the occasional usability study, nothing any CS researcher does has anything to do with the Scientific Method. Second, there is no such thing as "research." Any activity which is not obviously productive can be described as "research." The word is entirely meaningless. All just semantics, of course, but it's hardly a good sign that even the name is fraudulent.

When we look at what "CS researchers" actually do, we see three kinds of people. We can describe them roughly as creative programmers, mathematicians, and bureaucrats.

If only he had claimed that there was no such thing as Science, now that would have been a fun proposition to explore!

Learning about (Computational) Monads

I am interested in acquiring programming idioms -- or if you like patterns -- that facilitate a clear and disciplined approach to organizing state. As applications grow large and certain operations transform state in a large-scale fashion, it becomes harder to understand and modify program behavior.

Perhaps monads offer a better way, but I don't really get them yet ...

What are Monads?

I think Leibniz invented the term monad to describe some kind of indivisible fundamental entity in his philosophy: Presumably the term atom was too Greek for him. Anyway: I do not mean philosophical monads, or biological monads, or mathematical -- category theory -- monads (although now we are getting warmer).

Right now I mean computational monads, the ones so beloved of Haskell programmers, but potentially of use elsewhere.

A monad is a family of types M t, based on a polymorphic type constructor M, with functions

return :: t -> M t
(>>=) :: M t -> (t -> M u) -> M u

satisfying

return a >>f = f a
m >>= return = m
m >>= (\a -> (f a) >>=g) = (m >>= f) >>= g

This definition gave me flashbacks to Pure Mathematics Honours (4th year University) where I encountered some classes so abstract as to seem totally detached from reality: "Hello Banach Spaces and Algrebras!"

How to get it

But having survived a mathematics education and having a ridiculously high sense of self-efficacy I know how to get through this kind of obstacle. There are two methods:

1. Abstractions first: Treat this as a game where the rules are given, and play with them until they become familiar and seem natural.
2. Empirical approach: Walk in the footsteps of the discoverers by building some practical experience first, so that the abstractions begin to make sense.

Better still, work from both ends. Anyway, both approaches require doing, as opposed to reading, and I am starting with the following tutorial:

You Could Have Invented Monads! (And Maybe You Already Have)

which seems to be helping, and belongs to the latter camp.

More later ...

Functional Programming Interest Group

An idea has been slowly germinating in my mind: Try to start a new special interest group (SIG) meeting in Melbourne once a month, but also with a virtual presence.

I have been working slowly through Abelman & Sussman's Structure and Interpretation of Computer Programming (SICP) and exercises, the MIT classic "introductory" text, but would like to share the experience. The great thing about SICP is that it is free online, as are accompanying video lectures -- the first was inspirational, but subsequently I have relied on the text. The tools are available online and free. The language used is Scheme (a teaching/research Lisp), but it's the ideas that come through.

There are other books out there which promise to capture exciting ideas using various f.p.-ish languages as vehicles:

• Hudak, The Haskell School of Expression
• Armstrong, Programming in Erlang
• Siebel, Practical Common Lisp (text available online)

I believe that languages such as these are worth studying for the ideas that they develop:

Haskell: Lazy evaluation, monadic computation, mathematical modelling, and more ...
Erlang: Practical, reliable, massive parallelism, ...
Lisps: Code-data duality

I am also interested in F# (as the .NET representative of the ML / OCAML) family, but am waiting on the publication and review of more books. [Forgive me for leaving Smalltalk, Forth, plus the various languages du jour off my list: There may well be too many already.]

Other probably books worth looking into:

• Graham, On Lisp
• Norvig et al, PAIP and AI: A modern approach
• Kiczales, The Art of the Meta-Object Protocol
• Sussman and Wisdom, Structure and Interpretation of Classical Mechanics (text available online)
• Doets and van Eijck, The Haskell Road to Logic, Maths and Programming
• Okasaki, Purely Functional Data Structures

Of course these are just some highly rated books, and not the literature, but my objective here is to survey some of the more mature parts of field; the leading edge can wait.

It's all about the joy of new and ongoing learning; with the bonus of becoming more skillful, productive, and having a chance of successfully working with the coming generation of massively multi-core machines.

I would be interested in hearing expressions of interest, suggestions for format plus any experiences and tips from anyone involved in such groups.