Hacker News Reader

Comment by pca006132 | Hacker News Reader

I may be biased due to familiarity with imperative programming, but I think it is natural to think in a way that mutate states, as we live in a mutable world. I agree that functional programming might be easier to compose and reason about in a high level but it may be hard to teach beginners these abstractions, e.g., consider how many monad tutorials out there. Concepts that experienced users think are trivial may actually be confusing to beginners, especially if they are abstract...

I do agree that C++ is not a good language for beginners. I think a language similar to Python but with static type checking will be a good one.

View on HN

It's natural to think in terms of "mutating the real world", but I don't think it's natural to introduce artificial mutable state at all.

You say "clean all those dishes", not "let x=0, then while x<N, clean the x-th dish from the top, then let x = x+1"

Ask someone without a scientific background to solve (a * b) + (c * d) with a (physical, non-software) calculator. The "correct" answer is to do something like: a * b, M+, c * d +, MR. What they will do is: solve a+b, write down the result, then do the rest. They don't think of a calculator as something stateful.

I'm not following here - if it is not a typo, why would you expect someone to solve a+b here?

But if we are using calculators, then depending on the make and model, you might do a b * c d * +, Which achieves the goal your second paragraph is aiming for: getting rid of (or at least abstracting away) any explicit use of incidental or intermediate state (which takes the form of memory operations in conventional calculators.)

RPN calculators (and programming languages), however, never became popular, and I strongly suspect that is because their expressions are often objectively harder for humans to comprehend, no matter how elegant RPN seems.

It's a typo, I meant a * b.

I agree on RPN, that was the point I was trying to make. RPN is more powerful, but is stateful and uses a rather complicated and unintuitive form of state (a stack). In my experience it's not true that people find it more intuitive to work with arbitrary mutable state of the kind imperative programming languages traditionally have.

I don't think in your dishes example that `x` is introduced complexity. The mutable `x` is used here to reflect the mutable state of the physical world, so it'll come naturally to anyone capable of thinking symbolically and want to describe how to clean. If you did that functionally, the mutability would still need to be reflected somewhere, only now it might be implicitly in the runtime.

The difficulty with using M+/MR is that the value does not remain visible or at hand. It's like the calculator loses its state. So people write the state down instead. This suggests they know it is stateful, they're just not familiar with managing it.

To be pedantic, the world is not mutable, rather, it is a process undergoing a continuous transformation.

Also, machines deal with data - which is encoded information about the world.

So when we say that a thing 'changes' in the world, what we're actually saying is that at time T, something happens to the world and from then on, the data we read back is different.

'Something happened' is new information which is added on top of the state of the world at time T-1.

Eg. the user e-mail does not 'change' to be come X, but rather, it used to be Y, then the user changed it to X on 1st of May.

So we can generalize that the world is a function `f` of some state combined with extra data of what happened at time T, giving us the state at T.

Let me ask you a question: is using numbers natural?

Apparently it is not, because otherwise it wouldn't have taken so long for the concept to spread, and folks like the romans would have used 0 from the beginning.

But just because something is not natural does not mean it is not more productive than the alternative solutions, given that one spends the time to learn it.

So, maybe mutating state is natural - but I would object the claim that this means it is more productive.

You can apply some level of pure function in whatever langues, and it not that hard and make thing easy to test and think about it

Monad is like highly effective and complicate patch to handle thing who couldn't be pure function. i don't like Haskell because of that is not natural force that much the langues for me(opinion), but is like try to tech Rust as first langues you don't have the grasp in the limitations to understand why ownership matters, and why all the langues need to be kind a weird, is still weird but you understand the advantage and grasp at least the syntax and basic patters make it more pleasure to learn it.

Monads are pure expressions/patterns. It's only impure and have side effects in the final evaluation, for a few monads like the IO Monad. It's just using monadic expressions for tricking side effects into the language in a cleaner way, thus considered beneficial.

Haskell is hard for programmers, because it forces them to truly think. Haskell grows on you when you get to know how it evaluates and forces you to separate concerns structurally. For that reason, it's said to be a language that teaches you how to program better.

Well, we used to teach it to first year university students back in the 1990's pre-standard.

C was already taken out of curriculum (students were expected to learn it from the C++ learnings), and we made use of our own collection classes with bounds checking.

The secret was teaching the language on its own, and not as C with extras.

Reply on news.ycombinator.com