Which programming paradigm had the most impact on you as an engineer and why?

Anti-service oriented architecture: continually asking myself in what way could I solve a problem with less complexity, fewer dependencies, and permitting shitty solutions as long as they are vaguely adequate to customer need.

Functional programming. I learned OOP in school, and always thought it overcomplicates things, why can't this comparison operator in one page of Java just be a function, I thought. How can you make the state of objects manageable, especially if it's private, how do you test, without opening up too much of the API, couldn't we just make this a set of functions with an explicit state so it's easier to understand? How do people understand a method that is spread over a hierarchy of 15 layers of inheritance.

For years I thought there must be something I don't grok about OOP. Some point where these design patterns click and make sense. Until I set out to learn OCaml, switched to F# because I was on Windows, and found https://fsharpforfunandprofit.com. All these concepts had really foreign sounding names, but they clicked right away. I finally found that there are people that think like me.

I'm happy functional programming is slowly taking off, influencing almost every modern language. So I guess I should have just trusted my intuition.

YAGNI, unlearning OOP, embracing simple languages, accepting that the requirements/hypotheses about external world is the most important signal.

Before: I was endlessly creating useless abstractions and going for cute and "elegant".

After: Simplest possible code.

The downsides:

1) One has to know good code from bad to evaluate if "simplest possible code" is not too simplistic and won't cause you problems a month, a year or 5 years later;

2) One is always bombarded by the "cute", "elegant", or plain meandering and unclear code. Unless one is at the top of technical peeking order of the company all the attempts to keep sanity will be in vain.

'Fail early' and 'throw exceptions in exceptional circumstances'. You need good top level error handling and logging of course. I still work with engineers that try catch exceptions and return some sort of more 'graceful' error, for problems that can't really be handled in any other way but to let the system fail. This practice makes it clear when problems arise and where they come from.

