When To Use What Paradigm

Under what circumstances do specific ProgrammingParadigms shine or not shine?

Object Oriented:

Manipulating/coordinating physical devices or low-level services based around standardized, slow-changing protocols. For example, access to the file system, networking protocols, etc. It is especially useful if one wishes to enforce static type checking for such services.
Physical modeling in order to study or emulate a process rather than replace it.
Building GUI components (but not necessarily GUI frameworks)
Large and/or distributed systems
- Disputed by some, see below
Programs which use individual state variables primarily as components of a larger abstraction rather than individual data points {Not clear whether this issue is an internal design decision or part of the external requirements}
Programs in which complex data aggregates need to be handled as atomic units {example? -- Hospital systems? Computer games?}

Logical/Functional:

Code consisting largely of mathematical transformations
- But perhaps all code can be turned into math if one knows how and/or works hard enough at it.
When code needs to be provably correct (lack of side effects aids this)
- consider DeclarativeDeviceDrivers
When code needs to be AsFastAsCee, and still remain readable/elegant (most of the few high level languages which can be compiled as fast as C are functional or functional-based languages).
Large and/or distributed systems
- lack of side effects allows local changes to be truly local

Procedural:

GlueLanguages
EventDrivenProgramming (at least from the domain logic side)

Regardless of which paradigm you use... you'll probably also end up using the following in conjunction with a programming paradigm. Every paradigm can make use of databases, but databases themselves are not a paradigm.

Databases (including but not limited to RelationalDatabases)

Need to perform efficient AdHocQueries
When multiple users/languages/applications need to see/use/modify the same information from different perspectives
When you need AtomicConsistentIsolated or AtomicConsistentIsolatedDurable semantics
When you have very large volumes of persistent data; which may outlive any particular application.
When the data itself is the focus of the program, rather than a representation of a larger abstraction

To some extent, database issues overlap with CollectionOrientedProgramming. Assuming COP deserves it's own "paradigm" (a LaynesLaw debate?), here are perhaps some of situations where they shine:

Dealing mostly with large collections of simple items or attributes
The individual items/cells/records are fairly uniform

Not sure if I agree with that. Data modeling and OO design tend to overlap. If the "noun model" is in both the database design and class structure, we have a violation of OnceAndOnlyOnce to some extent. In short, the issue of where the "noun model" goes is debatable and perhaps not orthogonal. (There used to be a topic dedicated to this, but it was deleted IIRC.) [Perhaps this discussion should be moved below, outside of the summary list.]

[It doesn't matter if you agree or not, databases are not a programming paradigm, the other three are, and they can all make use of databases. To the extent that OO may take on some of what you consider to be the database's responsibility, does not add any capabilities to a database that make them a programming paradigm. (Eh?) Databases are programs, paradigms are methodologies used to write programs, it's apples and oranges. To put it bluntly... you could write a database using any of the listed paradigms, but you can't write a paradigm using a database. How about Sesame Street style for you, functional/OO/procedural/database.... which one of these things is not like the other?]

This is of course true in the sense that SQL is not TuringEquivalent, but it is not the whole truth, because solving problems relationally really does require thinking in a different way. I think it would be more accurate to say that it is indeed an alternate paradigm, but not as powerful and complete as the pure-functional, OO, and procedural paradigms.
- How are you measuring "powerful"? It is not meant to do everything, but what it does it does well. It can do a lot of tasks with less code than the equivalent direct coding would take. It is a similar issue to addressing whether using regular expressions is programming or not.
- All of that is true. I meant it in a very matter of fact sense, not as an attack. If SQL had been extended to be a full-fledged programming language, no doubt it would look like COBOL; we're better off with the current situation.
- SQL is hardly the best possible relational language. However, why does a language/technique have to be all-or-nothing with regard to what problems it solves? It is a matter of how one goes about DivideAndConquer.
(There's more to it than that, actually; you can make SQL Turing Equivalent just by putting the right list of SQL commands in the midst of an infinite loop, but for practical purposes that still isn't expressive enough. SQL is also lacking expressive power in terms of full-fledged arithmetic and unbounded recursive facilities.)

