201–210 of 282 posts
Meanwhile the JS world has been waiting for 10 years for this proposal, which is still in stage 2 https://github.com/tc39/proposal-pipeline-operator/issues/23...
Go explain them that promises already have a natural way to chain operations through the "then" method, and don't need to fit the pipe operator to do more than needed.
PHP: $result = $arr |> fn($x) => array_column($x, 'tags') // Gets an array of arrays |> fn($x) => array_merge(...$x) // Flatten into one big array |> array_unique(...) // Remove duplicates |> array_values(...) // Reindex the array. ; // Ruby: result = arr.uniq.flatten.map(&:tags) I understand this is not pipe operator, but just look at that character difference across these two languages. // This comment was my $0.02…
It's the same reason PHP allows trailing commas in all lists.
Earlier quoted context omitted.
What makes you believe Haskell is dead or even dying? New versions of GHC are coming out, and in my experience, developing Haskell has never been smoother (that’s not to say it is completely smooth).
And yet, while PHPs, Javas, and even nicher/newer languages like Kotlin, Clojure or Scala have plenty of killer software (software that makes it worth learning a language just to use that library/framework) Haskell has none after 30 years. Zero. Mind you, I know and like Haskell, but its issues are highly tied to the failure of the simple haskell initiative (also the dreadful state of its tooling).
I thought for a while I'd be able to focus on getting jobs that liked haskell. it never happened.
Earlier quoted context omitted.
Haskell seems pretty dead as well. Good think php has another option for line noise though.
What makes you believe Haskell is dead or even dying? New versions of GHC are coming out, and in my experience, developing Haskell has never been smoother (that’s not to say it is completely smooth).
Earlier quoted context omitted.
What makes you believe Haskell is dead or even dying? New versions of GHC are coming out, and in my experience, developing Haskell has never been smoother (that’s not to say it is completely smooth).
And yet, while PHPs, Javas, and even nicher/newer languages like Kotlin, Clojure or Scala have plenty of killer software (software that makes it worth learning a language just to use that library/framework) Haskell has none after 30 years. Zero. Mind you, I know and like Haskell, but its issues are highly tied to the failure of the simple haskell initiative (also the dreadful state of its tooling).
The first typed programming language where I've seen pipe operator |> in action was in F#. You can write something like: sum 1 2 |> multiply 3 and it works because |> pushes the output of the left expression as the last parameter into the right-hand function. multiply has to be defined as: let multiply b c = b \* c so that b becomes 3, and c receives the result of sum 1 2 . RHS can also be a lambda too: sum 1 2 |> (f…
Earlier quoted context omitted.
This is "english-sentence-order-consistent", as it goes. Array filter is "filter this array with this function". Array map is "map this function over this array". But I agree any replacement function should be consistent with Haskell.
One can construct English sentences in the opposite order. There is no singular "English sentence order". "Filter for this function in this array" "Map over this array with this function"
When you use the correct verbiage, the parameter order makes sense.
I had this argument in the PHP community when the feature was being discussed, but I think the syntax is much more complicated to read , requiring backtracking to understand. It might be easier to write. Imagine you're just scanning code you're unfamiliar with trying to identify the symbols. Make sense of inputs and outputs, and you come to something as follows. $result = $arr |> fn($x) => array_column($x, 'values')…
$result = $arr
->column('values')
->merge()
->reduce(fn($carry, $item) => $carry + $item, 0)
->repeat('x');
I'm confused about the rationale behind: |> fn($x) => array_column($x, 'tags') Why is that inlined function necessary? Why not just |> array_column(..., 'tags') ? I mean, I understand that it is because the way this operator was designed. But why?
This syntax is invalid. But it will be possible next year with the proposed partial function application rfc
array_column(?, 'tags')