LispCast

Object-Oriented Dispatch is the Dual of Functional Dispatch

Wed 11 Mar 2015 02:56:53 PM CDT

Object-oriented dispatch is contrasted with functional dispatch, but they are shown to be two one-dimensional projections of the same two-dimensional data. Clojure does not provide the two-dimensional representation, but does interesting things to transcend the one-dimensional views.

Read full post

Object-Oriented Programming is the Dual of Functional Programming

Sun 08 Feb 2015 11:22:31 AM CST

Object-Oriented Programming is often shown in contrast to Functional Programming. But they are so exactly opposite that they are duals, and so equivalent in important ways. Which one to use should be left up to the programmer, as is done in Clojure and Javascript.

Read full post

The Paper Metaphor

Fri 27 Feb 2015 12:57:38 PM CST

Functional programs follow a simple rule: never write on the same paper twice. Imperative programs are free to define their own rules. Both have interesting consequences.

Read full post

The Content of Your Code

Mon 06 Oct 2014 02:25:46 PM CDT

Code style is important, but way less important than content. Yet everyone talks about style because it's easier. Let's talk about content.

Read full post

What is Functional Programming?

Tue 01 Jul 2014 10:47:20 AM CDT

I prefer to define Functional Programming as making a distinction between pure and impure code. With this definition, you can program functionally in any language. What differentiates the functional languages is how much help they give you to make the distinction.

Read full post

Deconstructing Functional Programming

Sun 22 Dec 2013 04:33:32 PM CST

Because if you think about it, the stack itself is just an optimization. Right? There are these frames which contain information about each invocation. Each stack frame. Each activation record. And that's what they are--they're activation records. They're sort of objects. If you really have objects on the brain, like I do, then you realize that they're all just objects.

And they should be treated uniformly. You can even build a language that works this way--as I have. If that's the case, this is really a garbage collection problem. Right? Your stack traces might go away if you don't need them. You do need them when it's not a tail call because you need to go back there and use that information. But if it's a tail call, you don't need them, you don't need a tail call back to that frame. You need a pointer back to the last frame that wasn't a tail call. And they might get collected.

Which doesn't mean you actually have to implement it that way. Erlang sort of does. And there are many implementations that do that. They are not noted for their speed. If you can have real stacks, what happens when you run out of space? If you don't run out of space, it didn't really matter if you optimized the tail calls or not.

When you run out of space, you should GC the damned stack. You shouldn't just throw up your hands and say you're dead. And for all the normal programs that people write where it didn't matter, they won't care. And for your tail recursive programs, well, they might be a bit slower, but they will work. And then it's a matter of flags to the garbage collector if in production you don't want to debug it if you're sure it's all going to be fine--then go ahead and tell it to don't bother and just slam it and overwrite those frames directly.

Why is this so hard for implementers to do? Optimization is an optimization and should be optional.

It's a cool algorithm, but there's nothing nice that I'm prepared to say about Hindley-Milner.

He nails a lot of things I didn't like about Haskell.

All in all, this talk gets a lot of things right.

Read full post

LispCast

Object-Oriented Dispatch is the Dual of Functional Dispatch

Object-Oriented Programming is the Dual of Functional Programming

The Paper Metaphor

The Content of Your Code

What is Functional Programming?

Deconstructing Functional Programming

You might also like