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 …
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.
f x y = x * y
g = f 5
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.
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.
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.
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. 😉