4 ms·

> I can't decide if I like the pipeline operator (1). Is it really better? I think it can be useful for processing that is clearly separated into stages. You c

> I can't decide if I like the pipeline operator (1). Is it really better? I think it can be useful for processing that is clearly separated into stages. You can read it forward: foo |> do_this_first |> then_do_this |> this_must_absolutely_be_last instead of backward: this_must_absolutely_be_last (then_do_this (do_this_first foo)) On the other hand, we are used to understanding such "backward" pipelines, so your mileage may vary. > With regard to implicit names (4), I think I actually prefer writing lambdas with my own variable names I would agree, especially because "it" is not a very good name in some cases. "it.length == 5" is really jarring. In Smalltalk, the custom is to name the variable "each", so for the article's examples you would get "each length = 5" and "each toUpperCase", which look nicer IMHO. > Isn't destructuring (5) just an effect of ADTs? Do you mean algebraic data types? I think ADT typically refers to abstract data types, but I'm old. Anyway, yes, destructuring is just syntactic sugar for a pattern match where there is only one variant, so the match can never fail. > Definitely a fan of auto-currying (9). I'm a fan of writing and using curried functions by default. I'm not a fan of Reason's syntax that suggests the opposite. > Is method extension (10) similar to overriding the "magic" double-underscore methods in Python, such as `__add__`? No. It is adding a new method to an existing class from someone else's library.

mhandley 9y ago
I'm not sure about mixing prefix (for functions), infix (for operators) and postfix (for pipelines) notation in the same languaqe. Does having all three in the same language actually help readability? If you really want to read things forward, you could always adopt forth, where everything is postfix: foo do_this_first then_do_this this_must_absolutely_be_last No need for pipelines when you've got a stack.
- tom_mellior 9y ago
  > you could always adopt forth Yes, but that would be throwing the baby out with the bathwater. Just because of a single operator that I'm not sure is useful in a language I'm otherwise satisfied with. > where everything is postfix Except for parsing words, which are commonly used to change exactly this property of the syntax, no? The fact that postfix is nice in many cases does not imply that postfix is always a good idea.
- Sean1708 9y ago
  > postfix (for pipelines) Isn't the pipeline operator infix?
DonaldPShimoda 9y ago
Hmm that's a good point about the pipeline operator. But I'm not sure how I feel about having both idioms readily available. In which cases would you choose forwards processing instead of backwards, you know? I'll have to think more about that. > In Smalltalk, the custom is to name the variable "each" Ooh I like that! I think I would like it even more if "each" was a reserved word, like "this" in e.g. Java. But maybe that's a bit much. > Do you mean algebraic data types? Yes, sorry. I talk to functional people a lot so we tend to use "ADT" for the algebraic ones (those FP people are all about brevity it seems). Glad to have that confirmed, though. Just wanted to be sure I wasn't missing something. > I'm a fan of writing and using curried functions by default. I'm not a fan of Reason's syntax that suggests the opposite. Could you clarify a bit? I'm not sure I follow exactly what you mean about the syntax being unclear. It seems similar to Haskell, except with parentheses, which doesn't seem terrible. > No. It is adding a new method to an existing class from someone else's library. Oh I see! I totally misread that example. Thanks for the clarification!
- tom_mellior 9y ago
  > It seems similar to Haskell, except with parentheses That's the point: In Haskell, the parentheses (and especially the comma) are meaningful, and "foo(x, y)" is not the same as "foo x y". Reason jumps through extra hoops to make the two syntaxes mean the same thing. To a Haskell (or OCaml, or other ML family) programmer, the Reason syntax suggests an uncurried function.
  - DonaldPShimoda 9y ago
    Ohh I see what you mean, yeah, fair point!

mhandley 9y ago

I'm not sure about mixing prefix (for functions), infix (for operators) and postfix (for pipelines) notation in the same languaqe. Does having all three in the same language actually help readability? If you really want to read things forward, you could always adopt forth, where everything is postfix: foo do_this_first then_do_this this_must_absolutely_be_last No need for pipelines when you've got a stack.

tom_mellior 9y ago
> you could always adopt forth Yes, but that would be throwing the baby out with the bathwater. Just because of a single operator that I'm not sure is useful in a language I'm otherwise satisfied with. > where everything is postfix Except for parsing words, which are commonly used to change exactly this property of the syntax, no? The fact that postfix is nice in many cases does not imply that postfix is always a good idea.
Sean1708 9y ago
> postfix (for pipelines) Isn't the pipeline operator infix?

DonaldPShimoda 9y ago

Hmm that's a good point about the pipeline operator. But I'm not sure how I feel about having both idioms readily available. In which cases would you choose forwards processing instead of backwards, you know? I'll have to think more about that. > In Smalltalk, the custom is to name the variable "each" Ooh I like that! I think I would like it even more if "each" was a reserved word, like "this" in e.g. Java. But maybe that's a bit much. > Do you mean algebraic data types? Yes, sorry. I talk to functional people a lot so we tend to use "ADT" for the algebraic ones (those FP people are all about brevity it seems). Glad to have that confirmed, though. Just wanted to be sure I wasn't missing something. > I'm a fan of writing and using curried functions by default. I'm not a fan of Reason's syntax that suggests the opposite. Could you clarify a bit? I'm not sure I follow exactly what you mean about the syntax being unclear. It seems similar to Haskell, except with parentheses, which doesn't seem terrible. > No. It is adding a new method to an existing class from someone else's library. Oh I see! I totally misread that example. Thanks for the clarification!

tom_mellior 9y ago
> It seems similar to Haskell, except with parentheses That's the point: In Haskell, the parentheses (and especially the comma) are meaningful, and "foo(x, y)" is not the same as "foo x y". Reason jumps through extra hoops to make the two syntaxes mean the same thing. To a Haskell (or OCaml, or other ML family) programmer, the Reason syntax suggests an uncurried function.
- DonaldPShimoda 9y ago
  Ohh I see what you mean, yeah, fair point!