3 ms·
Since beginning to see the value of purity, I write imperative code in a different way. I don't care much about local manipulation of state for algorithms and s
by mbrock 13y ago
Since beginning to see the value of purity, I write imperative code in a different way. I don't care much about local manipulation of state for algorithms and such, but I write a lot more pure functions.
It's not only that purity is safe and beautiful. It's also in many cases much easier to understand, because it's about writing functions that express transformations. These transformations should make sense in a conceptual way.
When you distill your domain concepts (see "Domain-Driven Design") and write pure functions on domain data, the result is remarkably clear, testable, and debuggable, no matter which language.
Previously I would have been (prematurely) concerned with the efficiency of in-place updates, but since I'm not writing high-performance CPU-bound software, I don't care about that anymore until the profiler tells me to.
- vladimirralev 13y agoWhat is your imperative language? Do you write imperative code in OOP? Do you find yourself compelled to implement everything with static methods?
- mbrock 13y agoI currently work with Java. This codebase employs a kind of pseudo-OOP, according to a pattern that I think is at least somewhat popular. Data is mostly represented by objects with only getters and setters. Business logic is contained in "services," which are basically stateless singletons (handled by dependency injection). The best code in the system, IMO, consists of small stateless singletons with clear dependencies and non-modifying operations. This code often comes out of test-driven development and has tests that read like specifications.