next :: Java -> Haskell

You might have read Seeing Java where I described my experience writing a project for a Java class as an exercise in learning some modern Java. Today I did a similar experiment but on a much smaller scale and with one of the polar opposites of the Java language: Haskell.

Haskell is something I’ve been thinking quite a bit about lately as I’ve been pushing myself to learn more about “functional programming.” Haskell and Clojure are two languages that break the normal paradigm I’m used to and encourage a dramatically different style of programming. They  take very different approaches to that concept, though, and I’ll only be discussing Haskell today. By the way, today is the day I wrote my first program ever in Haskell.

Functional programming is a misnomer. Most software is functional. The term comes from a technical aspect about passing around functions whereas many languages only allow passing around data. Functional programming is basically the result of the worlds of mathematics and computer science crashing into each other. I’ll describe it more fully in a future post.

Java and Haskell have strong typing in common, but Java’s typing system feels like a bear compared to Haskell’s, which helps more than it annoys. Typing is lightweight in Haskell, which means that the language encourages creating all sorts of names for a certain type of data. Instead of a list of numbers in a certain form, for example, we might create  a phoneNumber type. This can be done in most programming languages but it can require more effort to do well.

Haskell is a purely functional language. This comes from the math side of things and that means we can make a bunch of assumptions about the code we write, which in turn makes code that might otherwise be very slow to run work fast. Usually when programming there is a way to write code that is simple to understand but slow and another way that is harder to read but runs faster. Because we “promise” not to do certain things, the Haskell compiler can translate our easier-to-read code into faster-to-run code for us.

Haskell has a bad reputation for being incredibly cryptic. My first bit of Haskell was pain-free, but I’m not doing anything particularly complicated. I enjoyed the language syntax (the format for how you are supposed to write the program) and the error messages were pretty good when I wrote incorrect code. As a programmer I didn’t find this any more cryptic or hard-to-read than just about any other language.

One of the things I really enjoy is the declarative nature of this code verses the imperative or procedural nature of what I’m used to. When we typically learn how to program, we are taught how to break complicated processes into smaller and smaller steps and then order those steps in code to accomplish our goals. The math-side of functional languages prefer to focus on the relationships between data (or input and output) and let the computer “figure out” how to make it work. Let me illustrate with a description of pattern matching.

Pattern matching is a way to specify different behaviors for input that is structurally distinct. A little code will hopefully make sense.

pluralize :: takes a word and a plurality indicator to make a new word
    noun 1 = noun
    noun 2 = "a couple {noun}s"
    noun n = "{noun}s"

Disclaimer: the above snippet isn’t real code from any language, but it’s similar to how Haskell makes functions to operate on data. We can see here in the second line that if we call pluralize with a noun and a count of 1, then we just return the noun. If, however, we want the noun for a count of 2, the function pieces together a simple fragment, “a couple of things.” Finally, if we call it with any other number besides 1 or 2, we simply add an s on the end of the noun and call it a day. This crude pluralizer won’t get an A in grammar class, but it’s not a bad way to describe the behavior we want from pluralizing nouns.

This code snippet leaves much to be imagined on how to accomplish the pluralizing. In a traditional imperative language, we would have to construct it in a way that includes lots of “support” code, which figures out what circumstances we are in before giving a new value.

pluralize( noun, count )
    if count is 1 then noun
    else if count is 2 then "a couple {noun}s"
    else "{noun}s"

The differences are subtle in a simple function like this, but in the first snippet we don’t have to perform checking on the input to see if it is a particular value and then to respond accordingly. Sometimes we end up with more code to check the input than we do to actually get.stuff.done. Again, this is a result of the mathematical focus on the algorithm in Haskell and other functional programming languages.

This was a small project but a fun one. Reasons for choosing Haskell for a project include the language’s ability to prove its behavior the way we construct mathematical proofs such as for  the Pythagorean Theorem, its ability to concurrently run code safely, its type safety, and the love of the purity and expressiveness of the language.

The only real trip-up I had came from the fact that I was running my code through my text editor – a “set-it-and-forget-it” kind of deal. Unfortunately, a few of the errors I made in the process caused the code to run forever without ending, so I was surprised to see a popup telling me that my computer’s memory was full and I had to close some applications or it would crash. Whoops.

