A "nice syntax to the builder pattern" describes every single applicative based DSL I've seen on Haskell. (I think this generalizes for all theoretically possible ones, but I need more coffee for being sure.)
But you get the advantage that applicative is a standard syntax, what you don't get on most builders.
I have started intuiting it like this. I want you to imagine the concept of a "producer of values", which is a fairly broad notion. This can be
1. a list, which produces its elements one at a time;
2. a computation that might fail to produce a value, which either produces one value or none at all;
3. an I/O computation, which may ask the user for a value to produce),
4. a stateful computation, which produces a value that may depend on some hidden state;
5. a parser, which produces a value that may depend on the source data being parsed;
6. a source of pseudorandomness, which produces a that is unpredictable;
or any other of a nearly infinite set of things. For such a producer of values, we can imagine that
A) The Functor instance says, "Hey, give me a function and I'll create a new producer that produces the values you get if you apply that function to the values I produce."
-- Example: If the producer is the infinite stream [1..] and the function is (^2), the Functor instance lets us create a new producer that produces the infinite stream of positive perfect squares.
B) The Applicative instance says, "Okay, that's cool, but you know what I can do beyond that? Give me two different producers of values, and I promise you I'll create a producer that combines values from both of the two producers you gave me. So in a sense, I am a combiner of producers."
-- Example: If the first producer is a database of previous actions the player of a game has taken, and the second producer is a source of randomness, the Applicative instance lets us create a new producer that produces an AI decision based on player action history but with some randomness thrown in to look more human.
C) The Monad instance says, "Pah, and you thought that was neat? Look what I can do! If you give me a producer and several different possible producers, I can create a new producer that chooses which of the different possible producers to run next based on the values produced by the first producer. So in a sense, I am the opposite of Applicative: I am a splitter of producers."
-- Example: if the first producer is a stateful computation that extracts the player health from the state in a game, we may have two different producers lined up to follow: one produces a commiserative message mentioning their score, and the other produces a message telling them round number n is starting. The Monad instance lets us create a new producer that delegates to either of the two depending on whether the player is dead (health <= 0) or alive (health > 0).
... I should really get around to writing this blog post ... I feel like I have rewritten it a thousand times in various comments at various points...
But you get the advantage that applicative is a standard syntax, what you don't get on most builders.