I’m on the Making Our Own Types and Typeclasses chapter.

With prompting from the tutorial, knocked up the classic binary tree :

data Tree a = EmptyTree | Node a (Tree a) (Tree a) deriving (Show, Read, Eq)

root x = Node x EmptyTree EmptyTree

tInsert x EmptyTree = root x
tInsert x (Node val left right) 
    | x < val   = Node val (tInsert x left) right
    | otherwise = Node val left (tInsert x right)
    
tFind x EmptyTree = False
tFind x (Node val left right) 
    | x == val  = True
    | x < val = tFind x left
    | x > val = tFind x right

Which isn’t really all that impressive.

But what I think I’m more chuffed about is what I did next. My first attempt at a quick and dirty function to fill a tree from a list of numbers :

listToTree [] = EmptyTree
listToTree (x:xs) = foldl insert (root x) xs
    where insert = (tree val -> tInsert val tree)

That looks like it’s quite elegant Haskell, no?

Update : Or maybe not. Because I scroll down and see the next thing the tutorial does …

let numsTree = foldr tInsert EmptyTree [5, 19, 2, 52, 43, 32, 99]

So I basically missed the fact that the original tInsert was already sufficient to pass to the fold (at least in its foldr form, won’t work with foldl because the arguments are the wrong way around.)

Yes … I’m getting the picture. Laziness is pretty damned useful. You can basically just not worry about the end conditions for all those infinite series and lists you’re searching in.

So I decided to actually sit down and Learn Me a Haskell.

Worked through the first few sections. Kind of what I knew already except I think I’m getting a glimmer of why Currying / Partial Application is a good idea, at least in that it’s a very concise way of making higher-order functions on the fly.

Eg. :

Haskell

f x y = x * y
g = f 5

Python

def f(y) :
    return (lambda x : x * y)
g = f(5)

Haskell is certainly a lot more concise. And in Python you need to explicitly decide you want to make a function which makes multiplying functions. f only has that role. In Haskell f can be both a 2 argument multiply function AND a higher-order function factory.

Clever!

Stephen Wolfram's Introduction to the Wolfram Language

I’m impressed. Beyond being just a grab-bag of libraries (which it could have been) it seems there’s real thinking about composability here. The laziness of evaluation, the “symbolic-ness” makes it a powerful functional programming language. In fact, it’s almost a “data-flow” language. Of the kind, like Yahoo Pipes, which can become an orchestrator of web-level components.

That already gives some substance to the claim that this is a “new” kind of programming. But what REALLY differentiates it, I think, is the philosophical commitment to what O’Reilly used to call “Data Inside“.

This might well herald a new trend : “programming language as a service”. A language whose essence and value depends on not just the library of functionality, but the continuously updated data living in that cloud. This is genuinely new. (Maybe it contrasts with something I once said about SemanticCommitment, that semantic constraints weren’t the treasure that the SemWeb people thought they might be. Perhaps the Wolfram Language is a bet against me, and on the idea that we now have comprehensive enough databases of “knowledge” about the world, that packaging huge ontologies of semantics within languages is a valued feature.)

It’s also a huge risk to the programmer, of course. You’ll only EVER run Wolfram Language against Wolfram’s cloud. Every program you write will be dependent on Wolfram in perpetuity. And we know where that story leads … the cloud provider’s business model inevitably evolves to being observation and analysis of what the customer is doing. (And it should go without saying that every program you run is explicitly open to inspection by the NSA etc.) But some people will be willing to make that trade-off.

Mary Jo Foley asks if Microsoft could or should enable Android apps on Windows.

I’d think it would be more to the point to support standard HTML5 / Javascript apps. as first class citizens in Windows.

  • It’s just as good a way to pick up a lot of developers.
  • ChromeOS and FirefoxOS developers can port their apps. easily. Not as big as Android, but a growing segment.
  • Microsoft already DO officially support Javascript and libraries like jQuery in their development tools so it doesn’t require either a) telling developers to use non-M$ tools, or b) sending a message that they’re abandoning C# for Java.
  • They can claim to be supporting a neutral standard rather than capitulating to a reality determined by a more successful rival.
  • They, in practice, will be supporting a neutral standard which helps to undermine rather than further Google’s dominance.
  • I’d rather write a dedicated Windows OWL app. in CoffeeScript than Java. 😉

I don’t think I noted, when I was discussing bringing the OWL and OWLdroid codebases back together, that I was using Meld.

Just wanna say it here … Meld rocks! Thanks guys!