On 22/10/2011, Patrick Haller <201009-suckless_AT_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
Received on Sat Oct 22 2011 - 10:35:00 CEST