3 ms·

It seems more complicated than necessary. Why not a syntax like... from("telegraf") .range(-1h) .where(_measurement, "foo") .exponentialM

It seems more complicated than necessary. Why not a syntax like... from("telegraf") .range(-1h) .where(_measurement, "foo") .exponentialMovingAverage(-10s)

marshalking 8y ago
I totally agree. Building a language without an elegant/concise syntax won't go very long in my view.
jtchang 8y ago
This looks a lot like SQLAlchemy.
pmontra 8y ago
Exactly, I came here to write about the same comment. I'd optionally keep the named arguments because they self document the code from("telegraf") .range(start:-1h) .filter((r) => r._measurement == "foo") .exponentialMovingAverage(size:-10s) No need of writing fn because that's obviously a function. Maybe it's a tradeoff between ease of implementation and ease of use.
dsego 8y ago
What's wrong with a pipeline operator? JS is getting one as well. https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator Chaining calls in JS means that a function returns the original object, piping is actually passing over the result as an argument, so it's semantically different.
- dragonwriter 8y ago
  > What's wrong with a pipeline operator? Honestly, for the use case, the same thing that's wrong with a (mandatory) visible function application operator in Haskell. > Chaining calls in JS means that a function returns the original object, piping is actually passing over the result as an argument, so it's semantically different. The syntax Flux uses for creating the result is the same as JS would use for mutating an inbound object, so it actually would be consistent if pushing the result used the same syntax as passing the (mutated) original object would in JS. Though I’d prefer whitespace for piping just like Haskell does for application. If your are going to specialize a language for a domain, don't be timid about it.

It seems more complicated than necessary. Why not a syntax like... from("telegraf") .range(-1h) .where(_measurement, "foo") .exponentialMovingAverage(-10s)

marshalking 8y ago

I totally agree. Building a language without an elegant/concise syntax won't go very long in my view.

jtchang 8y ago

This looks a lot like SQLAlchemy.

pmontra 8y ago

Exactly, I came here to write about the same comment. I'd optionally keep the named arguments because they self document the code from("telegraf") .range(start:-1h) .filter((r) => r._measurement == "foo") .exponentialMovingAverage(size:-10s) No need of writing fn because that's obviously a function. Maybe it's a tradeoff between ease of implementation and ease of use.

dsego 8y ago

What's wrong with a pipeline operator? JS is getting one as well. https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator Chaining calls in JS means that a function returns the original object, piping is actually passing over the result as an argument, so it's semantically different.

dragonwriter 8y ago
> What's wrong with a pipeline operator? Honestly, for the use case, the same thing that's wrong with a (mandatory) visible function application operator in Haskell. > Chaining calls in JS means that a function returns the original object, piping is actually passing over the result as an argument, so it's semantically different. The syntax Flux uses for creating the result is the same as JS would use for mutating an inbound object, so it actually would be consistent if pushing the result used the same syntax as passing the (mutated) original object would in JS. Though I’d prefer whitespace for piping just like Haskell does for application. If your are going to specialize a language for a domain, don't be timid about it.