I want to present a rather unusual perspective on programming paradigms. So far, we have three major paradigms: So far, we have three major paradigms: Structured Programming,
Object-Oriented Programming, and
Functional Programming. Structured Programming, Object-Oriented Programming, and Functional Programming. Programming Paradigms are fundamental ways of structuring code. They tell you what structures to use and, more importantly, what to avoid. Instead of giving you more power, they set limits by adding rules for how your code should be written. what to avoid Also, there will probably never be a fourth paradigm. I’ll explain why in this article, strap in! Structured Programming In the early days of programming, Edsger Dijkstra recognized a fundamental problem: programming is hard, and programmers don't do it very well. Programs would grow in complexity and become a big mess, impossible to manage. Edsger Dijkstra programming is hard, and programmers don't do it very well. Programs would grow in complexity and become a big mess, impossible to manage So he proposed applying the mathematical discipline of proof. This means: Start with small units that you can prove to be correct.
Use these units to glue together a bigger unit. Since the small units are proven correct, the bigger unit is correct too (if done right). Start with small units that you can prove to be correct. Use these units to glue together a bigger unit. Since the small units are proven correct, the bigger unit is correct too (if done right). His system was similar to modularizing your code, making it DRY (don't repeat yourself). But with "mathematical proof". Now the key part: Dijkstra noticed that certain uses of goto statements make this decomposition very difficult. Other uses of goto, however, did not. And these latter gotos basically just map to structures like if/then/else and do/while. goto goto goto if/then/else do/while So he proposed the removal the first type of goto, the bad type. Or even better: remove goto entirely and introduce if/then/else and do/while. This is structured programming. goto goto if/then/else do/while This is structured programming. That's really all it is. And he was right about goto being harmful, so his proposal "won" over time. Of course, actual mathematical proofs never became a thing, but his proposal of what we now call structured programming succeeded. goto In Short Mp goto, only if/then/else and do/while = Structured Programming goto if/then/else do/while So yes, structured programming does not bestow devs with new power, it removes power. Object-Oriented Programming (OOP) OOP basically involves moving the function call stack frame to a heap. By doing this, local variables declared by a function can exist long after the function is returned. The function becomes a constructor for a class, the local variables become instance variables, and the nested functions become methods. This is OOP. Now, OOP is often associated with "modeling the real world" or the trio of encapsulation, inheritance, and polymorphism, but all of that was possible before. The biggest power of OOP is arguably polymorphism. It allows dependency version, plugin architecture, and more. However, OOP did not invent this, as we will see in a second. Polymorphism in C As promised, here is an example of how polymorphism was achieved before OOP was a thing. C programmers used techniques like function pointers to achieve similar results. See a simplified example below. Scenario: We want to process different kinds of data packets received over a network. Each packet type requires a specific processing function, but we want a generic way to handle any incoming packet. Scenario: We want to process different kinds of data packets received over a network. Each packet type requires a specific processing function, but we want a generic way to handle any incoming packet. // Define the function pointer type for processing any packet
typedef void (_process_func_ptr)(void_ packet_data); // Define the function pointer type for processing any packet
typedef void (_process_func_ptr)(void_ packet_data); // Generic header includes a pointer to the specific processor
typedef struct {
    int packet_type;
    int packet_length;
    process_func_ptr process; // Pointer to the specific function
    void* data; // Pointer to the actual packet data
} GenericPacket; // Generic header includes a pointer to the specific processor
typedef struct {
    int packet_type;
    int packet_length;
    process_func_ptr process; // Pointer to the specific function
    void* data; // Pointer to the actual packet data
} GenericPacket; When we receive and identify a specific packet type, say an AuthPacket, we would create a GenericPacket instance and set its process pointer to the address of the process_auth function, and data to point to the actual AuthPacket data: // Specific packet data structure
typedef struct { ... authentication fields... } AuthPacketData;

// Specific processing function
void process_auth(void* packet_data) {
    AuthPacketData* auth_data = (AuthPacketData\*)packet_data;
    // ... process authentication data ...
    printf("Processing Auth Packet\n");
}

// ... elsewhere, when an auth packet arrives ...
AuthPacketData specific_auth_data; // Assume this is filled
GenericPacket incoming_packet;
incoming_packet.packet_type = AUTH_TYPE;
incoming_packet.packet_length = sizeof(AuthPacketData);
incoming_packet.process = process_auth; // Point to the correct function
incoming_packet.data = &specific_auth_data; // Specific packet data structure
typedef struct { ... authentication fields... } AuthPacketData;

// Specific processing function
void process_auth(void* packet_data) {
    AuthPacketData* auth_data = (AuthPacketData\*)packet_data;
    // ... process authentication data ...
    printf("Processing Auth Packet\n");
}

// ... elsewhere, when an auth packet arrives ...
AuthPacketData specific_auth_data; // Assume this is filled
GenericPacket incoming_packet;
incoming_packet.packet_type = AUTH_TYPE;
incoming_packet.packet_length = sizeof(AuthPacketData);
incoming_packet.process = process_auth; // Point to the correct function
incoming_packet.data = &specific_auth_data; Now, a generic handling loop could simply call the function pointer stored within the GenericPacket: void handle_incoming(GenericPacket\* packet) {
    // Polymorphic call: executes the function pointed to by 'process'
    packet->process(packet->data);
}

// ... calling the generic handler ...
handle_incoming(&incoming_packet); // This will call process_auth void handle_incoming(GenericPacket\* packet) {
    // Polymorphic call: executes the function pointed to by 'process'
    packet->process(packet->data);
}

