Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

For the Love of Pipes

blog.jessfraz.com

Post reply on HN
Print view View original

241–250 of 323 posts

Re: For the Love of Pipes

#241

Post by barrkel »

chriswarbo wrote: post #169
barrkel wrote: post #80

Earlier quoted context omitted.

Some of the most common monads (especially lists and other collection-like things) feel very much like pipes. list.select { |x| x.foo > 10 }.map { |x| x.bar }... Etc. I wouldn't make the same argument about the IO monad, which I think more in terms of a functional program which evaluates to an imperative program. But most monads are not like the IO monad, in my experience at least.

> list.select { |x| x.foo > 10 }.map { |x| x.bar }... Forgive me if I'm misreading this syntax, but to me this looks like plain old function composition: a call to `select` (I assume that's like Haskell's `filter`?) composed with a call to `map`. No monad in sight. As I mentioned, monads are more about collapsing structure. In the case of lists this could be done with `concat` (which is the list implementation of mon…

Nope, it's not. It's Ruby, and the list could be an eager iterator, an actual list, a lazy iterator, a Mabye (though it would be clumsy in Ruby), etc.

And monads are not "more about collapsing structure". They are just a design pattern that follows a handful of laws. It seems like you're mistaking their usefulness in Haskell for what they are. A lot of other languages have monads either baked in or an element of the design of libraries. Expand your mind out of the Haskell box :)

Re: For the Love of Pipes

#242

Post by msravi »

duckerude wrote: post #121
msravi wrote: post #104

Earlier quoted context omitted.

In Julia, this would be: 1:3 |> x->x+1 |> x->join(x,",") |> length

Small correction (or it won't run on my system): 1:3 |> x -> map(y -> y+1, x) |> x -> join(x, ",") |> length All those anonymous functions seem a bit distracting, though https://github.com/JuliaLang/julia/pull/24990 could help with that.

Ok, in Julia 1.0+ you just have to use the dot operator:

1:3 |> x->x.+1 |> x->join(x,",") |> length

Note the dot in x.+1, that tells + to operate on each element of the array (x), and not the array itself.

Re: For the Love of Pipes

#243

Post by marpstar »

nojvek wrote: post #211

I’m surprised JessFraz who is employed by Microsoft doesn’t talk about powershell pipes at all. Powershell pipes are an extension over Unix pipes. Rather than just being able to pipe a stream of bytes, powershell can pipe a stream of objects. It makes working with pipes so much fun. In Unix you have to cut, awk and do all sorts of parsing to get some field out of `ls`. In poweshell, ls outputs stream of file objects…

I've been following her on twitter for awhile. She went to MSFT only a couple years ago. From what I understand her expertise is in Linux.

Re: For the Love of Pipes

#244

Post by milkey_mouse »

chrisfinazzo wrote: post #152
richardwhiuk wrote: post #117

Earlier quoted context omitted.

is perfectly fine.

Of course, if any of your commands prompt for input, you'll be disappointed that's not always as easy as it appears on the surface. Does anyone have a better way to do this kind of thing?

The standard is expect [1]. There are also libraries for many programming languages which perform a similar task, such as pexpect [2].

[1] https://core.tcl.tk/expect/index [2] https://pexpect.readthedocs.io/en/stable/

Re: For the Love of Pipes

#245

Post by oldmanhorton »

vorpalhex wrote: post #201
masklinn wrote: post #196

Earlier quoted context omitted.

That would break actual code snippet. What would solve most of the problems is HN actually implementing markdown instead of the current half-assed crap.

What is it with so many products (HN, Discord, Slack) building half assed markdown implementations that aren't actually markdown?

To be pedantic, there's debate about what is "actually markdown". No one would say it's the flavor HN implements, but the easiest way to win some games is to simply not play

Re: For the Love of Pipes

#246

Post by assafmo »

yaakushi wrote: post #85

I'm probably nitpicking, but if you're using cat to pipe a single file into the sdtin of another program, you most likely don't need the cat in the first place, you can just redirect the file to the process' stdin. Unless, of course, you're actually concatenating multiple files or maybe a file and stdin together. Disclaimer: I do cat-piping myself quite a bit out of habit, so I'm not trying to look down at the author…

I usually replace cat with pv and gets a nice progress bar and ETA :-)

Re: For the Love of Pipes

#247

Post by Hello71 »

yesenadam wrote: post #145
Hello71 wrote: post #134

Earlier quoted context omitted.

This is a very silly way of writing it though. grep|sed can almost always be replaced with a simple awk: awk '/^x/ { sub("a", "b"); print $2; }' foo.txt. This way, the whole command fits on one line. If it doesn't, put your awk script in a separate file and simply call it with "awk -f myawkscript foo.txt".

>sub("a", "b"); That should be gsub, shouldn't it? (sub only replaces the first occurrence)

Yes.

Re: For the Love of Pipes

#249

Post by gpderetta »

zwp wrote: post #195
laumars wrote: post #92

Earlier quoted context omitted.

I'm not going to argue that UNIX got everything right because I don't believe that to be the case either but I don't agree with those specific points: > This means that you can’t send an object and the code for the class definition necessary to implement the object. To some degree you can and I do just this with my own shell I've written. You just have to ensure that both ends of the pipe understands what is being se…

>> You can’t send file handles > Actually that's exactly how piping works Also SCM_RIGHTS, which exists exactly for this purpose (see cmsg(3), unix(7) or https://blog.cloudflare.com/know-your-scm_rights/ for a gentler introduction and application). That's been around since BSD 4.3, which predates the Hater's Handbook 1ed by 4 years or so.

And that's how Unix is secretly a capability system

Re: For the Love of Pipes

#250

Post by ticklemyelmo »

duckerude wrote: post #107
OJFord wrote: post #81

Earlier quoted context omitted.

But each successive 'command' is a method on what's constructed so far; not an entirely different command to which we delegate processing of what we have so far. The Python: length(','.join(map(lambda n: n+1, range(1, 4))) is a bit closer, but the order's now reversed, and then jumbled by the map/lambda. (Though I suppose arguably awk does that too.)

That's true. It's far from being generally applicable. But it might be the most "mainstream" pipe-like processing notation around. Nim has an interesting synthesis where a.f(b) is only another way to spell f(a, b), which (I think) matches the usual behavior of |> while still allowing familiar-looking method-style syntax. These are equivalent: [1, 2, 3].map(proc (n: int): int = n + 1).map(proc (n: int): string = $n).j…

C# extension methods provide the same syntax, and it is used for all of its LINQ pipeline methods. It's amazing how effective syntactic sugar can be for readability.
Post reply on HN