I'm still struggling to get an intuition for places in my code where some idea would be more elegantly expressed with >=> or <=<.

Haskell can be a beautiful small language. One can enjoy it like a walk in the woods, without worrying about which typeclass models our light cone in the universe.

My first functional language was APL; I later moved from C to Standard ML. I loved Scheme till I realized I was camping, it was getting late, and I needed to build a shelter from Y-shaped twigs. Somehow OCaml never took for me, but reading a few of its source code modules was an efficient crash course for coding in a functional language.

What is the dream that these languages and Haskell aspires to realize? We want to slice computations in arbitrary ways and manipulate the parts as algebra. This dream of many since the first Lisp meets resistance from those who don't love algebra, but one cannot fault the aspiration: Find a way we can all code with more leverage, less effort.

Pretend Haskell is as small as APL or Scheme. Ignore those who scoff at your primitive avoidance of an emerging Haskell pattern.

I highly recommend Simon Marlow's "Parallel and Concurrent Programming in Haskell". I don't know any language that handles parallel as gracefully, and one can read this book without ever seeing an >=> or <=<.

Sure, but I still appreciate the ergonomic benefits that come with having developed the ability to recognise these patterns.

I'm not a Haskell programmer yet but from what I understand it's basically just function composition, with the condition that the functions return some kind of Functor.

In normal function composition, let's say you have function `tostr` that converts a boolean to string, and function `strlen` that computes the length of the string.

They have the ff. signatures:

tostr :: boolean -> string

strlen :: string -> number

If you compose these two functions, where you `tostr` then `strlen`, then the resulting function will have the ff. signature:

composed :: boolean -> number

Now let's suppose that `tostr` and `strlen` both return a Maybe monad, with the ff. signatures:

tostr :: boolean -> Maybe string

strlen :: string -> Maybe number

This is where the fish operator helps, because if we compose it normally it doesn't work because `strlen` expects a string, not a Maybe string. The fish operator will automatically unwrap the value, resulting in the ff. signature:

mcomposed :: boolean -> Maybe number

I guess it's subjective, but I prefer

  f = h <=< g

over

  f x = do
    y <- g x
    h y

I use it basically as the beginning of a pipe, where I want to process, for example, a String, but I have to start the pipe with an IO String.

Simplest example, I have would be to read something from a file and apply some function `f :: String -> String` to the contents of the file, and return an IO String again. Let's say that overarching function is called readFileAndProcess, then it could be defined like

`readFileAndProcess :: (String-> String) -> String -> IO String`

`readFileAndProcess f fileName = putStrLn . f <=< (readFile fileName)`

You can just borrow your intuition for when to use point-free style: `>=>` is to do-notation as `f . g` is to `\x -> let y = g x in f y`.

I think the author meant "just" as in: it is only another name. In Haskell, you can make an infix operator out of a function by putting it between backticks. Thus, `fmap` and <$> are synonyms. For example:

    (subtract 3) <$>    [1,2,3,4]  -- =[-2,-1,0,1]
    (subtract 3) `fmap` [1,2,3,4]  -- =[-2,-1,0,1]

My reading of that sentence is that “<$> might rightfully scare you but it is only a synonym for the fmap function.” Does that still sound arrogant?

As a mathematician this looks like standard usage of "just" in mathematics, but I do try to avoid doing that because it does sound arrogant and patronizing

yeah, the ignorant tend to misunderstand and incorrectly infer intent.