4 ms·

The REPL is the shell. I even used the term "REPL" (and a couple of synonyms too) in my comment. So I do agree it's critical but that doesn't make the language

• nine_k 5y ago
  REPLs are highly interactive. Shells are also needed to run scripts. A Bourne shell implementation without Readline is a pain to use as a REPL, but is a completely adequate shell scripting tool.
  • hnlmorg 5y ago
    Scripting without a shell is just scripting. The "shell" is the UI component. Shell's don't even need to be CLI based either (eg explorer.exe, web shells, etc). https://en.wikipedia.org/wiki/Shell_(computing) https://en.wikipedia.org/wiki/Shell_(computing)
• klibertp 5y ago
  > Your point about how Python shells have had to create syntactic sugar for REPL usage is a good illustration of my point about how it matters a lot. Of course it matters. The fact that Python is hardly suited for one-liners means that, if you want to write one-liners in it, you'll have to first extend or change its syntax and stdlib, pouring time and effort into creating a DSL for the interactive use-case. Some languages basically are DSLs for one-liners, like AWK, jq, TCL, Perl and Raku; some require minimal effort, like Lisp, Smalltalk, Ruby or Groovy; and some require a lot of work to make the syntax you want work, like Python, Lua, or JavaScript (or Java). So yes, the choice of language definitely matters, but in principle every language with a REPL can be made into a shell with more or less effort. The problem is that even when you do make that effort, you're stuck with a shell nice for scripting, but with line-editing capabilities of raw readline at best. I would like to see a framework for creating rich REPLs that would be language agnostic, so that I could get a state of the art auto-completion dialog no matter which language I decided to make into a shell. > Some shells (mine included) ship with hooks to autodetect which terminal emulator you're using and find the best method for rendering those images. That's an interesting bit of functionality, I will take a look. Thanks!
  • hnlmorg 5y ago
    > I would like to see a framework for creating rich REPLs that would be language agnostic, so that I could get a state of the art auto-completion dialog no matter which language I decided to make into a shell. It's doable with existing tools. You have LSP to provide the syntactical framework and there's no shortage of alternatives to readline (I'd written my own[1] to use in murex[2], and open sourced that). [1] https://github.com/lmorg/readline https://github.com/lmorg/readline [2] https://murex.rocks https://murex.rocks The problem you still face is that a good shell will offer autocompletion suggestions for strings that aren't language keywords or function names. eg - file names; and there's a lot of hidden logic in how to do this. Do you build in fzf-like support, just include fzf wholesale but increase your dependency tree, or go for basic path completion. Do you check metadata (eg hidden files and system files on Windows), include dot-prefixed files on Linux / UNIX, etc. How do you know when to return paths, or paths and files, or even know not to return disk items at all? (see next point) - flags for existing CLI tools (assuming you want compatibility with existing tools). Fish and murex will parse man pages to populate suggestions, others rely entirely on the community to write autocompletion scripts. - Are you including variables in your completion of strings. And if so are you reading the variables to spot if it's a path and then following that path. eg `cd $HOME/[tab]` should then return items inside a your home directory even though you've not actually specified your home directory as a string. That means the shell needs to expand the variables to see if it's a valid path. But that's a shell decision rather than a language feature. Some of these lists might take a while to populate so you then have another problem. Do you delay the autocompletion list (bad UX because it slows the user down) or provide the autocompletion sooner. And if the latter, how do you do that without: 1. changing the items under what you're about to select causing you to accidentally select the wrong option 2. communicate that there are update clearly 3. ensure the UI is consistent when slower loading entries might not fit the same dimensions as the space allocated for the list (if you dynamically size your completions to fit the screen real estate) 4. ensure that there's still something present while you're lazy loading the rest of the suggestions; and that those early entries on the completion list are worthwhile and accurate 5. what about sorting the list? Alphabetical? By feature? etc The REPL in murex was inspired by IDEs so I've spent a lot of time trying to consider how to provide the best UX around autocompletion. One thing I've learnt is that it's a lot harder to get right than it seems on the surface.
• webmaven 5y ago
  > Also you can render images in quite a few terminal emulators already. Some shells (mine included) ship with hooks to autodetect which terminal emulator you're using and find the best method for rendering those images. Same word, different concepts. In Smalltalk an 'image' is a memory dump of the VM state, suitable for reloading and resuming, and typically includes a complete development environment: https://wiki.c2.com/?ImageBasedLanguage https://wiki.c2.com/?ImageBasedLanguage
  • klibertp 5y ago
    TBH I used the word "image" in both context: once as a synonym for picture, and the other time meaning Smalltalk image. I think GP was responding to the former use in the quoted text. But, it's actually worth highlighting: GNU Smalltalk is image-based, but has NO GUI by default. So while the image does contain the state of your whole program at the point of dumping it, it does not include the whole IDE together with it. GNU Smalltalk is such a wonder, it's so sad it's not being actively developed :(
    • webmaven 5y ago
      > GNU Smalltalk is image-based, but has NO GUI by default. […]it does not include the whole IDE together with it. […] it's so sad it's not being actively developed :( I suspect that, given the general emphasis in the Smalltalk community on images that are "batteries included", that there is a cause and effect relationship between these lacks.
      • klibertp 5y ago
        That model (image with batteries included) of Smalltalk development does not work in reality in an open source setting. It still works if there's a company behind the implementation, but with typical open source development, where everyone goes on to write things they are interested in at the moment, without looking back on the rest of the ecosystem all that much, this model breaks. It's like maintaining a Linux distro, but with a few orders of magnitude less people and with tooling that never reaches any kind of stability (because it's replaced before it has the chance). Distribution in the vein of Cuis and GST - small, with carefully curated and selected content - are the better way of going forward, unless you're willing to fork some $1k for a commercial license for Visual Works or ST/X. GST is also a Smalltalk than can be embedded in other applications. Try doing that with Pharo. The lack of GUI by default - it exists as a loadable module, BTW - was not the thing that derailed GST development. It was a small, niche project and when some of the contributors lost interest in it, it stagnated and, after a while, fell behind other implementations. If only the JIT in GST was finished, and a few compatibility layers were added on top of its "Smalltalk in Smalltalk", GST could well resurrect. Not that it's going to happen... In the meantime, if you want to play with Smalltalk, I'd suggest using either the open-source ST/X or VW personal use license. Morphic is nice to experience once - use Cuis or Squeak for that. (I'm writing this comment right after the rant about Pharo so I'm probably repeating myself here, but wanted to note that Pharo is the perfect example of how badly the traditional Smalltalk development model fits the modern reality. It simply does not, at all.)