Although structured and object-oriented techniques account for a majority of the programs written today, these are not the only approaches to code.

Functional programming sounds a lot like procedural programming, but in reality it's quite different. Functional programming concentrates on the evaluation of expressions rather than the execution of commands. Functional languages include Lisp, Scheme, and ML. These languages and this style of programming are popular in some universities, but have not really caught on in the rest of the world. The primary uses of functional programming are in teaching and artificial intelligence.

In data flow programming, the key element is data that flows between functions. Flow of control is not precisely specified; only dependency relationships that specify which operations must complete before other operations must begin are specified. Data flow programming is in some sense orthogonal to OOP. Both techniques and styles can profitably be used in one language. Data flow programming hasn't caught on in a big way. Perhaps the most popular environment for it is Pictorius's Prograph.

Fourth-generation languages, of which the most popular is SQL (Structured Query Language), define the answer that's wanted rather than the method by which the answer is generated. For example, a typical fourth-generation language inquiry looks like this

SELECT LastName FROM SalesPeople 
WHERE Quota > 5000

You neither know nor care what data structure is used to store the information you're requesting. It could be an array. It could be a linked list. It could be a hash table. Similarly, you neither know nor care what algorithm is used to search that data structure for the requested information.

Finally, I feel compelled to mention that one of the most popular, if not always the most effective, approaches is the quick-and-dirty, anything-that-works nonmethodology.
This methodology is often identified by a lack of subroutines, functions, or classes; an almost complete lack of comments; flow control structures, especially goto, that spontaneously jump from place to place; and a general disdain for anything that might make the code more understandable.
A quick-and-dirty solution is often adequate for small problems, especially those that need to work only once, but programmers who attempt to scale this up to more complex problems rapidly discover the need for more formal approaches.