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

Functional programming. I learned OOP in school, and always thought it overcomplicates things, why can&#x27;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&#x27;s private, how do you test, without opening up too much of the API, couldn&#x27;t we just make this a set of functions with an explicit state so it&#x27;s easier to understand? How do people understand a method that is spread over a hierarchy of 15 layers of inheritance.<p>For years I thought there must be something I don&#x27;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 <a href="https:&#x2F;&#x2F;fsharpforfunandprofit.com" rel="nofollow">https:&#x2F;&#x2F;fsharpforfunandprofit.com</a>. All these concepts had really foreign sounding names, but they clicked right away. I finally found that there are people that think like me.<p>I&#x27;m happy functional programming is slowly taking off, influencing almost every modern language. So I guess I should have just trusted my intuition.

I’ll actually list 3.<p>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.<p>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.<p>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.<p>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&#x27;t use a hammer as a screwdriver.<p>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.

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.

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.<p>This sounds kind of trivial, but it entails three very useful techniques:<p>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;<p>1. Dependency injecting useful resources, as opposed to keeping them inside god objects&#x2F;&quot;managers&quot;;<p>2. Allowing each layer to use a different programming style, quality bar, logistics etc.<p>One caveat: I don&#x27;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&#x27;ll have to go through all layers. However it definitely can make each of the piecemeal changes quicker and cheaper.

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&#x27;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.<p>I don&#x27;t think it&#x27;d be anything you could obviously point at in my code, but it&#x27;s a day-to-day consideration that I have.

Actor Model.<p>Go down the rabbit hole of the actor model &amp; eventual consistency, it will make you a better developer. After reading everything you can on the topic, there are a couple of frameworks that implement it (Orleans Framework &amp; Akka &amp; others). I think it will make a comeback as it is a natural fit for multicore cpu&#x27;s&#x2F;gpu&#x27;s.<p>It is also fairly easy to create, persist and resume state machines, which can help a ton for complex workflows. It also forces you to think in a bottom-up approach instead of a top-down approach like most languages&#x2F;frameworks.<p>Another interesting thing to dig into is &quot;code calisthenics&quot; and &quot;tiny types&quot;.

Ruby&#x27;s pry.<p>Just dropping `binding.pry` anywhere in the code, run it and then get a full REPL with all the variables and instrospect everything with `ls`. This is why I am still coming back to Ruby and writing everything like it. In most other languages you spend a lot of time actually trying to find a way to debug properly. Happy to hear recommendations how other languages are doing it. (I know that there are debuggers :P )

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 &quot;microservices are epic&quot; mantra. &#x27;Cause, oh boy was that annoying and difficult to debug.<p>When I learned functional programming, in my head, classes suddenly became slightly worse versions of partially applied functions.<p>When I learned about state machines classes also now seems like a failed attempt at achieving the same thing.

