Hacker News Reader

Comment by yodsanklai | Hacker News Reader

It's not hard at all. It's routinely taught to beginners.

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.

View on HN

Programming is about clearly communicating theory.

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.

What makes you say "port" and "starboard" are more clear than "front" and "back"?

The alternatives are left and right respectively. They're more clear because left and right are usually relative to the speaker or listener who may be facing each other and are often moving around.

Also the problem of right having another meaning.

“You want me to turn right, right?”

Or worse, "You want me to turn left?" "Right!"

"You want me to turn left? "Right" "Right right?" "No left".

After that Port/Starboard would make sense and I'd be chucking someone over one of them.

It's not "front" and "back" it's "left side of the boat" and "right side of the boat".

Oops.

I'm sorry you got downvoted, it's a reasonable question to ask and I would have voted it up if my noprocrast hadn't run out.

Aft and forward would be back and front.

More correctly, the "left side of the boat" and "no, the other left side of the boat."

a) They refer to left and right, not front and back (which I believe would be "forward" and "aft").

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".

Often just fore instead of forward, or a particular pronunciation like for’d for “the front of the boat as opposed to in front of the speaker”.

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.

Windward and leeward are still commonly used in my experience.

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.

"Port", "starboard" are unambiguously defined relative to the vessel. "Left" and "right" require specifying or guessing a point of reference.

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.

ok, but forward on a boat is toward the bow, as unambiguous port and starboard

It's the difference between "forward for you" and "forward for the boat". Without words like "port", you might do the wrong thing when I say "take one step forward". Did I mean for you to go further in the direction you're already facing, or did I want you to step towards the prow?

You can step forward to any side of the boat.

In Soviet Russia, the boat can step forward to any side of YOU!

It's not as unambiguous because, to the guy with his back to starboard, forward could just as easily mean port! It may seem clear if someone's shouting, and pointing, at the bow, but if I'm recounting the action of a tense combat scene and say he "slips on a banana peel and falls 'forward'", you can't know for sure what I mean- does he fall straight towards port, or does he a break a leg, twisting, tumbling toward the bow? c:

We use similar approaches with terrestrial navigation too.

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.

Terrestrial navigation is also multidirectional.

It's not, because forward depends where you are looking it. That is, the front part of the boat might be on your back.

So "move forward" doesn't say much, whereas "toward the bow" e.g. does.

Same for left/right compared to port/startboard.

In theater you always specific 'stage left' or 'stage right' for the same reason, even though it's more syllables.

I've told my doctor that I had a problem with my passenger-side nostril before

One fun thing about this is that I have to guess what country you're in to know which side you mean.

The passenger side is where the booger is sitting.

It's still ambiguous.

"Stage left" as if I'm standing looking towards the stage from the audience, or looking from the stage towards the audience?

No it isn't because the term was invented specifically to avoid this confusion -- it means "left from the perspective of the performer facing the audience".

As a former US Navy Sailor, port and starboard are pretty clear. Along with Forward and Aft. These are things relative to the ship and points in which everyone is aware of on a ship. If I say starboard, that is right of the center of the ship. Port is left of center line of the ship.

Fun fact: the "port" side used to frequently be called "larboard" until the British Royal Navy realized it was too easily confused with "starboard" and ordered sailors to stop using the term. After that it gradually fell out of favor.

Yes, I always found "left" and "right" so unclear and ambiguous.

Correct, turn right

I left the cheese on the left side

Right! Why use port when left is right? Nonmariners left starboard right at port, left port there as well. Maybe modern mariners should port left back to their lexicon before they're left behind.

How are those terms less ambiguous than left and right?

> 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.

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.

> What is important is how the code is organized at high level.

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."

http://wiki.c2.com/?AlanKayOnMessaging

> 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.

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.

I try to be as functional as possible with my C and C++. You can't reach perfection obviously but I feel it has made my code much better.

Agree. I can program in pure languages like Haskell, Idris etc. but still prefer to program ‘in anger” in OO languages. Having easy access to mutable state is just so damn convenient. As long as you are careful how you do it. Mutable state is a very sharp tool so be careful when you use it.

Simpler fp languages that are hosted on some bigger ecosystem exist though. Like Clojure(Script) and maybe F#.

Simpler fp languages that are hosted on some bigger ecosystem exist though. Like Clojure(Script) & F#.

For one, languages like golang prevent over engineering or bad practice. I’ve never read unintelligible golang code. Some might abuse the interface{} but that’s the worse that you’ll see. Not bad compared to some other languages.

Reply on news.ycombinator.com