I feel many fluent API's are guilty of something similar. You gain terse, one-line magic statements that accomplish a lot; you lose discoverability and meaningful object-oriented class names.
For example, ElasticSearch's NEST API client uses a fluent-style API to setup configuration and mappings. It started out well, but then I got lost in a forest of nested callbacks on various mystery objects. It was a bizarre way to build what should have been a tree of strongly-typed POCO's that have a 1-to-1 correlation with the server-side concepts. Worse, I didn't see a way to dynamically manipulate the (hidden) result. Better to use the low-level API and a little reflection to compose the required JSON manually.
[On the other hand, I can think of successful fluent API's: .NET's StringBuilder works because it is super simple (only returning instances of itself). The IEnumerable extension methods (created to support LINQ) work because their broad-applicability justifies the effort to learn.]
For example, ElasticSearch's NEST API client uses a fluent-style API to setup configuration and mappings. It started out well, but then I got lost in a forest of nested callbacks on various mystery objects. It was a bizarre way to build what should have been a tree of strongly-typed POCO's that have a 1-to-1 correlation with the server-side concepts. Worse, I didn't see a way to dynamically manipulate the (hidden) result. Better to use the low-level API and a little reflection to compose the required JSON manually.
[On the other hand, I can think of successful fluent API's: .NET's StringBuilder works because it is super simple (only returning instances of itself). The IEnumerable extension methods (created to support LINQ) work because their broad-applicability justifies the effort to learn.]