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)
In reply to Re: What's the big deal?
by demerphq
in thread What's the big deal?
by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |