What is a Programming Paradigm?
A Programming Paradigm is just an approach to thinking about problems and solutions. Applying a particular paradigm limits the size of the solution space by providing a framework for thinking about problems.
The four major programming paradigms are listed here. Almost everyone starts off by learning the procedural paradigm, because it is more straight-forward in many ways than the others.
The OO paradigm has been the dominant paradigm for more than a decade now. The functional paradigm has been making a comeback thanks to problems with concurrency.
The logical paradigm is possibly the most abstract of the set.
Programming originally began with hardware and progressed to procedural proramming. It's relatively easy to reason about. Most programmers can pick it up much easier than the other paradigms.
On the other hand, there's less of a theoretical background for it. Originally, it was quite messy until refined with structured programming.
Many from the OO camp consider procedural programming to be old-fashioned and not capable of scaling to production environments. These people tend to forget how much of the world runs on procedural code.
The idea most people are taught about OO is that objects allow the code to more closely model the real world. Obviously, modeling the world with objects would result in solutions that are easier to understand. This promise has not actually been fullfilled.
The major real advantage of OO programming is the way it supports partitioning problems. This effect helps with construction of massive software projects using large numbers of developers. Some OO fans would suggest that large, complex systems cannot be built without an Object Oriented system.
The functional paradigm was born from research into an area of math called lambda calculus. Given the mathematical foundations of functional programming, it should not be surprising that there is a history of proving software correctness. This usually works with limited scope of programs.
With the new push towards more concurrency in programs, functional programming is making a comeback.
As far as I understand it, logic programming has been mostly used in artificial intelligence and, especially, expert systems. The only language I'm aware of that supported it directly is Prolog.
In addition to the major paradigms, there are a number of lesser ones as well. Some of these (like Generic and Aspect-Oriented) are normally associated with a major paradigm (OO in these cases). Others (like State-Oriented and Event Driven) are only minor because they tend to only be used in limited circumstances.
Developed in Ada and C++, generic programming attempts to reduce some of the redundancy caused by strong type checking. The approach is to allow constructing generic algorithms that can worm on any object that implements certain operations, not just subclasses of a given class.
Programs are defined as a series of states with transitions between states caused by incoming events. One major advantage of this approach is the ability to statically determine whether or not every combination of input and state is accounted for. This prevents ambiguous situations where an unexpected input cause the system to misbehave.
Perl does not enforce a particular paradigm. In fact, Perl allows relatively simple use of multiple paradigms in a single program.
Two of the examples you saw were actually multi-paradigm.
Technically, the OO example was mostly procedural and only used one object.
The functional example was not pure functional because the code had
side effects (reading a file and printing) and chomp
was used to
mutate $_
.
Fans of some paradigms are convinced theirs is the One, True Way to develop software.
Perl's slogan TIMTOWTDI shows some disdain for the one, true way approach to programming. This may be why Perl is often abused by people whose language of choice pushes a particular paradigm.
Answer: It depends.
Despite what people want you to believe each paradigm has strengths and weaknesses. In some cases, the procedural approach is perfect and OO is too heavyweight. In other cases, a predominantly object design is best. In most cases a combination of approaches is the perfect solution.
People to to use what they are comfortable with.
The only good examples I know are expert systems.
The real key is to add paradigms to your toolbox.