Absolutely right if you're going in and out of Python to create a pipeline of full fledged processes (I suppose you refer to the subprocess module and alike).
What I meant is: you can stay in the environment that supports 'tacit/point-free programming', and make sure you have everything you need:
# 'function' composition is a dash# functions are processestac logs.txt | grep"http://" | xargs wget
Could be just as easy:
# function composition not built-in
# functions are native
compose(read_file("logs.txt"),filter_lines("http://"),wget)
provided you have these functions lying around somewhere.
Granted: Python has these FP concepts built-in, but not as nicely as the unix way. There are better languages for that: Haskell, F#, erlang...
-- my haskell is rusty - but function composition is a dot:-- functions are nativepipeline=read_file.(filter_lines"http://").web_getpipeline"logs.txt"
Interestingly enough, someone already thought up a Haskell shell: Turtle
Yes, I was talking about composing processes like you would at the shell.
I see what you're saying about point-free programming, though. I still think the Unix style is the cleanest, most natural implementation of point-free programming, and I think the fact that it is a genuine stream of processing is a big point in its camp. However, if your Haskell example is accurate, I like it. The examples the Wikipedia article give seem less intuitive and a lot more LISP-y.
I think most programmers would probably find the use of compose in Python a lot less intuitive than nested generator functions, and it's certainly an inelegant implementation of point-free programming. I also wonder if it can eliminate some of the advantages of the generators? It probably doesn't based on the sample implementation, but I'd have to think carefully about if applying partial like that would have unintended consequences, at least in some cases.
Absolutely right if you're going in and out of Python to create a pipeline of full fledged processes (I suppose you refer to the
subprocess
module and alike).What I meant is: you can stay in the environment that supports 'tacit/point-free programming', and make sure you have everything you need:
Could be just as easy:
provided you have these functions lying around somewhere.
Granted: Python has these FP concepts built-in, but not as nicely as the unix way. There are better languages for that: Haskell, F#, erlang...
Interestingly enough, someone already thought up a Haskell shell: Turtle
Yes, I was talking about composing processes like you would at the shell.
I see what you're saying about point-free programming, though. I still think the Unix style is the cleanest, most natural implementation of point-free programming, and I think the fact that it is a genuine stream of processing is a big point in its camp. However, if your Haskell example is accurate, I like it. The examples the Wikipedia article give seem less intuitive and a lot more LISP-y.
I think most programmers would probably find the use of
compose
in Python a lot less intuitive than nested generator functions, and it's certainly an inelegant implementation of point-free programming. I also wonder if it can eliminate some of the advantages of the generators? It probably doesn't based on the sample implementation, but I'd have to think carefully about if applyingpartial
like that would have unintended consequences, at least in some cases.I think so, too. You can make a nice 'fluent' DSL out of it, though.
..... ingenious.
I'm still trying to brain this, its possibilities and its limitations but... wow.
A bit of commentary would be very welcome :-)
I'll expand it in a full fledged post :) Or 'leave it as an exercise'?
I either love this or hate it, I can't decide. Bravo, sir!
Somehow, I have hit the 'publish' button on dev.to/xtofl/i-want-my-bash-pipe-34i2.
I've only skimmed the article so far, but it looks like a good one. I like the title! 😁
@xtofl , @Cliff , I have finally gotten round to this, I think you will be gleefully dismayed.
dev.to/taikedz/shellpipe-shellpipe...