In this post I would like to explore if SOLID principles (a.k.a Object Oriented Design Principles) are useful in a functional programming context. SOLID principles are not sacred commandments that need to be followed dutifully. They are guidelines for designing object oriented code.
All software development activity is design activity. When I say design in this post though, I mean the more abstract design activity that happens (in developer’s head, on paper, etc.) before coding begins.
Java got lambdas now, Kotlin is growing stronger with lots of functional features… Is there anything functional programmers can learn from OOP design?
This is a technical post and laziness in this context means deferring execution of code. When the machine first meets the code, it may be executed there and then or it may be stored and executed later. Which of those happens depends on the instructions in the code, the computer just executes them without judgement.
Most non-technical people think software development is a standardized, repetable process. That is why they come up with enterprise agile frameworks. If it was standardized we would not need to write software but we would generate it from specifications. Every new project, every new task has a component of discovery. It requires us to think outside of the box. Therefore assembly line approach to software development produces mediocre results at best.
This is the third post of Getting a Little Further Than Hello World With Rust series. We will look into Rust’s concurrency support. I intend to provide a guide for the Rust language and try to keep things within the safe Rust realm. We will be looking at the concurrency primitives that are in the Rust standard library. Please keep in mind that there are popular libraries that provide other efficient and convenient concurrency primitives.