Hacker News Reader

Comment by vasilia | Hacker News Reader

> Which is why UNIX shells are a poor man's REPL quite far from what a Xerox inspired user/developer interaction aspired to achieve.

Unix shells are quite good for their purpose. It's not a full-featured programming language. Can you explain what is "poor man's REPL"?

> Pipe based interactions work properly only across CLI based applications

Yes. If you want to find something in logs or looking at any other text data pipes is a good solution. In any other case(like binary data) it will be better to choose GRPC(or any other RPC). I never have seen GUI apps on servers, sorry.

> PowerShell or other Xerox inspired shells don't need kernel support to achieve their workflows.

Good for them :)

View on HN

A poor man's REPL is a shell that fails short of everything that was possible to do across the OS infrastructure with what Lisp/Smalltalk/Oberon/XDE/Cedar REPLs allowed to do.

An approximation of it would be to have a shell that is a Jupyter netbook with access to the whole set of OS APIs, shared libraries and applications, with the ability to jump into the debugger at any given step of the pipeline, and redo the current step.

I bet you saw GUI apps on UNIX workstations, though.

Then again, maybe Steve Jobs was right after all.

https://www.usenix.org/blog/vault-steve-jobs-keynotes-1987-u...

https://www.cake.co/conversations/rZXhqtP/that-time-i-had-st...

> A poor man's REPL is a shell that fails short of everything that was possible to do across the OS infrastructure with what Lisp/Smalltalk/Oberon/XDE/Cedar REPLs allowed to do.

Shell is a command-line interpreter with additional functionality like scripting. Why it should have fully functional REPL? Lisp/ST/etc are programming languages, they are uncomfortable for copying files, moving directories, calling curl or using tar.

> An approximation of it would be to have a shell that is a Jupyter netbook with access to the whole set of OS APIs, shared libraries and applications, with the ability to jump into the debugger at any given step of the pipeline, and redo the current step.

You can use python for this purpose. I don't understand why Unix shell should have all this functionality.

> I bet you saw GUI apps on UNIX workstations, though.

Yes, of course, I have GUI apps on my MacBook, but they don't use piping for inter-process communication because bi-directional pipes are not quite useful like an ordinary RPC.

I guess we'll have to agree to disagree.

> Shell is a command-line interpreter with additional functionality like scripting. Why it should have fully functional REPL? Lisp/ST/etc are programming languages, they are uncomfortable for copying files, moving directories, calling curl or using tar.

Lisp is an interactive programming language. On can run functions like COPY-FILE, RENAME-FILE, ...

The Listener of the Symbolics Lisp Machine has commands which allow prompting of arguments, input menus, completion, object reuse, etc. It's also integrated in Lisp. For example you can list a directory using a command and then use the pathname objects in calls to Lisp functions. One can also use the output of Lisp functions as input to commands. It's an interesting mix of a command interpreter and a Lisp REPL.

Reply on news.ycombinator.com