OOP, hands down. Though I never learned Functional (and never learned Smalltalk, for that matter. I think the OOP I learned wasn&#x27;t half of what Smalltalk offered.)<p>I learned to program on punch cards, and the options were &#x27;top down&#x27; (&quot;The best way&quot;), and bottom up (&quot;The bad way&quot;).<p>Top down was hideous, because it ended up being decomposed as the next level as (1) Initialize things (2) Do what&#x27;s needed. There was no clear path to subdividing the functionality.<p>Bottom up was worse. Ya&#x27; know you&#x27;re gonna need a routine to do such-and-such, so go ahead and write it. You get to feel productive. The huge down-side was that you couldn&#x27;t figure out in advance precisely what was needed, so those routines always got re-written to be amenable to what was needed at a higher level once the higher levels were written.<p>OOP gave me a way to think about the middle layers of a program in a way that isolated some element of what was needed and let me code it &#x27;usably&#x27;. I could sit and think about an what kind of interface I wanted to provide, and get it right. It was also a big win to realize that even C (NOT C++) could be used in this paradigm, in terms of a boundary around the interior or some piece of functionality.

The ability to freely mix programming paradigms and to bend the language towards the problem instead of the other way around. It&#x27;s the thing that Common Lisp is kind of famous for.<p>Depending on the programming sub-sub-task that I&#x27;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&#x27;m at it, and the ability to always branch off to a task-specialized DSL whenever it brings direct benefits to the table.

YAGNI, unlearning OOP, embracing simple languages, accepting that the requirements&#x2F;hypotheses about external world is the most important signal.<p>Before: I was endlessly creating useless abstractions and going for cute and &quot;elegant&quot;.<p>After: Simplest possible code.<p>The downsides:<p>1) One has to know good code from bad to evaluate if &quot;simplest possible code&quot; is not too simplistic and won&#x27;t cause you problems a month, a year or 5 years later;<p>2) One is always bombarded by the &quot;cute&quot;, &quot;elegant&quot;, 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.

For me, more than any paradigms, the following outlooks were the most useful -<p>1. YAGNI - plan for the future if required but only implement once it arrives.<p>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&#x27;t try to create a generic dynamic form.<p>3. Tests - Not necessarily TDD, but there should be tests for when you think your module &#x2F; function has been done. This will ensure your edge cases are considered. Try NOT to fix a bug without adding to your tests.

For me the biggest impact I&#x27;ve seen in my every day programming is creating a list of utility functions like lodash or underscore.js for both Js and Php.<p>I have these 2 huge files with hundreds and thousands of small unit tested functions that do everything under the sun like sorting a js hash by key, to making ajax requests, to all the things I&#x27;ve needed to do over the years. This has reduced my time to code by so much I can&#x27;t even begin to describe and also I feel confident of not making silly mistakes since the functions are tested and reused many time. Thanks to tree shaking in js it also means I do not increase the bundle size.<p>On other thing that has helped me a lot with programming is learning zen css and zen html, i.e. div.test&gt;span&gt;b type stuff. Such macros really help a lot to avoid mistakes and help speed up things.

First pure functional programming (not just functional programming) and then type driven development with a typesystem that supports dependent types.<p>In combination they are a huge productivity boost that you can&#x27;t really imagine without having tried it. I still remember the days where I wrote tests over tests and ran the system to check if it works. But &quot;if it compiles it works&quot; is just a sooo much smoother workflow.

Not so much a paradigm, but learning TDD from the engineers at Pivotal Labs really changed the way I approach problems.<p>I spent a few weeks constantly pairing and doing TDD with them, and while I don&#x27;t think I could pair forever (maybe 2 days&#x2F;week), I was amazed at how TDD could shift my approach to a problem. These days I&#x27;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.

The Turbo Pascal IDE. At first I thought it was stupid to have to compile a program instead of just writing it in BASIC, which was what I was used to. Then I learned to love that almost instant compile and insane speed compared to BASIC.<p>When I was forced to move to Windows, Delphi was there to make it damned easy to build GUI apps, which was about a similar step in productivity as Turbo Pascal. They used the perfect amount of OOP to get the job done, but not bury you in abstraction.

I think it would have to be machine language, assembly language, and C used to program machines at the hardware level. This was on an Atari 8-bit except C being cross compiling to M86k. In all cases I was programming to hardware interfaces video games and laser printer firmware. What it taught me was as sense of &#x27;you can understand it all down to the metal&#x27;. That hardly seems valuable now, but what that means is that I&#x27;ve always had the curiosity and desire to know how things work which leads to deeper understanding in our field.<p>Learning recursive programming was an eye-opener because it clearly illustrated the correspondence of programming and math (proof by induction). [Dynamic programming was meh when I learned it--memoization seems a more fitting term--as I expected to be learning metaprogramming.]<p>The thing I wish I&#x27;d been taught or learned much earlier is functional programming. And maybe data-oriented design if that&#x27;s a name of the thing that prioritizes data schema and layers operations on them. I&#x27;m always surprised by coding-first developers not able to put fields at the appropriate place considering cardinalities, or never even think that it&#x27;s important to get this right.

Got to be MVC right?<p>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&#x27;s been by far the most influential on me.<p>Also I&#x27;m not sure if this is a programming paradigm, or just good practice, but strongly typed parameters + throwing errors if they&#x27;re not the right type. I thought TypeScript was the bees knees when it came along.

&quot;Reactive&quot; sutff. Bad impact. Programmer for 30 yrs and while it theoretically makes sense, pratically it&#x27;s all a shitshow so i made a very simple js framework thats all &quot;imperative&quot; like Android (findView, setText, etc etc.) just for myself.<p>Been making a living migrating react and vue overengineered projects that are supposed to be small to this with much succe$$.

Only paradigm isn’t enough. Language design, ecosystem and pragmatism is essential as well and Clojure has all that.<p>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.<p>I thought we shouldn’t have to recompile the whole project upon every single change.<p>Classes and private public fields, methods felt like they were solving the wrong problem.<p>Other fancy words, that contained fairly simple ideas, felt like the output of <i>clever</i> language designers who enjoy the sound of their voice.<p>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.<p>I wrote software in many different programming languages over the years but writing Clojure at work is fun, multiplied.

Easily this was the idea that maybe OOP wasn&#x27;t the solution to everything. It&#x27;s not exactly a paradigm, but more of a repudiation of one. I still write a majority of my code in classes. But you can see a lot of other influences as well: the command pattern (which is more procedural I would say), a lot of LINQ expressions (which are pretty functional), and a whole lot of dumb records being passed to dumb functions (which I got from data oriented thinkers). Anyway the point is, it&#x27;s not just one paradigm which has made a difference for me. It was realizing that there isn&#x27;t <i>one</i> paradigm. I can freely import influences from all of them, use them where appropriate, and get a benefit from all of them. Including OOP, but not only OOP.

Working at a company that cared deeply about correctness and reading code over writing it was critical to my current coding style and beliefs. I&#x27;ve written about some of this at <a href="https:&#x2F;&#x2F;programsareproofs.com&#x2F;articles&#x2F;singleuse_functions.html" rel="nofollow">https:&#x2F;&#x2F;programsareproofs.com&#x2F;articles&#x2F;singleuse_functions.h...</a>, but I developed an aversion to single-use functions, premature abstractions, and &quot;self documenting&quot; code. The code I write these days is drastically more understandable and modifiable than back when I targeted terseness, minimizing duplicated code, and future proofing.<p>As far as languages go, learning SML and functional programming was probably the biggest change for me.

Not a proper paradigm, but I will say test-driven-development. They didn&#x27;t teach that to us at University, or I was not paying attention when they did. I had to learn it afterwards.<p>I struggled with it for months. Only started seeing the benefits way after. An exercise on delayed gratification. I think its main difficulty is that it requires &quot;learned intuition&quot; - knowing which tests to write first, and which ones to build afterwards. It&#x27;s a bit like solving integral equations - apply the &quot;right&quot; transformation and you get to the result in a few steps, fail to see the pattern and you&#x27;ll have a hard time.<p>Perhaps I didn&#x27;t find the right resource. I won&#x27;t say that I use it every day, but it is certainly at the top of my toolbox.

Object oriented programming, though not the Java BeanCakeFactoryFactoryInterfaceProvider approach. It isn&#x27;t exactly Java&#x27;s fault though, it is just common there - but there are exceptions (see Swing vs SWT, with the latter having a much simpler API or LWJGL which has a very simple API itself). Also i don&#x27;t really do the whole patterns thing (unless accidentally) nor all the acronyms (i don&#x27;t care about things like LSP, SOLID, etc, i mainly keep related things together and use inheritance for specialization).<p>Of course i don&#x27;t do OOP for the sake of OOP, i stick with simple procedural code where it makes sense, but for some things (e.g. GUIs) other approaches feel like trying to shove a square peg through a round hole.

The imperative paradigm. Because most or all of my code is imperative. Of course most of my code is also object oriented but it&#x27;s more of an add-on and in practice classes function more like modules. I don&#x27;t think much about inheritance and polymorphism.

In a negative way: the current JS ecosystem and the way we build web apps in general. I started programming in late 80s and was very scrupulous in my work. I learned how to profile and optimize my code; I basically knew what each byte was doing. When I discovered Linux it was such a joy as I could basically trace the whole execution path and optimize everything even more.<p>Also, I love order. I enjoy clean and elastic design that keeps things in order but gives you the flexibility to extend the functionality indefinitely. In spite of some reservations, I enjoyed building apps with GUIs in the 90s, the process was quite pleasant and neat.

Functional programming without a doubt.<p>And everything that elixir and Erlang drags along with it.<p>Nothing comes close as yet in terms of what one can do this this.

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

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.<p>The single responsibility princible gives a good rule of thumb of <i>why</i> and <i>where</i> 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.

Paul Graham&#x27;s book Hackers &amp; Painters resonated with me as a teenager, more specifically what he wrote about how code is like paint, or clay. Writing software is like writing essays: you make drafts, iterate, kill your darlings, and even though you may have a single goal in mind, a point to make, things seldom have a definite form. It&#x27;s an art. It&#x27;s more of a hacker&#x27;s mindset, perhaps, but I keep it close to heart still because it&#x27;s how I stay sane in this business.

Uncle Bob&#x27;s &quot;Extract Till You Drop&quot; 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 <i>and</i> this).<p>I went from creating messy, frustrating code to well-organized, easy to debug modules that (have) run w&#x2F;o issue for years. At first it seemed like overkill, but the sheer speed of bug fixes 10x&#x27;d overnight for me. I haven&#x27;t looked back in 5+ years.

Ironically enough I&#x27;d say extremely old-school imperative code has made a large impact for me. I&#x27;ve learnt OOP and to some extent FP as my default. Doing some OpenGL and other rendering stuff was refreshing and allowed me to explore much simpler ways to think about problems. Letting go of abstractions is tougher than it sounds. Killing your darlings type stuff.<p>I never really got into systems languages. I guess that&#x27;s the main way other programmers get the same insights.

The relational model.<p>Is so simple, that for like a decade I was using it with great success without having a clue about it.<p>Then when I start looking for my hobby programming language, was the one that pop-up as the easiest to implement with the greatest level of potential and expressivity. There is when I truly pay attention to the actual theory.<p>And the shocking part is that the theory is so small that you can put in in a single piece of paper.<p>Why is not more prevalent? I dunno!

procedural programming (is it data or is it code, it can’t be both)<p>and data oriented design with SOA and deferred buffering<p>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

No premature optimization. Don&#x27;t wrap code in complex patterns unless you&#x27;re sure you&#x27;re gonna need it within the next hour.<p>E.g. if you&#x27;re building some kind of file system access and know you want different &quot;drivers&quot; (e.g. local, Dropbox, Google Drive), using an adapter pattern is fine. If you just need local access right now, don&#x27;t waste your time. Refactor later if needed.

In chronological order:<p>- Pure functions<p>- TDD<p>- OOP<p>- DI<p>- FP idioms<p>- Inmutability<p>From these, the most important is DI. Separating the set up of runtime dependencies between parts of the software from the logical dependencies is a total game changer.<p>I&#x27;m curious about Erlang, which I didn&#x27;t try yet, since it seems to capture almost everything in one language. Pure functions, inmutability and FP idioms on the micro level with strong OOP and separation of logical from runtime dependencies on the macro level.

If I have to pick only one it procedural low level programming, like good old C. Taught me a lot about how memory is laid out, how software works under the hood, about lower level concepts.<p>Going from C to higher level languages like C++, C#, JS or Python means that I have a glimpse into why things work the way they work and having that understanding is helpful.

I would call it &quot;dataflow-oriented imperative programming&quot;. Think about your data structures first. Then think about the manipulations you need to apply on them. The program then becomes a collection of procedures, with locally-scoped &quot;const&quot; variables, in an almost SSA-like form.

I don&#x27;t know if I can say.<p>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&#x27;s basically a bunch of rules that force you to break habits, even though it&#x27;s easy to conflate that with benefits from the paradigm-change.<p>It&#x27;s difficult to improve when you&#x27;re basically just building the same program over and over. That&#x27;s what I&#x27;ll argue is the benefit from switching paradigms; you can&#x27;t keep doing that, so you&#x27;re nearly forced to learn new things.

It&#x27;s interesting to see how many people in this thread have had negative experiences with OOP. As much as I don&#x27;t do OOP that much anymore, I think it had a positive impact in me. But like every popular practice, there is a lot of bad patterns you have to navigate through.<p>Things like depending on interfaces as opposed to concrete implementations; or prefer message passing over direct data access are practices that I learned in OOP that I still value. The &quot;Small Talk crowd&quot; from the first team I worked in and influential authors in the topic (specially Sandi Metz) still have a dear place in my heart for how they improved the way I view software design.

Pure functions. It totally changed my game when I realised that state was &quot;evil&quot; and that it should be treated like the dirty little possum that it is.<p>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&#x27;t do OO on your resume, no point applying.<p>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&#x27;t the dream of reusability we were sold.<p>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&#x27;s another big shift I took from game development: choose composition over inheritance.<p>Code layout-wise, we went from hellish nightmare, to MVC, to MVP (presenters) and finally MVVM (thanks Silverlight).<p>Then came the reactive UIs. That&#x27;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&#x27;t get into a spaghetti fest of system-wide events, you&#x27;re probably going to be OK.<p>I think we&#x27;re becoming closer and closer to Model - View, with a bunch of render methods and utility methods on the side.<p>I&#x27;m not sure what the &quot;next&quot; 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&#x27;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.<p>As for the native stuff, I&#x27;m really digging the SwiftUI thing. It took them a while, but it&#x27;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.<p>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&#x27;s biased...<p>So to sum up? Pure functions, composition over inheritance, reactive rendering, strongly-statically type languages used for both rendering&#x2F;logic that are as powerful as Rust and as terse as Python.

12 factor app and SOLID.<p>When you have to review code you notice sometimes people that dislike OOP are doing a lot of messy code. Procedural code or procedural code hide in a object is not OOP and it&#x27;s horrible to review!

&#x27;Fail early&#x27; and &#x27;throw exceptions in exceptional circumstances&#x27;. 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 &#x27;graceful&#x27; error, for problems that can&#x27;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.

Functional programming combined with the process dependency tree of Erlang.<p>Up until a point functional programming with PHP or Python were always littered with small state time bombs which could change at any point in time. Only after thinking about state explicitly in Erlang based programming, was it clear how the state enclosed in OOPS is a total digression from reasoning about state and behavior separately.<p>Python, Erlang and then Clojure

Clean Architecture. I’ve only tried to implement it once, then I realized I was over engineering. But I still use it as a template to design softwares, but I implement something more crude.<p>Laravel’s use of conventions and facade. It was quite nice to see how a carefully designed developer experience can improve productivity. For most app, the code basically write itself.<p>The versatility of common lisp.

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

Ruby&#x27;s programmer happiness focus.<p>For me Ruby is the most optimized language there is, and optimized for the most important thing: My happiness.

TDD. It gave me a framework to write easier to understand code and solved my verification issues. Not sure I would still be a coder if it wasn&#x27;t for that.

Focus on risky&#x2F;unknown parts of a project first, don’t start with what you already know&#x2F;can do.<p>And many more from the excellent book “The Pragmatic Programmer”.

Term and graph rewriting.<p>They encompass most good things in programming - compiler optimizations, functional programming, self-modifying code, etc.

Not really a paradigm, but when I learnt about state machines on MCUs that influenced my overall programming a lot :)

OOP modeling is an art<p>Add some handy lang features for technical code like LINQ and Result&lt;T&gt; and it&#x27;s great

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

Making operations idempotent.