On 22/10/2011, Patrick Haller <201009-suckl...@haller.ws> wrote: > Hickey kicks unix because although pipes = composability, output and > input = free-form text. We combined data exchange with user interface, > and user interface usually won that fight. > > Say data exchange won; would it help us to rewrite our programs to > output JSON and our shells to pretty-print* JSON?
You pretty much just described TermKit [1]. I think there is something wrong with the shell paradigm, but I'm not convinced JSON-structured IO is the right approach. My suggestion in the earlier mailing list discussion was to allow programs to draw directly to the terminal, in little Xembedded frames, but of course that change only improves the interface: to avoid "let's all write parsers" you'd also have to come up with some kind of typing system like TermKit's MIME headers. Also, the representation of data would be a concern of each program, not of the terminal, which would probably result in ugly. So I think the necessary next step would be to have a strongly typed shell. To pretty-print you'd need to add a polymorphic "à la carte" (multiple dispatch) pretty-printing function for the given data type. The type inference would be done per command, so cat(1) would be of a type such that if you were to try catting an image (directly) to wc(1) it would fail, because the types (Image, String) would not match. You could also have awesome higher-order functions, so 'map' would remove the need for find(1), etc. I know, Unix purists will rage about this added complexity. And it's true, it would be rather more complex. But in my opinion we ought to optimise for effectiveness of use by the user, not efficiency of execution by the machine: we should look at where we want to go and determine the simplest way of getting there, not succumb to nihilism because "it's simpler to stay where we are." But I suspect this approach is too Haskell-like for most people here... [1]: http://acko.net/blog/on-termkit cls