Is there any difference between Structured and Procedural Paradigm

Many of the terms can be reused (often misused) about programming languages, especially those other than object oriented ones.

Here are some small descriptions of the terms.

1. Imperative programming - In good old days, when programming was broadly in assembly, code would have tons of GOTOs. Even higher level languages like FORTRAN and BASIC began using the same primitives. In this programming paradigm, the entire program is a single algorithm or complete functionality written linearly - step-by-step. This is imperative style. Understand that one can really write totally bad imperative work even in modern C language as well but it is quite easy to organize code in higher level languages.

2. Structured and Modular programming - Most often we should be able to use the term interchangeably but with subtle differences. When higher level languages begun to get richer, one realized that all units of work should be broken into smaller tractable parts - that is when functions came into existence and programming became a hierarchy of functions and many at lower level could be re-used.

   • Structured programming is any programming when functionality is divided into units like for loop, while loop, if... then etc block structure.
   • Also, here the a piece of code (function) can be re-used.
   • In modular programming, one can create a physical form of package - i.e. a chunk of code that can be shipped; which are fairly general purpose and re-usable. This is called modules of elements compiled together.
   • So one can hardly see modular programs which are not structured and vice versa; the technical definition is subtly different but mostly structured code can be made modular and other way.

3. Then came "object oriented programming" which is well defined in literature. Understand that object oriented programming is a form of structured programming by definition. The new name for all those function based code which is structured code but NOT object oriented is often called as Procedural programming.

   • So basically structured code where functions (or procedures) dominate over data is called procedural whereas class and object based representation is called object oriented. Both by definition are also modular.

Many people think - all of structured programming (maybe skipping Object based) as imperative programming; I guess this is only due to lack of clear definition of imperative programming - but it is wrong. You are doing structured programming when you are not doing much imperative ones! But I can still write a lot of functions as well as a lot of goto statements inside C or FORTRAN program to mixup.

To be specific to your questions:

First Question : Pure assembly language is imperative language which is NOT structured or procedural. (Having step by step interpretive control flow doesn't mean procedural - but division of functionality into functions is what makes a language procedural).

• correction * Most modern forms of assembly DO support the use of functions. In fact, everything that's possible in high level code HAS to exist low level to work. Although it's a far better practice to create procedural code, it's possible to write both procedural and imperative code. Unlike the latter, it's more maintainable and easier to understand (avoiding horrible spaghetti code). I think there are shell/bash scripts that better fit the accolade of being purely imperative, but even then, most have functions, developers definitely understand how much value they have.

Second Question : Procedural programming is a FORM of structured programming.

BONUS

• According to some taxonomy the primary classification is Declarative (or functional language) vs. Imperative. Declarative languages allow computation without describing its control flow whereas imperative is where explicit control flow (step-by-step) is defined. Based on this classification, Imperative programing, for some can be a super-set of structured, modular and OO programming. See this: Functional Programming vs. OOP

• After Object oriented, there have been other programming paradigms invented: See here for more details: What are the differences between aspect-oriented, subject-oriented, and role-oriented programming?

One can answer this by writing a book on this. However, here is a basic comparison

1. Subject oriented Programming

Subject-Oriented Programming is radical departure from the Object oriented as follows. In OO, objects are defined in terms of intrinsic (i.e. based on a model that independently describes it). and based on this its attributes (properties) and methods (behavior) are derived. The application makes only the use of these properties and behavior. Contrary to this, in subject oriented programming, no object exists (and modeled) in such an isolation. In the process, but behaviors of the objects is been provided by the various other "subjects” of the objects which are beyond the scope and control of the author of the original object. Think of it as a way of extending various "independently definable behaviors" on the object. I think this would be way beyond defining templates of inheritance compared to what is being discussed here.

The undisputed origin of terms (and concept) comes from the paper "Subject Oriented Programming: A Critique of Pure Objects, William Harrison and Harold Ossher". Here is another good paper. Though personally i believe this is a theoretical framework. I don't know if there are any languages/implementation

See this, this and this for more info.

2. Aspect Oriented Programming

Aspect oriented programming has originated from the concept of "Separation of oncerns". Basically it extends the either procedural or object oriented programming for concerns which are cross-cutting. Over simplifying one can say that software has functional requirements and non-functional ones. These cross cutting requirements includes examples like logging, exception handling, thread synchronization, memory management, optimization and so on. These cross cutting ASPECTS should be expressed and implemented separately and independently to any other functional parts.
A comprehensive work in this area is from IBM; basically each such concerns or aspects can be independent from each other forming multidimensional "concern space". , (read this).

Some of the good practical implementations of Aspect Oriented are AspectJ and AspectC++ and many more. See this.

3. Role Oriented Programing
As we evolve towards agents, many a times it is necessary to define "roles" and objectives where as exact activities that agent ends-up performing depends on the environment it is in. This is analogous to human conceptual understanding.

The primary objective is to decouple objective of task from it's co-operation capability by defining explicit construct called cooperation processes. A role is modeled as a set of the capabilities and an expected behavior. however, these approaches also allow modeling of the execution environment and how agent/object can perceive the environment as well. See this.

There are various frameworks proposed in the research for role based modeling and implementations. A few of them are ROPE, BRAIN, ALAADIN and more.