191–200 of 323 posts
One criticism would be that ggplot2 uses the "+" to add more graph features, whereas the rest of tidyverse uses "%>%" as its pipe, when ideally ggplot2 would also use it. One of my most common errors with ggplot2 is not utilizing the + or the %>% in the right places.
I have seen plenty pipe use in bash scripts, especially for build and ETL purposes. Other languages, have ways to do pipes as well (e.g. Python https://docs.python.org/2/library/subprocess.html#replacing-...) but I have seen much less use of it.
It appears to me, that for more complex applications one rather opts for TCP-/UDP-/UNIX-Domain sockets for IPC.
- Has anyone here tried to plumb together large applications with pipes?
- Was it successful?
- Which problems did you run into?
This is cool and useful, but not all unix programs follow this convention: * find * cal * vi * emacs * ls These don't use one of standard input/standard output. (edited) and are not fully pipeable. I don't recall seeing a list of programs--tools, in the original description--that distinguish between pipeable and not-pipeable programs. Also, none of the corrective cat/grep code in these threads point out that grep in…
Well find, cal, and ls don't take input at all. And vi (well vim) in fact does. If you invoke it with a - for the file name argument, it will read standard input into the buffer. I can't comment on emacs as I don't use it much.
What about standard output? That is, can vi be used in a pipe?
Earlier quoted context omitted.
The core critique - that everything is stringly typed - still holds pretty well though. >The receiving and sending processes must use a stream of bytes. Any object more complex than a byte cannot be sent until the object is first transmuted into a string of bytes that the receiving end knows how to reassemble. This means that you can’t send an object and the code for the class definition necessary to implement the ob…
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…
> 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.
Earlier quoted context omitted.
If bots were not discouraged on news.yc, I would have implemented a bot for this long ago. Code-block quotes are so atrocious, esp. on mobile devices.
It seems "white-space: pre-wrap" on code block would solve most of the problem. There is also additional "max-width" on the pre that I think is not needed.
What would solve most of the problems is HN actually implementing markdown instead of the current half-assed crap.
I have wondered for a long time why pipes are not used more often in production-grade applications. I have seen plenty pipe use in bash scripts, especially for build and ETL purposes. Other languages, have ways to do pipes as well (e.g. Python https://docs.python.org/2/library/subprocess.html#replacing-... ) but I have seen much less use of it. It appears to me, that for more complex applications one rather opts for…
Some functional programming styles are pipe-like in the sense that data-flow is unidirectional:
Foo(Bar(Baz(Bif(x))))
cat x | Bif| Baz |Bar| Foo
The idea of dataflow programming[1] is closely related to pipes and has existed for a long time, but it has mostly remained a niche, at least outside of hardware-design languages
Sometimes they work great -- being able to dump from MySQL into gzip sending across the wire via ssh into gunzip and into my local MySQL without ever touching a file feels nothing short of magic... although the command/incantation to do so took quite a while to finally get right.
But far too often they inexplicably fail. For example, I had an issue last year where piping curl to bunzip would just inexplicably stop after about 1GB, but it was at a different exact spot every time (between 1GB and 1.5GB). No error message, no exit, my network connection is fine, just an infinite timeout. (While curl by itself worked flawlessly every time.)
And I've got another 10 stories like this (I do a lot of data processing). Any given combination of pipe tools, there's a kind of random chance they'll actually work in the end or not. And even more frustrating, they'll often work on your local machine but not on your server, or vice-versa. And I'm just running basic commodity macOS locally and out-of-the-box Ubuntu on my servers.
I don't know why, but many times I've had to rewrite a piped command as streams in a Python script to get it to work reliably.
Pipes are awesome and infuriating. Sometimes they work great -- being able to dump from MySQL into gzip sending across the wire via ssh into gunzip and into my local MySQL without ever touching a file feels nothing short of magic... although the command/incantation to do so took quite a while to finally get right. But far too often they inexplicably fail. For example, I had an issue last year where piping curl to bun…
This is cool and useful, but not all unix programs follow this convention: * find * cal * vi * emacs * ls These don't use one of standard input/standard output. (edited) and are not fully pipeable. I don't recall seeing a list of programs--tools, in the original description--that distinguish between pipeable and not-pipeable programs. Also, none of the corrective cat/grep code in these threads point out that grep in…