Functional programming and the death of the Unix Way
newcome.wordpress.com
Functional programming and the death of the Unix Way
1–10 of 34 posts
Re: Functional programming and the death of the Unix Way
#2Often times I’ll want to grab just one part of a command’s output to use for the input of another command. Sometimes I can use grep to do this, and sometimes grep isn’t quite flexible enough and sed is required. The regular expression required to get sed to do the right thing is often complex on its own, and of course the flags need to be set appropriately. If the data format is in columns, sometimes cut can be simpler.
Master Foo nodded and replied: "When you are hungry, eat; when you are thirsty, drink; when you are tired, sleep."
Upon hearing this, the novice was enlightened.
-- http://catb.org/~esr/writings/unix-koans/shell-tools.html
Re: Functional programming and the death of the Unix Way
#3TermKit[1] was a proposal that tried to fix some of those problems by adding two new channels (separating terminal in/out from stdin/stdout data pipes) and using MIME-types (particularly JSON) to the latter.
It got a lot of flack, and I don't agree with everything the author proposes, but I think that part could definitively be improved.
The problem, of course, is backward compatibility: even if you can reimplement and/or wrap the core utils, what about the thousands CLI programs in each distro's repository? You'll end up with an hybrid beast that doesn't really do anything well.
Re: Functional programming and the death of the Unix Way
#4Often times I’ll want to grab just one part of a command’s output to use for the input of another command. Sometimes I can use grep to do this, and sometimes grep isn’t quite flexible enough and sed is required. The regular expression required to get sed to do the right thing is often complex on its own, and of course the flags need to be set appropriately. If the data format is in columns, sometimes cut can be simpl…
Don't koans generally cast off preexisting notions? It seems the philosophy espoused by that story is "don't think too much about the design of your tools".
Re: Functional programming and the death of the Unix Way
#5Often times I’ll want to grab just one part of a command’s output to use for the input of another command. Sometimes I can use grep to do this, and sometimes grep isn’t quite flexible enough and sed is required. The regular expression required to get sed to do the right thing is often complex on its own, and of course the flags need to be set appropriately. If the data format is in columns, sometimes cut can be simpl…
Don't koans generally cast off preexisting notions? It seems the philosophy espoused by that story is "don't think too much about the design of your tools".
I read it as "there are many ways you could solve a problem; rather than obsess over which is The One True Way in All Situations, choose whichever is the simplest path to scratching your itch".
Re: Functional programming and the death of the Unix Way
#6The gist—as I understand it—is that Unix programs are essentially all equivalent to functions : ([String], TextStream) -> (TextStream, TextStream) which limits how one can tie them together and causes a proliferation of text-processing tools (awk, sed, grep, cut, &c &c) which is not as elegant as functional programming. There are already some Unix command-line tools that work on structured data as mentioned, e.g. jsawk[1] is a tool inspired by awk whose scripting language is JavaScript and which works on JSON.
As an aside, I'd like to see people experiment with these concepts on an OS level while consciously targeting Xen or other virtualization systems. Already, Haskell can run barebones on Xen using HaLVM[2] and the successor to Plan 9, Inferno[3], was a virtual machine that could run either on bare metal or inside another OS. I can imagine an entirely new OS would meet some resistance—like Plan 9 did—but supplying an OS intended to be virtualized would let people experiment freely within their existing OS.
[1]: https://github.com/micha/jsawk [2]: http://halvm.org/wiki/ [3]: http://code.google.com/p/inferno-os/
Re: Functional programming and the death of the Unix Way
#7So basically the author is saying:
The UNIX shell pipeline is really just a functional programming language whose functions can only operate on strings. Think how much more powerful, concise, readable, etc. it would be if other data types were supported.
I agree. I don't even think this requires changes at the OS level. Newlisp and Racket's shell attempt might be clunky, and Clojure certainly isn't ready for quick-and-dirty scripts, but it shouldn't be too hard to implement such a language if shell replacement is its main purpose.
Re: Functional programming and the death of the Unix Way
#8Steve Yegge's The problem of emacs goes over some of issues discussed here, although it focused on text processing.
Re: Functional programming and the death of the Unix Way
#9I wonder, does this mean we actually want types as metadata on our shell commands? Type of args, type of stdin, type of stdout, or whatever we decide to call them?
All apps would have to speak a single, more complicated language and we would have to do more explicit translation but it might work out better.
Re: Functional programming and the death of the Unix Way
#10It sounds like the OP wants scsh (The Scheme Shell): http://www.scsh.net