←back to thread

Software development topics I've changed my mind on

(chriskiehl.com)
873 points belter | 3 comments | 05 Feb 25 09:50 UTC | HN request time: 0s | source
Show context
ikety ◴[05 Feb 25 15:22 UTC] No.42949735[source]▶
Functional programming does not prevent you from using objects

Stop listening to functional programming bros. Watch someone like Zoran Horvat. While I can't cosign all of his opinions, he tries to bridge the functional/OOP gap for OOP programmers. OOP programmers urgently need to distance themselves from this binary narrative. Everyone should understand functional programming and how they can utilize functional approaches in every language or paradigm. For me it is a requirement of understanding software development.

Absolutely every institution teaches OOP practices, they also need to teach functional practices. These aren't sports teams.

replies(3): >>42949802 #>>42950464 #>>42954084 #
1. mrkeen ◴[05 Feb 25 15:26 UTC] No.42949802[source]▶
> Functional programming does not prevent you from using objects

It's a bit like how doing single-entry bookkeeping doesn't stop you from doing double-entry bookkeeping.

replies(1): >>42954010 #
2. beders ◴[05 Feb 25 19:44 UTC] No.42954010[source]▶
That's probably the most incorrect analogy. If I have objects, I can change their state in the middle of any bookkeeping.

There should be a different name for functional programming with mutable objects.

replies(1): >>42954505 #
3. mrkeen ◴[05 Feb 25 20:17 UTC] No.42954505[source]▶
I think the analogy works. It's all about the tradeoffs.

Double-entry is harder to grasp, but it has certain properties, like being able to sum along rows or columns. With that property, you can then make assertions like "if anything is off by a cent, then there has been a mistake and it needs to be looked at again."

On the other hand, single-entry is much simpler, you can just record a figure for a date with a reason, and be done with it. It widens the pool of employable candidates, it's easier to onboard new employees, and you don't have any elites screaming at you for doing accounting the wrong way.

If you take a hybrid approach and mix the two, then on average you only have to fill in 1.5 entries per transaction, so it's easier and faster than double-entry, but you can still express some transactions with two entries if it's more elegant, on a case-by-base basis.