## August 11th, 2006

### how i/o can work in a purely functional language

Without using fancy jargon or theory, here's an attempt to explain how you can do "impure" operations (like deleting a file, or updating an array) in a purely functional language. It's actually pretty simple; once you get it, it may be a bit of a let-down. But I need to get this out of the way for some later posts to make sense.

)

### obviousness

When I was in college I sometimes helped people (friends of friends, etc.) with their programming homework. I remember J was in an intro class and needed to find an element in an array. I tried to explain to him how linear search works: first you look at the first element, then then the next, and you stop the loop if you find what you're looking for. No matter how I phrased it, it seemed he didn't get it. It was like there was a floor of complexity, a minimum level of understanding and I couldn't express ideas any simpler.

(Yes, I've seen that paper that argues that programming is simply "beyond" some people. I think it's bunk: their testing methodology measures something that correlates with a bunch of other explanatory but unmentioned skills.)

Sometimes Meena will see me programming and say "I can't believe you think this way", but to me it's so natural I can't imagine thinking another way. I remember taking a logic class in college (part of the philosophy department) and wondering why other people couldn't do the proofs.

I almost feel the same way about types now, except that I can still vaguely remember before. If I look at the official Haskell tutorial on IO, I remember that it was confusing but the memory is strongly overridden by how straightforward and sensible it seems now. If I were to try to explain IO to myself I'd just say that the => operator from my previous post had type `IO a → (a → IO b) → IO b` and I'd be mostly done.

So since I can't remember what about typing was confusing, I made a point in my previous post of not talking about types at all and instead phrasing it in runtime terms ("if this produces a value, then next ..."). This is not at all how I really think about it. It is a stretch of my imagination, which is part of why I tried to write it.