101–110 of 323 posts
Why isn't the pipe a construct that has caught on in 'proper' languages?
Many functional languages have |> for piping, but chained method calls are also a lot like pipelines. Data goes from left to right. This javascript expression: [1, 2, 3].map(n => n + 1).join(',').length Is basically like this shell command: seq 3 | awk '{ print $1 + 1 }' | tr '\n' , | wc -c (the shell version gives 6 instead of 5 because of a trailing newline, but close enough)
Earlier quoted context omitted.
Reformatted to be readable: > Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”. > Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input. > Design and build software, e…
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.
Why isn't the pipe a construct that has caught on in 'proper' languages?
Monads are effectively pipes; the monad controls how data flows through the functions you put into the monad, but the functions individually are like individual programs in a pipe.
Why isn't the pipe a construct that has caught on in 'proper' languages?
Many functional languages have |> for piping, but chained method calls are also a lot like pipelines. Data goes from left to right. This javascript expression: [1, 2, 3].map(n => n + 1).join(',').length Is basically like this shell command: seq 3 | awk '{ print $1 + 1 }' | tr '\n' , | wc -c (the shell version gives 6 instead of 5 because of a trailing newline, but close enough)
1:3 |> x->x+1 |> x->join(x,",") |> length
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…
Earlier quoted context omitted.
Many functional languages have |> for piping, but chained method calls are also a lot like pipelines. Data goes from left to right. This javascript expression: [1, 2, 3].map(n => n + 1).join(',').length Is basically like this shell command: seq 3 | awk '{ print $1 + 1 }' | tr '\n' , | wc -c (the shell version gives 6 instead of 5 because of a trailing newline, but close enough)
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.)
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).join(",").len
len(join(map(map([1, 2, 3], proc (n: int): int = n + 1), proc (n: int): string = $n), ","))
Earlier quoted context omitted.
> When was the last time your Unix workstation was as useful as a Macintosh? Some of that discussion has not aged well :)
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 love the idea of simple things that can be connected in any way. I'm not so much a fan of "everything is a soup of bytes with unspecified encoding and unknown formatting". It's an abstraction that held up quite well, but its starting to show its age.
100% agree. Having to extract information with regular expressions is a waste of time. If the structure of the data was available, you would have type safety / auto-completion. You could even have GUIs to compose programs.
Why isn't the pipe a construct that has caught on in 'proper' languages?
Nowadays, most of the user-facing desktop programs have GUIs, so the 'pipe' operator that composes programs is the user himself. Users compose programs by saving files from one program and opening them in another. The data being 'piped' through such program composition is sort-of typed, with the file types (PNG, TXT, etc) being the types and the loading modules of the programs being 'runtime typecheckers' that reject files with invalid format.
On the first sight, GUIs prevent program composition by requiring the user to serve as the 'pipe'. However, if GUIs were reflections / manifestations of some rich typed data (expressible in some really powerful type system, such as that of Idris), one could imagine the possibility of directly composing the programs together, bypassing the GUI or file-saving stages.