Hacker News Reader

Comment by pjc50 | Hacker News Reader

Nail on the head there. The humble state machine is a more important part of programming than people like to admit. And a very large amount of business logic is most naturally expressed in terms of data state manipulations, real world state manipulations, I/O. To do I/O in FP you have to deal with monads, which are hard to understand and work with.

(You can tell that monads are hard to work with because there are so many articles telling you that they're easy)

The common ground is functional-ish and mostly-stateless programming ("const" etc). C# is actually becoming very good at this, and you can always cross into F# if you want.

View on HN

I think you're conflating functional programming with Haskell.

You can use something like Clojure without touching monads, just use functional data structures to represent values instead of using objects, and the using mutable state is simple just not the default and you rarely need to go there.

In fact if you're using something like React and something like Redux you're going in that direction from the other side - in Clojure it's basically the natural way to solve the problem (and frankly all of their concepts map much better to CLJS than JS)

I feel like people pushing Haskell and all of the weirdness that comes from lazy evaluation did more harm to FP perception in the general programmer community than good.

> * feel like people pushing Haskell and all of the weirdness that comes from lazy evaluation did more harm to FP perception in the general programmer community than good*

You've hit the nail on the head. Haskell has the combination of being very extreme and popular enough that it is damaging the perception of FP as a whole. I really wish Haskell didn't exist.

For anyone skeptical of FP who might be reading this: start with a dynamic FP language or a typed FP language that is strict rather than lazy. Examples of the former are Erlang/Elixir or Scheme. Examples of the latter are OCaml, Elm, F# or good old Standard ML.

beg your pardon? you said "react cool" and "lazy eval bad" in the same sentence... what's react but lazy eval of the dom?

There's nothing wrong with lazy evaluation, like lazy seq/iterable transforms - it's just not a good "default" IMO

  > The humble state machine is a more important part of programming
  > than people like to admit

Here is where I feel a lot of OOP applications are “doing statefullness wrong.” Everyone gloms onto the popular GoF patterns, but explicit state machines are not nearly popular enough.

A colleague once remarked that in business programming, every model should be a state machine until you can demonstrate you can do without. For example, many Ruby on Rails models have a concept of validation. Most such models can be greatly improved by treating “invalid” as an explicit state with its own methods and behaviours distinct from the methods and behaviours of a valid model (which may encompass other states as well).

I find that if you’re going to have state, go all the way, reify it, make it something you can name and manipulate. Implicit state is the GOTO-ridden spaghetti-code of imperative programming style.

Monads aren't "hard to work with". The .NET core libraries contain a number of them which are some of the most commonly-used types in C# (and F#). To name a few:

* IEnumerable<T>

* IObservable<T>

* IQueryable<T>

* Lazy<T>

* Task<T>

You'll rarely hear the term monad in the MSDN documentation though. Maybe it's opaque terminology that scares people away from monads rather than monads themselves.

here's a state machine representing a lock in elm:

  type State = Locked | Unlocked
  type alias Model = State
  
  lock : Model -> Model
  lock model = Locked
  
  unlock : Model -> Model
  unlock model = Unlocked
  
  open : Model -> Bool
  open model =
    if model = Locked then True else False

and here it is in erlang:

  lock(_Lock) -> locked.
  
  unlock(_Lock) -> unlocked.
  
  open(locked) -> false;
  open(unlocked) -> true.

i think working with state machines in imperative languages is messy, mistake prone and hard to reason about. functional languages are just better for managing state

  > (You can tell that monads are hard to work with because
  > there are so many articles telling you that they're easy)

lol yeap, you made me curious so I went to search for those articles, and sure enough, there are plenty. My favorite quote was: "Monads are easy, you just need to put in the work."

My second-favorite quote was: "if someone is really convinced that monads are easy, they are going to be in for a demoralizing shock"

Riding a bike is easy. Learning to ride a bike is hard.

One more:

"A ‘newbie’, in Haskell, is someone who hasn’t yet implemented a compiler. They’ve only written a monad tutorial"

> To do I/O in FP you have to deal with monads

No.

> The common ground is functional-ish and mostly-stateless programming ("const" etc). C# is actually becoming very good at this, and you can always cross into F# if you want.

Newish C# is just functional programming dressed up as Java, and goes far beyond const. C.f. functional-ish C# programs to C programs that use const. Striking difference.

F# is just .NET's version of a straight up a very traditional and canonical functional language. If F# isn't functional then nothing except maybe untyped lambda calculus is functional.

The article's title is correct only in the tautological sense that unpopular things are weird, even in the paradoxical case where those unpopular things are actually fully embraced while remaining unpopular.

I enjoy "functional languages" because they force good practices, especially those that may not pay off immediately. Merely offering some nice features (C#, Java 8, etc) doesn't force you to write your new code better, let alone refactor all that old code, and thus I'd argue the benefits don't follow.

Nothing is going to force you to write new code better or refactor old code if you don't have the motivation yourself. I can guarantee you that I could write horrible spaghetti code in any functional programming language.

Yeah, but it's just easier to refactor in a functional language. :)

Erlang is functional, but I/O is just functions (that send messages).

Reply on news.ycombinator.com