While I don’t like Fluent interfaces at all, I don’t like the alternative presented much either.

My dislike of Fluent interfaces stems from two things. First, it’s trying to contort an English-like sentence out of a programming language, which just looks and feels wrong. It leads to weird methods like ‘.method’ in the example. Second, Fluent interfaces really try to paper over the fact that the language lacks an equivalent to Visual Basic’s ‘with’[0] statement.

On the other hand, the example presented is not great either. Should ResponseAssertStatus be an object? Wouldn’t it make more sense to do the request then have a separate line of code to evaluate the status? How does it make sense for BodyOfResponse to be constructed out of some kind of ResponseAssertStatus object?

Between the two options, the Fluent interface makes more sense, even if the underlying implementation ends up being kind of ugly.

[0] https://docs.microsoft.com/en-us/dotnet/visual-basic/languag...

braythwayt

I second the notion that fluency is a language syntax problem that should not be solved with the design of interfaces.

Smalltalk also solved this problem with the semi-colon, but for some damn fool reason we followed C syntax but didn't find an alternative. And now we're trying desperately to replicate `&.` in every library and language, but we still don't have an easy way to write:

    someObject
      .doThis();
      .doThat();
      .dontForgetToFinishUp().

mhomde

I always wanted a language that was built upon the concept on just passing things forward in a pipe, and was like an hybrid between functional and c style languages, like:

  someobject => doThis() => doThat() => dontForgotToFinishUp()

then you could also possible send multiple objects into that pipe:

  obj1, obj2 => doThis() => doThat() => dontForgotToFinishUp()

you'd have to have some semantics for sending them separately, as an ienumerable or as parameters but perhaps that could be done

  (obj1, obj2) => doThis() => doThat() => dontForgotToFinishUp()

  [obj1, obj2] => doThis() => doThat() => dontForgotToFinishUp()

add on top of that something that could abstract away multithreading/tasking in certain cases (automatically assigning them to tasks) and I'd be a happpy coder :)

kortex

I spent a half day playing around with something very similar to this. I wanted a concise language for describing data pipelines in Pandas, and was (ab)using python dunder methods (operator overloading) to this end. Like:

`data | groupby, "author" | mean`

Would create a graph object, which could be lazily evaluated, run in Dask, TF, etc.

It started to get ugly when passing in multiple parameters into a function. I had to watch out for left and right associativity, and manage casting of arguments.

It was a fun little experiment but I'm not sure how much it would actually improve workflows. If that sounds interesting, let me know and I'll poke at it again.

wenc

I'm not sure if you are aware, but there are several efforts out there to give Python a more data-pipeline-friendly (composable pipe) syntax:

1) Coconut: http://coconut-lang.org/

2) https://github.com/JulienPalard/Pipe

3) Pandas also has a new dataframe pipe method. https://pandas.pydata.org/pandas-docs/stable/generated/panda...

I would look at those before rolling out a custom solution.