1. Imperative programming is as you say, a series of instructions (with flow control) of what the computer should do with its data. Code and data are seperate and they have no real bonding or association. About the closest that they get is strong type checking, but even then you could just do a cast.

2. For functional (which has nothing to do with f(x) type thinking really) programming you have to grok the idea that the program is allowed, nay encouraged to write itself. In this model there is little or no concept of data/code being seperate, and often the data the program is working on IS code that the program will soon use.

3. OO programming usually is basically imperative with a slant. In this case its not so much a matter that 'this data is mine and not yours' etc (after all OO does not preclude passing data around), but that procedures are STRONGLY associated with the data they manipulate. This means that all of the subs that manipulate a given data structure are bundled up into a nice package together with the definition of the data structures they manipulate. As an added bonus we get ideas like dispatch tables (VMT) and polymorphism. (My personal theory is that OO only got big becuase of programming in a GUI enviornment. So many details to keep track of in a window, so how to organize the data.) OO was in fact called modular prorgamming before it was known as OO.

So Perl is all three. We can use eval and closures (whose idea is taken from one the granddaddy of programming languages, the functional language LISP). We can write clases and we can write simple one liners. About the only thing that perl doesnt do is what you call Logical Programming. I believe originally these were called production systems. (which means something else nowadays :-)

Ultimately one can prove that all problems solveable on any digital computer (Automatic Interpreted Formal System) and that means in any languge, can be solved on a large enough version of a Turing machine (a typewriter with a scanner and a very very long tape) given sufficient tape and time. This is called the universal computer proof, and is related to the halting problem (chruch goedle turing thesis, church was one of the brainchilds behind rule based systems, goedle (sp?) the mathematician and Turing, one of the founding members of modern comp sci. (he cracked the Enigma using one of the first computers in WWII).

The point being that it doesnt really matter which one you use on the level of the solution, but it matters a great deal when you consider the method of development. OO seems to scale quite well, Imperative seems to excel in small projects, and functional has a way of surprising people with the types of problems that it makes easy. Production systems usually dont show up too much in written code.

The other reason why you are not getting the big deal is cause the wonderul people that have been working on perl have come up with an excellent blend, strong, not too heavy and very sweet indeed!

Anyway, just remember that functional programming is not about 'writing a function for each type of packet' but rather writing a routine (sub or function, perl doesnt care) that on the basis of the types of packets it recieves creates a new class for each on the fly and then executes those classes. Which is all three at once, and is one of many reasons why perl kicks serious ass!

Yves
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

She also said Perl was interpreted, and not compiled. Although she did kind of admit it was a hybrid. But the sounded very strongly like she believed it was strictly interpreted.

_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

Hey japhy.

Its too bad you didnt bring up closures. Thats about the best example I can think of in perl. Grep and map, while very cool and useful are basically just for loops so to me they dont count that much (even though the idea has a functional origin)

She also said Perl was interpreted, and not compiled.
Yes the old interpreted versus compiled debate. You really could have nailed her by pointing out what I said earlier "all digital computer are technically Automated Interpreted Formal Systems" which mean no matter how you look at it ultimately the code gets interpreted.

I kinda hate that debate actually, cause so often the lines get blurred. For instance if a c program has a regex engine then some part of the c programs code gets compiled then interpreted... Nightmare.

add to the fact that languages that have some form of interpretation are usually so much more fun to program...

:-)
Yves

It's somewhat a matter of degree. Ask a C programmer if Lisp is a functional language and he'll probably say "yes" (if he knows what a functional language is :-) Ask a hardcore Haskell programmer, and you might well get the answer "no". One might think of Perl similarly.

I think it's doubtful that you're going to get a good answer that doesn't involve the advice "study functional programming for yourself". Program a little bit in a language that makes it impossible or at least hard to program imperatively (e.g. Haskell or ML). Read some books that emphasize functional programming, like pretty much any language primer for the aforementioned languages, the classic Structure and Interpretation of Computer Programs, and Purely Functional Data Structures. The light may or may not click on, but that's probably the best way to try. No royal road and all that...

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 &amp;...) 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...

The encouragement of OO code abstraction ensures and enforces code reuse, and ease of refactoring, If it were not for these factors I would agree that it offered very little enhancement over procedural programming.