Minimizing and isolating state. Not eliminating it, keeping state is often useful, but not everything needs statefulness, and keeping track of state is _hard_ (hi yes I'm backend, have fun FE folk). The loose pillar of functional programming to keep state and behavior separate means that the problem space for objects and functions goes down quite a bit, and reasoning about things becomes much easier.

I don't think it'd be anything you could obviously point at in my code, but it's a day-to-day consideration that I have.

Not so much a paradigm, but learning TDD from the engineers at Pivotal Labs really changed the way I approach problems.

I spent a few weeks constantly pairing and doing TDD with them, and while I don't think I could pair forever (maybe 2 days/week), I was amazed at how TDD could shift my approach to a problem. These days I'll still use it, even on personal projects (usually only integration tests), as a great way to reduce unnecessary complexity and increase my confidence in my own code.

Functional programming without a doubt.

And everything that elixir and Erlang drags along with it.

Nothing comes close as yet in terms of what one can do this this.

Focus on risky/unknown parts of a project first, don’t start with what you already know/can do.

And many more from the excellent book “The Pragmatic Programmer”.

procedural programming (is it data or is it code, it can’t be both)

and data oriented design with SOA and deferred buffering

for games at least code needs to be highly cache friendly and dumping OOP makes it way easier to reason about program state and code flow

Fail fast. Adding assertions everywhere helped me write software which does less unexpected stuff and is more reliable.

Functional programming, the idea of state machines and finally how Rust extends structs with functionality. Also experiencing an overengineered internal system that was microserviced, really made me reconsider the whole "microservices are epic" mantra. 'Cause, oh boy was that annoying and difficult to debug.

When I learned functional programming, in my head, classes suddenly became slightly worse versions of partially applied functions.

When I learned about state machines classes also now seems like a failed attempt at achieving the same thing.

Pure functions. It totally changed my game when I realised that state was "evil" and that it should be treated like the dirty little possum that it is.

The whole functional programming paradigm made a big change for me. Coming from the 90s you know, we were fed Object Oriented paradigm down the throat up to mid-2000s. If you didn't do OO on your resume, no point applying.

Then slowly the whole industry started looking at global state and considered any kind of shared state bug-prone (which it is). So Object Oriented took a big hit in the face. It wasn't the dream of reusability we were sold.

Some went ape in the functional direction and became obsessed with it. Some like me went into a more pragmatic understanding of what state is and how to keep as simple and compartmentalised as possible. So we still use OO in parts, completely avoiding inheritance if possible, using composable objects instead, with pure functions. That's another big shift I took from game development: choose composition over inheritance.

Code layout-wise, we went from hellish nightmare, to MVC, to MVP (presenters) and finally MVVM (thanks Silverlight).

Then came the reactive UIs. That's also been a big shift, but in the same direction. State is state, and the UI flows from there. As long as you don't get into a spaghetti fest of system-wide events, you're probably going to be OK.

I think we're becoming closer and closer to Model - View, with a bunch of render methods and utility methods on the side.

I'm not sure what the "next" thing is, but we seem to start to have this whole UI thing finally under control. Except tailwind, anyone in their right mind needs to see what a clusterf that is. There definitely needs to be more work done on the design-systems and CSS frameworks side, it still feels like cowboys and indians in this age. You'll see, in a year or two, a monolithic CSS will make a come back, probably partially server rendered. Anyway, this is only for the web.

As for the native stuff, I'm really digging the SwiftUI thing. It took them a while, but it's undeniably amazing to be dealing with a language that is both a rendering DSL and a statically strongly compiled language close to Rust, but very terse. If only they could fix the compiler errors... I could finally drop my deck of tarot cards.

But as far as impressive language goes, I have to give it to Swift now. As a polyglot of most (yes most) languages, Swift takes the cake. Sadly it's biased...

So to sum up? Pure functions, composition over inheritance, reactive rendering, strongly-statically type languages used for both rendering/logic that are as powerful as Rust and as terse as Python.

Beyond functional programming as shared by other people on this thread, the programming style that has most affected me was separating major layers of a SW stack - in particular, the data model, the business logic and presentation.

This sounds kind of trivial, but it entails three very useful techniques:

0. Passing strictly typed immutable data structures (i.e., DTOs) that formalize and enforce the pre- and post- conditions at each such layer of the code;

1. Dependency injecting useful resources, as opposed to keeping them inside god objects/"managers";

2. Allowing each layer to use a different programming style, quality bar, logistics etc.

One caveat: I don't think that modularizing code causes it to require fewer changes when introducing new behaviors. For example, if you add a new data field, you'll have to go through all layers. However it definitely can make each of the piecemeal changes quicker and cheaper.

Got to be MVC right?

Put the data all the way over there. Put the view all the way on the other side over there. And then start tying it togther in the middle. I was pretty young when I learnt about it, but it's been by far the most influential on me.

Also I'm not sure if this is a programming paradigm, or just good practice, but strongly typed parameters + throwing errors if they're not the right type. I thought TypeScript was the bees knees when it came along.

Perhaps the single responsibility principle. Before that, it was always hard to decide on a good point between either everything being a single compact block of code doing everything, or the other extreme of everything being separated out to many different abstractions and subsystems just for the sake of it, seemingly.

The single responsibility princible gives a good rule of thumb of why and where to split things up, and if you follow it, you will by design get a system which has about enough abstractions for change to be reasonably easy.

For me, more than any paradigms, the following outlooks were the most useful -

1. YAGNI - plan for the future if required but only implement once it arrives.

2. KISS - Keep things as simple as possible. For example, f you have to generate 50 forms for 50 different use cases, build 50 forms. Don't try to create a generic dynamic form.

3. Tests - Not necessarily TDD, but there should be tests for when you think your module / function has been done. This will ensure your edge cases are considered. Try NOT to fix a bug without adding to your tests.

Only paradigm isn’t enough. Language design, ecosystem and pragmatism is essential as well and Clojure has all that.

After a couple of years of writing Java in my late teen, early 20s, I observed considerable overhead and inefficiency while working on large Java projects.

I thought we shouldn’t have to recompile the whole project upon every single change.

Classes and private public fields, methods felt like they were solving the wrong problem.

Other fancy words, that contained fairly simple ideas, felt like the output of clever language designers who enjoy the sound of their voice.

Those were the issues I observed as a newbie, but still I started looking for alternatives and found Clojure fairly soon. Sense of satisfaction steadily grew as I dug deep into the language, it was addressing so many design decisions I questioned before. At some point I started re-writing core library and it was joy to see how simple a programming language can be.

I wrote software in many different programming languages over the years but writing Clojure at work is fun, multiplied.

Uncle Bob's "Extract Till You Drop" which suggests breaking down large chunks of code into multiple, single-task functions (i.e., when describing a function, you should rarely if ever be able to say it does this and this).

I went from creating messy, frustrating code to well-organized, easy to debug modules that (have) run w/o issue for years. At first it seemed like overkill, but the sheer speed of bug fixes 10x'd overnight for me. I haven't looked back in 5+ years.

I don't know if I can say.

A lot of things that have been mentioned like FP and TDD and whatever can bring new perspectives because they force you to break your existing programming patterns, but I also think that is the main benefit, not the paradigm itself. This is also the benefit from (the increasingly contentious) Clean Code. It's basically a bunch of rules that force you to break habits, even though it's easy to conflate that with benefits from the paradigm-change.

It's difficult to improve when you're basically just building the same program over and over. That's what I'll argue is the benefit from switching paradigms; you can't keep doing that, so you're nearly forced to learn new things.

The ability to freely mix programming paradigms and to bend the language towards the problem instead of the other way around. It's the thing that Common Lisp is kind of famous for.

Depending on the programming sub-sub-task that I'm working on right now, I can have simple state machines written with explicit GOTOs, algorithms working on immutable state and written in functional style, minor operations in these algorithms implemented with a functional shell but imperative core, the ability to do declarative programming and define my own syntax for the declarations while I'm at it, and the ability to always branch off to a task-specialized DSL whenever it brings direct benefits to the table.

I’ll actually list 3.

1 - Smalltalk. I’ve done Python, Kotlin, Swift, C++, and Objective-C, all in various forms of real production code. The kind of OOP you do in Smalltalk is not the same as you do in other “oop” languages, which are really just Algol dirivstives with some weak sauce OO smashed on top of them like lipstick on a pig.

2 - C actually. In particular, pointer rich C. Working in some domains where we did LOTs with pointers (vms and the like) gave me a practical understanding of the general computation model of Chios in general. After I worked with pointers a lot, assembler, though arcane, just suddenly clicked.

3 - Currently Elixir. It’s pragmatic approach to functional fascinates me. I don’t have to become a type theologian to participate. I just get to try and solve problems with function pipelines, ubiquitous immutability, no return statements and everything as an expression.

And though each of these paradigms is very different, they all have pushed my mind the most. It’s interesting that whole different, they’re each “simple” but powerful paradigms maxed out in the interest of consistency.

Definitely object oriented design, in a negative way. It taught me how I do not want to think about a computer system. All its ideas sound so neat and if you have a well designed system, which never needs to change, it might even work. But someday, somewhere you might realize that some functionality means none of your abstractions made any sense. The idea of combining functionality with state (classes) was definitely a useful one, but you shouldn't use a hammer as a screwdriver.

I have a lot of positive things to say about procedural programming. It is perhaps the easiest and most straightforward way to think about computation. The more abstract the problem gets the more I start to think about it in functional terms, it allows you to construct the flow of data in a very managable and efficient way.

Flow-based Programming, and Message Passing. Separation of implementation and composition.

State machines, I love how you can describe a problem with a nice diagram. They are used extensively where I work (embedded software).