Mariners use "port" and "starboard" for vehicle relative directions not because it's "cool" but because it's clear and unambiguous. Problem decomposition works the same way: some problems decompose better with FP (I would argue databases do) some with OOP, some with EF etc. The more you know the clearer code you can write and the faster you can extract the theory from other people's code.
For instance if you're facing port and I ask you to take two steps forward, you could either take two steps to port or two steps towards the bow. If I tell you to take two steps to port then the direction is unambiguous.
"Stage left" as if I'm standing looking towards the stage from the audience, or looking from the stage towards the audience?
At the intersection of Main and Oak, go two blocks east. The building will be on the north side of the street.
Those instructions are the same no matter what direction the person is facing or direction they came from.
However, on a ship, the absolute positions of NSEW (relative to the Earth) aren't as useful as the ship may be heading any direction (and may be going forward or reverse). So a different absolute coordinate system is use - fore, aft, port, starboard.
So "move forward" doesn't say much, whereas "toward the bow" e.g. does.
Same for left/right compared to port/startboard.
“You want me to turn right, right?”
After that Port/Starboard would make sense and I'd be chucking someone over one of them.
b) With the possible exception of "forward", if you hear one of these words you always know it's specifying a direction relative to the direction the boat is pointing, which is not true for "left" and "right".
Lots of other jargon too for other directions or places (leeward, windward, amidships, athwartships, etc) but that is all much less common than the four listed above.
Also, there's a fun additional distinction for forward and aft, which is that they tend to refer to locations within the vessel. Ahead and astern are used to refer to locations outside of the vessel.
After about 8 years of sailing fairly regularly with various crews, I still get many of the terms mixed up. For instance, stanchions and shrowds are terms that are useful, but they never seen to come to mind when I need to communicate them.
I left the cheese on the left side
Wanted to echo this point.
I'm a huge FP proponent, and I do believe that liberal use FP paradigms can result in code that's in many ways measurably more expressive and less complex than code that make liberal use of imperative looping, in-place mutation, and inheritance, etc. When I'm coding on my own for side projects, I always strive to use the most elegant and expressive FP constructs I can think of.
However, at the end of the day, most of the coding we do is part of a social activity. And in a social setting, familiarity matters.
Writing slightly less expressive, more complex code in a way that most people who read it will be already familiar with can result in more productivity in aggregate than writing code that's super expressive and simple but requires everyone reading it to first learn the paradigms/patterns that enabled the code to be written that way, especially in a fast growing startup where people are constantly onboarding into the codebase.
Optimizing too much for familiarity can also become detrimental though, in that it results in stagnation and closes the doors to paradigms/patterns that can have an outsized impact on overall productivity compared to their cost in learning/education.
The real challenge is striking a good balance between familiarity and expressiveness in the choice of paradigms/patterns to use.
This was often forgotten about OOP as well, as Alan Kay himself reminds us...
"The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be."
Agreed, developers are great at finding new ways to write questionable code no matter what languages or programming paradigms claim about their respective abilities to reduce code errors and smells. I know because I'm one of them.
However, it's not a silver bullet. I found that basic software engineering principles are way more important than the language. I've seen extremely messy OCaml code and super clean C code. What is important is how the code is organized at high level. Whether you use a for loop or a fold, an error monad or an exception mechanism matters less.
I'm also wary of functional programming gurus that tend to over-abstract things and use all the language latest features, making code very hard to read.
Also, when developing in a niche language, you tend to miss important tools and need to rely on unstable third-party libraries.
I used to be quite enthusiastic about FP, but I think I'd stick with more mainstream languages unless there's a good reason not to.