4 ms·

This is one of those eternal debates I think: on the one hand you have OOP and certain sorts of FP advocates advocating for extremely rich data models that elim

This is one of those eternal debates I think: on the one hand you have OOP and certain sorts of FP advocates advocating for extremely rich data models that eliminate certain classes of errors by design. On the other hand, you have the Unix notion of using a very generic data type (see also Perlis’s “rather 100 functions on one data structure than ten functions on ten data structures”) to maximize flexibility, at the cost of a certain amount of footguns. Personally, I’m discovering more and more that CL’s REPL in SLIME is my preferred shell in part because the CL ecosystem has a rich array of operations on a small number of data-types (without forcing everything into binary streams), but also the ability to define ad-hoc datatypes as needed and a powerful system for manipulating them and integrating the custom data types into existing protocols. Also, the claim that you need n^2 encoder/decoders isn’t actually true: conventions around data formats can reduce it to O(n) in the number of conventions.

TeMPOraL 6y ago
> This is one of those eternal debates Myself I know I'm stuck here. I've been thinking in circles for a while. At the moment, I'm leaning towards rich type system and structured data, but I'm not sure if it can be made fully convenient for the shell. Do you know if anyone attempted to summarize this debate and distill some conclusions, or reframe it in a way that would allow to make progress? > I’m discovering more and more that CL’s REPL in SLIME is my preferred shell In terms of command line or scripting? SLIME is awesome, particularly with its interactive Inspector :). And I wrote my fair share of "scripts" as CL functions. But I can't seem to get used to using the REPL as a shell; I feel something is missing. Most likely convenience functions (that I didn't bother to write for myself yet). That whole paragraph you wrote applies to another Lisp system, though: Emacs. In recent years, I've been leaning on it more and more for day-to-day operations. For instance, I rarely use shell for file operations - I mostly stick to dired. I end up scripting common operations straight in Emacs Lisp, and bind them to ad-hoc UIs (using the Hydra package). And of course utilize well-known packages like Magit (for Git). This recent experience makes me think that we could pull more common shell interactions and turn them from 1D to 2D interface. And I keep dreaming about merging it with PowerShell, in a way that allows Emacs to ingest and manipulate .NET objects nicely, while at the same time exposing its internals to PowerShell. > Also, the claim that you need n^2 encoder/decoders isn’t actually true: conventions around data formats can reduce it to O(n) in the number of conventions. I think this assumes conversions are lossless, which isn't the case in UNIX piping. When you invoke "tools like cut, jq, grep, awk, and sed", it's almost always to filter out most of the text in the pipeline.

TeMPOraL 6y ago

> This is one of those eternal debates Myself I know I'm stuck here. I've been thinking in circles for a while. At the moment, I'm leaning towards rich type system and structured data, but I'm not sure if it can be made fully convenient for the shell. Do you know if anyone attempted to summarize this debate and distill some conclusions, or reframe it in a way that would allow to make progress? > I’m discovering more and more that CL’s REPL in SLIME is my preferred shell In terms of command line or scripting? SLIME is awesome, particularly with its interactive Inspector :). And I wrote my fair share of "scripts" as CL functions. But I can't seem to get used to using the REPL as a shell; I feel something is missing. Most likely convenience functions (that I didn't bother to write for myself yet). That whole paragraph you wrote applies to another Lisp system, though: Emacs. In recent years, I've been leaning on it more and more for day-to-day operations. For instance, I rarely use shell for file operations - I mostly stick to dired. I end up scripting common operations straight in Emacs Lisp, and bind them to ad-hoc UIs (using the Hydra package). And of course utilize well-known packages like Magit (for Git). This recent experience makes me think that we could pull more common shell interactions and turn them from 1D to 2D interface. And I keep dreaming about merging it with PowerShell, in a way that allows Emacs to ingest and manipulate .NET objects nicely, while at the same time exposing its internals to PowerShell. > Also, the claim that you need n^2 encoder/decoders isn’t actually true: conventions around data formats can reduce it to O(n) in the number of conventions. I think this assumes conversions are lossless, which isn't the case in UNIX piping. When you invoke "tools like cut, jq, grep, awk, and sed", it's almost always to filter out most of the text in the pipeline.