Want to see the code? Here it is. How much of what it is doing can you figure out? How would you attempt to add a new function in this code to compute the standard deviation?


import Data.Monoid;
x1 = [1..100]
x2 = [2,4..100]
x3 = [3,6..100]
data Summary = Summary {µ::Float, n::Int} deriving (Show)
instance Monoid Summary where
mempty = Summary { µ = 0, n = 0 }
mappend s1 s2 = Summary {
µ = combinedMean s1 s2,
n = (n s1) + (n s2)
count :: [Float] -> Int
count xs = length xs
mean :: [Float] -> Float
mean xs =
let s = sum xs
n = fromIntegral $ count xs
in s / n
describe :: [Float] -> Summary
describe xs = Summary { µ = mean xs, n = count xs }
combinedMean :: Summary -> Summary -> Float
combinedMean s1 s2 =
let n1 = fromIntegral $ n s1
n2 = fromIntegral $ n s2
µ1 = µ s1
µ2 = µ s2
in (µ1 * n1 + µ2 * n2) / (n1 + n2)
main :: IO ()
main = do
putStrLn $ " x1 – " ++ (show $ d1)
putStrLn $ " x2 – " ++ (show $ d2)
putStrLn $ " x3 – " ++ (show $ d3)
putStrLn $ " x1 + x2 – " ++ (show $ d1 <> d2)
putStrLn $ "x1 + x2 + x3 – " ++ (show $ mconcat [d1, d2, d3])
[d1, d2, d3] = map describe [x1, x2, x3]

Seeing Java

In the world of programming there is a particular language known for its…well…thoroughness in doing its job: Java. If any programming language were to build the Great Pyramids, it would probably be Java – and this is no compliment!

A friend of mine is the teaching assistent for a Java class at the University, however, and out of curiousity I recently had him send me a class project. I’ve always ignored Java despite it being one of the most popular programming languages and wondered what I might be missing out.

The rest of this post is a personal reflection on my experience building a program to compare two Poker hands in Java as a “class project” for a first-year Java class.

Continue reading “Seeing Java”

Peace at SFO – who would’a thunk it?

It’s incredibly calm right now, and considering the chaos I left an hour ago – that’s pretty incredible. This weekend I have been attending the Hacking EDU conference at our Automattic booth (we’re one of the primary sponsors). The event bills itself as the largest educational hackathon in the world and more than twelve hundred students attended (or so I was told). It’s been a good weekend but pretty loud and chaotic.

Somewhat late in the day I decided that it would make more sense to spend the night at the airport instead of trying to get here in time for my 6:00am flight home. Times like these I really wonder what I must have been thinking when I booked the flight, but it’s all going to work out just fine. I’m the only one in sight except for a few scattered cleaning crews and the only noise is the gentle hum of the air conditioning. Having this peaceful and quiet decompression time wasn’t something I anticipated, but I sure am thankful for it.

Hundreds of students form teams to compete for prizes and internships.

Those of us who attended the Automattic booth at the hackathon didn’t know what exactly to expect there. The array of highschool and college students, on the other hand, all seemed to have some idea as they strolled in on Friday afternoon carrying a sleeping bag under one arm and a wide-screen monitor in the other. We brought more swag than we usually would, but I think we ran out of most stuff after about an hour or two – those freebies went fast!

Unlike most of the other sponsors, we weren’t exactly there to push our products or services on the participants. Lots of people came and asked us, “What are your APIs?” and expected us to have a list. We really just wanted to encourage them all to pursue programming and their creative talents, but a couple other companies brought some hefty prizes: $2,000 for the most creative use of Target’s API; $5,000 for the best app built on top of a database platform online; etc… We sponsored a prize for the app or idea with the greatest social impact.

CSE0hoIUwAAejxl (1).jpg
Not homeless; not underprivileged; this is the making of a Silicon Valley tech-startup entrepreneur.

For those of us at the booth who didn’t grow up in the Bay Area, we had a mantra for the weekend, “This is sooo Silicon Valley.” (We were referencing both the startup culture of this area and the parody sitcom about it on HBO). Students had a surprisingly varied level of technical background, from those hitting the ground running to those who didn’t realize that Facebook runs on the Internet, but almost everyone had one goal in common: find the next disruptive and revolutionary idea to pitch to the judges; find someone interested enough to fund their idea; chart their own way as their own boss and eschew college – and oh how buzzwords flew 😊.

Sadly, for most of them this is but a pipe dream, but a few will probably make it in the end and hopefully they will all go away inspired and energized. Some really incredible people spoke at the event: the founder of the Y-Combinator, a popular seed-funding venture capital program; the founder of the Khan Academy online learning website; our very own Guillermo Rouch (who just left Automattic a couple weeks ago and will probably start some other great new thing any day now); and several leaders and pioneers in the technology world.

One of the side rooms where the “magic” (or attempted sleep) was happening.

The students are spending the whole weekend at the event center. I’m pretty sure most of them will have gone seventy-two hours without stepping outside or seeing the sun before they finish up tomorrow. The stocks of Redbull and Hint water, the stacks of paper towels and Fruit Loops, the emergency boxes full of toothpaste and mouthwash were staggering and hilarious at the same time. It has just been such an incredible experience and I know I would have loved to have participated when I was still in highschool. Although we left just a single Automattician to man our booth, the kids are still grinding away (between playing bubble-ball-soccer and taking advantage of the biggest LAN party they will likely ever experience). Their teams and projects have to be officially submitted in about ten minutes from now, I think, but they can continue to program or finish the details before demonstrations and judging tomorrow.

As usual, I chose adventure over luxury for my travels here to San Mateo and stayed at a “HackShack” hackers hostel. Actually, it’s just the home of a couple guys pushing along in the startup world trying to make the best-new-thing and they have opened up their rooms to errant hackers. Last night I had the great opportunity to work with them and chat for a while before going to bed and I had a great time learning about the problems they are trying to solve and the innovative ways they are accomplishing them.

It’s a shame to come all this way and hurry home, but I had plans long before this weekend to be with Mandi tomorrow. I would have liked to have hung out a bit more with my new startup friends at the Hack Shack and to have taken the train up to San Francisco to visit a few teammates, but honestly the Grand Meetup was exhausting and relentless – just as this weekend has been too. I had a lovely time getting to know a few of my coworkers better and now have the awesome experience of being the only one in a busy airport. Have a nice rest yourself; and good night!

No more code rot

A key security component of Windows…has a validity of 15 months and is going to expire in 25 hours.

This is what I read on the blogosphere today and it made think about doing software design. We all hate old code because we’ve grown and learned since the time we wrote it and now think that we’d never make those mistakes again.

Nevertheless, changing code once it’s checked-in to a project can be harder than landing a probe on an astroid. Code moves in and settles down, bringing all its baggage and bad habits with it – we call this code rot because the longer a certain piece of code is in a system, the worse it tends to look or smell when we review it.

What if we couldn’t let this happen though? What if everything we wrote would self-destruct after a predefined amount of time and if we failed to update it, our software would blow up? All traces of the code vanish, all of its history disappears unless someone looks over it and updates something. Small updates would extend the deadline for a little bit and bigger refactors would add prolonged delays.

This might be a novel way of prioritizing bug fixing and performance over adding new features.

Sex Tractor Preview

No, it’s not a racy post. It’s a play on words some funny programmer chose for the name of this StarExtractor. Actually, it’s called sextractor without the space, but I digress.

It may not look that impressive now, but it carries massive implications.
It may not look that impressive now, but it carries massive implications.

This represents a big step forward in my pursuit of a clear shot of the night sky. The process that I have worked out requires automatic alignment of each shot from my nocturnal photo-shoots, but the algorithms I have been using keep failing. My suspicion is that they fail because they are looking for features and the stars are just a bunch of points – featureless.

This, however, changes everything. This is a line drawn among the fifty brightest stars in the central area of the image and I was able to produce it automatically with the help of sextractor, which identified and classified the stars in the image. These lines will hopefully be enough of a set of features for the other algorithms to match.

Onward and forward!