[SQL, as a language, can be considered logical/functional, thus it's not a new paradigm and Turing Equivalence has nothing to do with that. Relational Algebra isn't a paradigm either, it would also fall under logical/functional, unless we want to start calling every different algebra/calculus a paradigm. Is lambda calculus now a paradigm too? NO... all the math's are going to be logical/functional, none are their own paradigms.]

For one thing, it's completely unclear what you mean by the math being the same. Either you're saying that essentially all math can be applied to use of any language, which is true but uninteresting, or you are saying that exactly the same branches of math are equally applicable to analyzing/synthesizing programs written in any language, which is clearly false.

[I meant neither; maybe I was unclear. Lambda calculus is not a paradigm, relational algebra is not a paradigm, both "maths" are different ways of thinking, but both already fall under the logical/functional paradigm. SQL is a logical/functional language, you say what you want, the runtime figures out the best way to get it. My point is, there is no relational paradigm since relational algebra is already part of the logical/functional paradigm.]

[If the maths are "different ways of thinking", I'd hardly call them the same paradigm. Be careful about lumping logical/functional together; the two require different ways of thinking. Functional programming relies on compositions of functions, while logical programming relies on composition of predicates (by contrast, OO is programming through composition of objects, and procedural is programming through composition of statements). The RelationalAlgebra as described in TheThirdManifesto could be considered logic programming, but SQL neither conforms to the relational algebra nor is a "logic programming language". It does, however, fit under the declarative paradigm, which could be viewed as a superset of both logical and functional programming (and more; HTML is a declarative language). I would consider relational to be its own paradigm, though, as you program through composition of relations. -- JonathanTang]

But in any case, it's not necessarily required to be talking about a different branch of math in order to have a new paradigm. The word, after all, was popularized in The Structure of Scientific Revolutions, wherein it is very clear that he wasn't talking about one branch of math versus another, he was talking about something closer to mental models.

It is quite well known that one needs to learn a different approach to languages with different paradigms. Programming proficiently in Lisp is different than in APL is different than in Haskell, whereas the paradigms for e.g. C and Pascal strongly (but not completely) overlap.

And in this sense, it is well known that being a good programmer in any of those other languages is not completely adequate for preparing someone to be really good at writing SQL queries (or vice versa); a different mindset is required. That's what makes it a different paradigm.

(moved from OoIsJustGoodEngineering)

It doesn't have to surpass the alternatives. OO is a tool, and like any tool, it's useful in certain circumstances. You don't say a hammer is useless because there're no objective studies saying it's better than a screwdriver - it just needs to be better at dealing with nails. Similarly, I've found OO useful in a fairly large set of circumstances - whenever there's a natural categorization hierarchy, or when you need a set of tasks to conform to a certain interface - and so it's useful to me. If a problem calls for a relational database, I use one, and if it can be solved with pure procedural programming, I do that. Neither case means that OO is useless. -- JonathanTang

Being a non-OO fan, I guess I can generally agree with this. The one exception is the "fairly large set of circumstances". A "natural categorization hierarchy" is rather rare. There are many LimitsOfHierarchies WRT the real world.

Can we burn down this StrawMan? Just because some OO languages are limited to tree-like inheritance hierarchies (languages with StaticTyping and without MultipleInheritance mainly), this is not a problem in general with OO.

The comment was addressing the "a natural categorization hierarchy" comment above it, and not meant to imply that all OO must be hierarchical.

I don't consider looking at OO as hierarchy-driven as a StrawMan. Restricting any argument against OO to single inheritance is justified by, among other things, the fact that the latest and most widely used OO languages ditch the concept of MultipleInheritance. This is true of Java and C#. An even better justification, in my mind, is the fact that OO education and the resulting thought processes are typically hierarchical. Consider the cannonical circle / triangle / square / shape example so often presented to students of OO. The fact that more and more CS education is being done in Java, of course, restricts education to single inheritance. The obvious response to my line of argument here is that OO is not defined by its application or mis-application. It's a concept in its own right independent of what the flavor-of-the-month happens to be. But I disagree with that counterargument in a fundamental way. My feeling is that just about any paradigm for development could produce good results if applied by someone sufficiently knowledgeable. The more relevant question, I think, is "what sort of output and practices are encouraged by this paradigm?" and I think it's on those grounds that OO can be said to be hierarchical. -- BeauWilkinson

Similarly, IMO relational shines where many different users will need multiple viewpoints and abstractions of the same information. This may not apply to things like communications components because we are not supposed to see the "state" from any viewpoint other than the protocol defines, because the implementation may change. The protocol forces one to view the state only from a predefined interface.

I have been trying to sort out the great object debate for a while now, with little success. But as you should PickTheRightToolForTheJob, I think that this page makes more sense than the endless war that I have seen so far.

I don't really have much experience with non-OO languages, so I won't try to give criteria for when to use them. However, I definitely believe that there are certain types of problems which are solved better in a non-OO language.

But from my experience I can hardly imagine an easier way to model a complex system, especially a distributed one, without objects. Even if I were to use some other language to do a bit of functionality, I can guarantee you I would end up wrapping it to use it as a piece of a larger system.

Another thing I really appreciate about OO development in it's present stage is the automatic function/parameter lookups and the great GUI interface design. (As far as I'm concerned, the ease that the development environment imparts to development can be as important as the 'perfectness' of the language.)

Is it hard? Yes, sometimes. But the nice thing about OO from my point of view is that it so nicely models the types of behavior you may wish your system to have.

I would like to see more comparative justification of this claim. I am skeptical.

The complexity is why you have to make sure to follow sound development principles (such as those found in XP). But the things you are trying to model ARE complex, so I don't have a problem with having a more complex language.

One last thing: I have been reading the huge debates about Relational vs. Object Oriented. Although I have felt a bit of ObjectRelationalImpedanceMismatch myself (read: "my first attempts were not that successful") I have also seen that, with a few nicely abstracted classes and the use of SQL (e.g. ADO.NET), it is not that hard to represent a relational database as objects. Now, I admit that it's a minor hassle to write objects which can represent specific records and tables, but the benefits of having type-checking and automatic completion for manipulating database records are well worth it to me. (If you didn't want that you wouldn't have to even implement specific objects.)

{As far as IDE gizmos like auto-completion, if another paradigm was around a while, IDE's would start to have nice gizmos for them to. As far as type-checking, see below.}

I have even gotten to the point that I would hardly want to write anything other than a trivial application without a database.

But, I can think of no circumstances in which I would want to abandon an object-oriented approach to developing a whole system just because certain non-OO concepts/languages may be more appropriate for a particular subcomponent. Is anyone familiar with such circumstances?

-- DaveHoehn

OO may be okay for access to external services such as networking, files, etc., but I would like to see how it improves "business modeling", AKA the domain itself. If you are suggesting that we should use an OO-enabled language for access to those external services, then I guess I can concur. -- AnonymousDonor

Type Checking

Some enjoy the strong type-checking of OO languages and OO-tized data. I don't know yet how to reconcile the desire for strong type-checking and databases because I am a fan of dynamic/weak typing and don't think much about heavy type-checking. Databases have the premise that data is shared with multiple languages and tools. Thus, they cannot be too connected with the type system of any one language. However, the possibility of a compiler checking internal types against database types and schemas certainly seems valid. Sharing info with multiple languages is generally going to trigger similar issues. One of the reasons I like low typing is that it reduces the to-and-from conversion layers between languages. Text is the closest thing to a universal "type".

re: OO for large and/or distributed systems

First off is the problem of measuring/determining a large system because the borders are usually fuzzy (see SystemSizeMetrics). I tend to avoid writing "large systems" by letting the database(s) be the primary messaging system connecting many smaller applications or tasks. DivideAndConquer. One-big-exe is a design smell in my opinion. As far as "distributed", I would like to see a bit more info on that. (DistributedProgramming)

By distributed I mean a system where parts of the system communicate with other parts of the system which reside on (possibly) separate computers. So, perhaps I have 4 computers which all are providing functionality which makes up the system. Regardless of the protocols which I use to connect the computers, I'm going to provide an interface which allows me to treat the remote systems as if they were local objects by implementing a shallow interface which just mirrors that of the subsystem. Then, in whatever OO language I choose, I make the wrapper interface, and use that subsystem as if it were any other part of my system.

I would be interested to hear what exactly you mean by avoiding "large systems." If you have lots of interacting pieces it's a large system regardless of whether you use the database to message or whether you have one-big-exe or thirty-little-exes. If the thirty little exes are indeed independent of one another, perhaps it's not a large system, but thirty little ones. I will try to think more on this later. -- DaveHoehn

An extreme example is perhaps certain web-based "applications". They may have hundreds of screens/forms/pages and thousands of users, yet they are composed of a bunch of relatively independent "scripts" that communicate mostly through a database and web parameters. See SystemSizeMetrics.

re: OO for GUI design and implementation

In my opinion GUI layouts should mostly be in data or meta-data. That way multiple languages and tools can share the layouts. I see no reason why GUI tools should be locked to any one language, except maybe for speed. But as time goes on that is less and less of a factor except maybe in entertainment games. The rules and expectations of GUI's hasn't changed that much in the last 10 years, thus there is no race against MooresLaw (unless something really different comes along). Cross-platform standardization (or semi-standardization) is the main reason HTML-based interfaces are so popular. What is lacking is an accepted HTTP-friendly GUI protocol designed for business forms instead of e-brochures. See RemoteGuiProtocols.

I'm not sure I really understand what you mean. Aren't GUI's inherently very OO? I mean, regardless of how you store the data for the individual GUI elements, doesn't it all eventually get translated somewhere that the user interacts with it as an object? So, maybe your OK button gets its text from the DB, and even maybe what event gets generated when you click it, but doesn't it all boil down to an button object somewhere which responds to being clicked? -- DaveHoehn

Verbs have been happening to nouns in computers long before OO. If you call everything an object, then everything is OO by definition. Such truisms don't help us here. Besides, you are kind of anthropormorphizing the button in a way that is not actually part of the software.

I didn't intend it to be a truism; I just thought that by its nature a GUI is object-oriented. Perhaps it is because I am not familiar with how GUIs are built without OO; would you mind giving a quick explanation on how to implement a GUI without objects? -- DH

Any algorithm at all can be done either in an OO way or in a non-OO way; why would you think GUIs are any different? That's like saying, please give an example of how to compute a square root without objects. It'd be easier to give an appropriate example if you would explain how your misconception works. Anything can be viewed as an object, but that doesn't mean that anything at all must be viewed as an object. -- dm

[A gui construct is a collection of behaviors and data. Like a button - it has specific behaviors (what it does when pressed, when you mouse over, etc), and specific data (like it's position, it's pressed/unpressed state, it's label, etc). The rest of a gui system is similar. It lends itself very naturally to OO thinking and methodology and I'm not aware of any gui system that isn't OO in this respect. Gtk is. Motif is. The Win32 API (with regards to the GUI) is. Even VB, if you create your forms programatically rather than using the designer, is. If you DO use the designer, then it's component based.

How would you implement a GUI framework without a concept of objects, even if they're just CeeLanguage style "objects as structs"? GUI is inherently OO in much the same way it's inherently event based - it's the most obvious and natural way to represent the real world behavior.]

NonOopGuiMethodologies, TooMuchGuiCode

[See if you can dig up some old Macintosh code. They copied the GUI ideas developed at Xerox PARC, but they didn't copy the OO ideas used to implement them. The result was pretty ugly by today's standards.]

Old Macintosh code was written in 68k assembly; doing OO in that would be a significant exercise in GreenSpunning...

As far as what to build the GUI engine (browser) itself with, I don't necessarily dispute that because I don't have enough experience in that domain. Thus, I generally don't dispute that "device drivers" allegation of OO, and a browser off of a standard protocol is a kind of device driver. If the interfaces between "instances" of drivers is generally stable, then polymorphism might actually work nearly as clean as the TextbookOo. -- top

I am of the opinion that the set of programming tasks that can be solved by any paradigm, neatly, is rather large. Sure, there are examples of things which are clearly improved by a specific paradigm (or even language) but a lot you can do any way you like without ending up with a mess. What style you use for programming anything in this set is an artistic rather than scientific choice (or possibly not open as a choice at all for commercial reasons i.e. your team only know language foo, your company only has compiler bar). I am inclined to agree with whoever wrote that programming has more to do with journalism than science or engineering, although I might change journalism to be writing in general. -- JamesKeogh

CategoryMultiparadigm