foo do_this_first then_do_this this_must_absolutely_be_last
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.
Isn't the pipeline operator infix?
> 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!
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.
I think it can be useful for processing that is clearly separated into stages. You can read it forward:
instead of backward: 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.