From within any of the three styles of programming you can emulate the other two. In that sense they are similar. Secondly the principles of good programming don't change just because you change styles. When OO came on the scene, it was a good idea for reasons that good procedural and functional programmers could recognize.

So in that sense not much differentiates them.

But there is a large amount that differentiates them in attitude and style.

First of all, unlike what your synopsis indicates, it is not the case that any of them is clearly better or worse than the other two. Rather all three can be done well, done poorly, and is appropriate in the right situations.

Imperative (aka procedural) programming is about giving a series of orders to the computer. Do this. Do that. If such and so is true, here is the next thing to do. This does not mean that the program is one huge monolithic body of code. Code Complete is all about imperative programming, and certainly does not recommend that! But the mode at which you interact is give instructions.

Object-oriented programming moves from orders to requests. The data is envisioned as being composed of simple entities called "objects". Each object knows how to do certain kinds of tasks, and is given requests to do them.

But what is the difference between giving orders and giving requests? Will the object choose not do do what you asked it to do? Hopefully not!

But conceptually there is a big difference, and the difference is that when you give an order, you think you know what it is going to do. When you give a request to an object, you aren't sure what it is going to do, or how it is going to do it. You generally have an idea what the end result is going to be like, but you don't know or need to know the details.

This is both a good and bad thing. It is a good thing because it encourages encapsulation. It provides a natural line along which you can decompose and structure code into conceptually separate components. It is a bad thing because many objects now need to be taught how to do very similar kinds of tasks. OO programming addresses this by adding structures like classes and inheritance behind the scenes.

Functional programming turns the way you think inside out. Most procedural and OO programs are written with the assumption that the programmer basically knows what is to be done, and generally knows how it will be done. By contrast the bulk of a functional program is generally devoted to writing the program that you will later run.

What you noticed is that the code wound up with things divided into a series of function calls. That is true, but incidental. What I notice is that the largest part of the code is involved in functions that write other functions. Virtually all of the functions that exist were generated as closures. The small amount of end code makes very few assumptions about what it is doing. After writing that small amount of driver, the majority of development was spent adding more code that writes other code.

Now two notes.

The first is that encapsulation of data is not unique to OO code. For instance I used a lot of closures. Closures encapsulate data in an anonymous function. The encapsulation is without the structure that you recognize in OO, but it is encapsulation. In fact I would go so far as to say that functional programming without closures is like OO programming without objects...

The second is that what I built is not at all like HTML::Parser. What it does is takes a document and processes it according to a custom markup language, and spits out HTML. The custom markup language happens to look a lot like HTML. However it is not actually valid HTML, and many of the extensions (like being about to write \& to escape an & without needing to remember that the escape code is &...) that you would want to add to it are even less like HTML. You can't do that if you are handed a document which is not valid HTML to start with...

So to summarize, the three techniques that I named are not so separate. They can be mingled. Each can be used to imitate the others. But if you sit down to write a significant program in each, you will definitely experience the difference for yourself. And if you only had exposure to 2 out of 3 of them, you would be unlikely to conceive of writing a program in the other style...