// ... calling the generic handler ...
handle_incoming(&incoming_packet); // This will call process_auth If the next packet were a DataPacket, we'd initialize a GenericPacket with its process pointer set to process_data, and handle_incoming would execute process_data instead, despite the call looking identical (packet->process(packet->data)). The behavior changes based on the function pointer assigned, which depends on the type of packet being handled. packet->process(packet->data) This way of achieving polymorphic behavior is also used for IO device independence and many other things. Why is OO still Beneficial? While C, for example, can achieve polymorphism, it requires careful manual setup, and you need to adhere to conventions. It's error-prone. OOP languages like Java or C# didn't invent polymorphism, but they formalized and automated this pattern. Features like virtual functions, inheritance, and interfaces handle the underlying function pointer management (like vtables) automatically. So all the aforementioned negatives are gone. You even get type safety. In Short OOP did not invent polymorphism (or inheritance or encapsulation). It just created an easy and safe way for us to do it and restricts devs to use that way. So again, devs did not gain new power by OOP. Their power was restricted by OOP. Functional Programming (FP) FP is all about immutability. You can not change the value of a variable. Ever. So the state isn't modified; a new state is created. Think about it: What causes most concurrency bugs? Race conditions, deadlocks, concurrent update issues? They all stem from multiple threads trying to change the same piece of data at the same time. If data never changes, those problems vanish. And this is what FP is about. Is Pure Immutability Practical? There are some purely functional languages like Haskell and Lisp, but most languages now are not purely functional. They just incorporate FP ideas, for example: Java has final variables and immutable record types,
TypeScript: readonly modifiers, strict null checks,
Rust: Variables are immutable by default (let), requires mut for mutability,
Kotlin has val (immutable) vs. var (mutable) and immutable collections by default. Java has final variables and immutable record types, TypeScript: readonly modifiers, strict null checks, Rust: Variables are immutable by default (let), requires mut for mutability, Kotlin has val (immutable) vs. var (mutable) and immutable collections by default. Architectural Impact Immutability makes the state much easier for the reasons mentioned. Patterns like Event Sourcing, where you store a sequence of events (immutable facts) rather than mutable state, are directly inspired by FP principles. In Short In FP, you cannot change the value of a variable. Again, the developer is being restricted. Summary The pattern is clear. Programming paradigms restrict devs: Structured: Took away goto.
OOP: Took away raw function pointers.
Functional: Took away unrestricted assignment. Structured: Took away goto. Structured goto OOP: Took away raw function pointers. OOP Functional: Took away unrestricted assignment. Functional Paradigms tell us what not to do. Or, differently put, we've learned over the last 50 years that programming freedom can be dangerous. Constraints make us build better systems. So, back to my original claim that there will be no fourth paradigm. What more than goto, function pointers and assignments do you want to take away...? Also, all these paradigms were discovered between 1950 and 1970, strengthening my theory that we’ll probably not see a fourth one. goto

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Programming Paradigms: All the Things We’ve Learned Not To Do

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

10 Expert Tips for Improving Code Reviews: A Guide for Developers

10 Coding Hacks to Remember in 2023

12 Essential Coding Standards for Quality Web Development

13 Tips on Writing Powerful Test Cases That You Need to Know

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

10 Expert Tips for Improving Code Reviews: A Guide for Developers

10 Coding Hacks to Remember in 2023

12 Essential Coding Standards for Quality Web Development

13 Tips on Writing Powerful Test Cases That You Need to Know

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps