Hacker News new | past | comments | ask | show | jobs | submit login
CLUI: Building a Graphical Command Line (repl.it)
596 points by amasad 6 months ago | hide | past | favorite | 184 comments



As somebody who worked professionally with Adobe Premiere I think the criticism of its UI misses the point. Premiere was never meant for hobbyists (reflected by it's actual name: Premiere _Pro_).

The only valid point made here is that it is hard to learn for someone who never used any editing software at all. But it certainly isn't slow or "unfocused". That source monitor is on screen for a reason. Keyboard shortcuts will always be faster than moving your mouse around. And by the way: Premiere has a modular interface, so if you hate the clutter or don't need it, you can get rid of it.

If you are the person who just wants to edit some stuff together once a year Premiere _Pro_ is not for you. Turns out software interfaces that are meant to be used by people 8 hours a day for weeks at a time follow different design paradigms than stuff made for amateurs. I'd go completely insane if I had to edit a movie on anything simpler tho.

I like their TLI ideas, but I am honestly a bit alergic against designers who lack the phantasy of realizing that sometimes a UIs complexity is a reflection of the complexity of the problem it helps to solve in conjunction with the level of control you want to give to the user.

Steep learning curves should be avoided — sure — but sometimes they are necessary to shave of that extra second. Something that multiplies if you do it hundred times an hour.

Premiere is like vim: not for everybody, but if you wield it in the right way, there is not much that can beat it.


> I like their TLI ideas, but I am honestly a bit alergic against designers who lack the phantasy of realizing that sometimes a UIs complexity is a reflection of the complexity of the problem it helps to solve in conjunction with the level of control you want to give to the user.

I think what's key here, and why I like the direction of the work in the linked post, is that none of the affordances of the UI they're augmenting -- the command line -- are being taken away,* merely made more visible based on context. I think that gets at a hole in the notion that UI complexity mirrors domain complexity -- in the case of Premiere, surely the entirety of what's on the screen doesn't mirror the complexity of the workflow you're executing right now, it's much closer to the sum total of everything you might ever do. Not that a UI based on progressive disclosure would be trivial or maybe even possible to implement effectively for something like a professional video-editing application, but it's worth considering whether something like that is merely a local maximum in the space of all possible UIs.

* I guess in the case where you know exactly what you want to do and the added context might distract or slow you down, that's an affordance being removed, but I think it's outside the scope of what we're talking about here -- especially because, given the scope of the command line, you will inevitably have to do something with it that involves an invocation that isn't right at the tip of your fingers.


I agree that they did the right thing for the domain of the TLI, as your comment captured.

And existing editing GUIs might very well be a local maxima — however we designers need to be careful in quickly condemning existing solutions that we don't understand by calling them "unfocused", "slow" or "ugly".

It is the responsibility of any designer to be more aware than the rest of tradeoffs like these — making it look good is merely a nice to have you can achieve as well. To decide that for a domain as complex as editing demands at least some degree of awareness of the common problems an editor needs to solve, as your software or UI will have to solve them as well.

Sometimes this comes with a learning curve, as your user will have to learn how to tell the computer what they want. They will have to learn some language that allows them to express this, if they don't want the computer to take the wheel and just assume what they want. And that very language is what makes it complex and hard to learn, and there is not much way around it. Might there be a different language that lets you express more things with better ease while beeing easier to learn? Sure. But will it still be harder to learn a language which allows you to express a lot, compared to a language which allows you to express only little? Yes - as well.

That beeing said: I they made all the right usability choices on their own thing there, my comment was more an aside stemming from my own values as a designer.


Your comment reminds me of a conversation here about how some people confuse complexity and disorganisation, particularly when they don't have much expertise in what they're looking at. So they "organise" everything, but in the process remove all the power, and what they end up with is a beautiful white elephant.


I once had a college HCI project where I designed the simplest possible TV UI (menus + on-display affordances + remote affordances.) I think I ended up with five buttons, and one menu. All the "settings" were automatic calibrations done during setup. You could re-trigger them by running the setup wizard again, but that's it.

Now, I am probably not a "professional TV user"... but neither are 99% of people who use TVs. Even if most of the complexity of a TV is important to the few people who, say, install one as part of an IMAX-certified home-theatre setup, most people want a TV that "just works" and gets out of their way—even if it's working in a sub-optimal way! They want a remote that can 1. turn the thing on, 2. control volume on their TV and/or soundbar; 3. switch input sources; and 4. proxy through to menu around in the streaming boxes/game consoles/etc. they own; and that's it. You don't even need the setup button on there—you can get up and press that on the TV itself.

The funny thing is, by default, TVs both have more functionality, but actually fewer desired features, than what I'm describing. People tend to have to buy a ridiculous 100-button (or digital touch-screen) Harmony remote just in order to get "turn on the TV" and "menu around in your streaming box" on the same remote. Why?


It's why I use intellij instead of e.g. vim at the moment, I can use a lot of the features and they provide a definite advantage over my previous editor, VS Code, which was also pretty densely packed with features (although it has a much cleaner UI).

The other question is discoverability. I mean I'm sure vim is incredibly powerful, but none of the features are obvious and you have to trudge through two decades of websites to discover anything.

I've been unable to find out (actually I haven't really looked) how to use vim as a software developing tool (with basic features like autocomplete/suggest and error reporting)


I'd arvise you to try vim again. Carve out two days, take your time, dive in and build the ide you want.

I tried all modern ides, and while vscode is certainly awesome, i always go back to my vim :-)


Discoverability certainly is an issue with vim – but it isn't really with Premiere. What I was alluding to with vim was more the combinatoric aspect of powerful tools. Creating software that solves one specific problem with a beautiful UI isn't that hard – creating something that solves a very broad range of problems is infinitly harder, because you need to give the users a language in which they can tell the machine what they want. That "language" can be shortcuts and chainable commands like in vim or it could be graphical, using a timeline, context menues, drop downs, symbols etc.

However: the more expressive this language has to be and the more problems you should be able to solve with it in precision, the steeper the learning curve will get. And as with spoken language, there are hard to learn languages that let you express certain aspects very precisely and there are simpler languages that might be easier to learn but make it harder to express certain things (e.g. "You" in English vs "Du"/"Sie" in German vs. all the formal variablity of Japanese).


I use IntelliJ with IdeaVim plugin, that makes it's editor behave like a vim editor (at least pretty close). It is the best of two worlds: real IDE with a powerful and efficient text editor.

As for learning VIM, it is a complex professional editor, and I personally recommend just reading a book about it.


Autocomplete with control-p, error reporting from your compiler, outside of vim, although there are plugins for it if you wish (I consider it something of an antifeature, as it distracts me from finishing the code I'm trying to write).


>you have to trudge through two decades of websites to discover anything

>type :help<Enter> or <F1> for on-line help

This is not for show!


>I've been unable to find out (actually I haven't really looked) how to use vim as a software developing tool (with basic features like autocomplete/suggest and error reporting)

Vi is a text editor with an incredibly powerful language to edit text tied to keyboard keys.

Emacs is a lisp interpreter that's optimized for text editing.

They are not IDEs.


GNU Emacs comes with a Lisp IDE. Compiler, Interpreter, interactive read-eval-print-loop, backtrace, stepper, code formatting, profiling, source-level debugger, ...


What do you consider to be the defining set of features for an IDE, and what do you think Vim and Emacs are lacking from that list?


They are not integrated.

That said, vim and emacs can be in a way a component of a DIY IDE - you just need to put the work in and build it yourself. I exclusively use vim with a handful of useful plugins, scripts, and additional CLI tools in other terminal splits.

The terminal is my IDE.


The standard way to use Emacs is as an IDE; you use M-x compile to run the compiler in a window under Emacs and M-x gdb to run the debugger in a window under Emacs, in both cases with hypertext capabilities. These are standard packages included in a default Emacs install, although you may want to bind them to more convenient keys. (I bind [f5] to recompile.) You do not need to run Emacs in a terminal, and copy and paste to and from Emacs (not to mention things like viewing SVGs you're editing) works better if you run it in a window on its own. You do not need to "put the work in and build [an IDE] yourself" if you are using Emacs.

(Of course if you're writing programs in Elisp, Emacs is a more tightly integrated IDE, but the success of Emacs, org-mode, Magit, and Amazon notwithstanding, Elisp is not a very good programming language. Also, if you run Emacs in a terminal, you can quite reasonably use it over a low-bandwidth, high-latency ssh -C connection, and it becomes good for remote pair programming, which is not true of running Emacs in VNC. I haven't tried running it in Xpra.)

Historically Emacs started up far too slowly and used far too much RAM to be convenient to use it in the way you're describing, as a text editor invoked by a larger IDE; I remember waiting over a minute for a new Emacs process to start up in the mid-90s. Nowadays it might be reasonable, but it still takes almost 4 seconds on this laptop, which I find to be a painfully long wait for opening a file. Also, Emacs's language-agnostic autocomplete M-/ works a lot better if you have a lot of files open in the same Emacs session.

Although there are packages that configure Vim to work the same way, it is more common to use Vim in the way you describe, as a component of the IDE rather than an IDE in its own right. And Vim has the great advantage that it starts up instantly, and the advantage or disadvantage that its equivalent of M-/ (^P and ^N) is buffer-scoped, so it doesn't matter if you have more files open.


> Nowadays it might be reasonable, but it still takes almost 4 seconds on this laptop, which I find to be a painfully long wait for opening a file.

That is one of the use cases for emacsclient/Emacs server.


Yes! I should have mentioned that. I mostly use emacsclient as an $EDITOR for git and similar programs in Emacs shell-mode, but you can also use it as a version of Emacs that you can run quickly in a tmux window, if that's what floats your boat!


They can be interactive development environments if you configure them as such.


They are certainly evangelized as IDEs.


I learned Photoshop, Flash, Final Cut Pro, Ableton Live and multiple IDEs.

I found they were, like CLIs, all very similar.


That's because they were based on the original hardware for linear video editing, which had a metric shitload of buttons and knobs you'd have to know. I could see using a minimal CLI for something like this, but it wouldn't be useful for those guys who learned on linear equipment then had to switch to the nonlinear equipment, which already had a steep learning curve since they were used to a more linear process. I don't know why the author of the article picked Premiere as an example of a "bad UI", because it is pretty close to perfect for that particular time in video editing.

Source: I am experienced in several nonlinear and linear video editing technologies from the 90's and early 2000's, since my father was in the videography business.


It would be useful for somebody who has no experience in video editing, but would like to cut together some footage taken on their phone. And yet, even the video editing software aimed at beginners and novices are crazy complicated.


Oh yea, today we can do so much more with less UI, but I'm not into video editing so I'm not sure of what's available. I'm sure there are simpler apps for regular people now.


Please let me know if you happen to stumble upon one. Every once in a while, I get the desire to take a small clip of a larger video to use as a gifv. I've yet to find a single video editing program that makes this very simple thing easy for somebody who has no idea what he's doing.


In the past, QuickTime (Pro?) was excellent for this sort of thing; you could just mark the section you wanted right in the player window and export a new clip. I don't know what the present situation is with QuickTime, and obviously that's an Apple solution.

There are basically two classes of editors:

* "pro" editors, like Premier, and (old?) Final Cut Pro * "home" editors, like iMovie, Windows Movie Maker, OpenShot etc.

You want something from the latter category. The general idea is:

1) Add your source video file to a new project 2) Drag that video onto your timeline 3) Edit the timeline to crop your video (various methods depending on user preference) 4) Export your new clip

You haven't mentioned your platform, so lets give a simple example using the free, cross-platform OpenShot:

1) Add your source video file to a new project 2) Drag that video onto your timeline 3) Grab the edges of your video clip in the timeline, and drag them to crop your video 4) Export your new clip

Short YouTube video (not mine) demonstrating this visually (you don't actually need to select the razor tool): https://www.youtube.com/watch?v=P8zmqfXXS60

---

Is this an easy enough method? I think to get any easier than that, you may be looking at a purpose-built tool to do only the simple thing you want, rather than a general purpose editing tool.

---

edit: I didn't see your file format requirement. I honestly don't know anything about .gifv; it appears to not actually be a file format at all, but some tomfoolery that Imgur is engaging in? You'll have to export to an actual video format (say webm or mp4) and figure it out from there.


your point about UI complexity reflecting the complexity of the problem + level of control is totally true in regard to most tools - but one of the key points at replit is that we are trying to create a programming environment that appeals to both beginners and experts. we don't want to block out hobbyists. that's really the main point of comparison to Premiere- if someone is interested in learning about film production, you shouldn't have to go to iMovie and then "graduate" to Premiere (or Canva -> Photoshop, SketchUp -> Autocad). tools should grow with you (ideally)!

complexity is always relative but I think the end point here is that there's always room for simplification and shallower learning curves, even for advanced/pro users.


I agree that digital tools don't have to be one thing, as you said they can grow with you (or you change them, like going from textedit to vim or from notepad to sublime text).

While there are solutions that both experts and beginners can benifit from (like Blenders 2.8 UI overhaul), everybody who has done every manual job ever might have learned that the optimized professional tool you used has a learning curve for a reason: when you know how to use it, it is literally faster and gets less in your way than the friendly intuitive and self explainatory variant of the tool.

The kind of dynamic scaling you mentioned is always desireable, but not always possible without introducing considerable complexity into a software — especially in complex domains like editing, audio or 3D the hard thing usually is to develop a language of adjectives and verbs the user can throw onto the objects they work with. And learning this can feel like learning a new language for a reason. And like with languages a simple combination of grunts and gestures might be enough for certain communicative goals, but sometimes it pays off to learn the actual developed language to really express what you want.

The most powerful software that gets in your way the least I ever learned had incredibly steep learning curves, but once you've got it, it felt like speeking a language you mastered.

We are literally commanding machines here — and problems of high complexity paired with a high level of control usually demand a very precise communication. So while I could e.g. imagine an editing suite which interprets your grunt and edits a bunch of videos for you using AI, you are still losing a level of control there: because the computer has to assume what you are unable to tell it. There is literally no way around it.

Ever wondered why the language used in the military, in an operation room or on a film set is so specialized and hard to understand for amateurs? It is because they need that level of control to communicate in order to get the desired result.


You are not wrong, but criticism levied at Adobe products (and I haven't used them in 5 years) is often actually unbeknownst to the person making the criticism, about the lack of state control and visibility in the UI. You can mess up your UI state to such a level that the application is unusable. The undo/redo mechanism affects the data (movie, the image, the sound) but it has no effect on the state of the UI. Adobe did implement "reset workspace" or whatever it was called, this was a gift from the gods, but it did not go far enough.

Tooling this complex needs to provide controlled methods for controlling state, both in the tooling and that tooling's impact on the data it is operating on.


Reminds me of a problem I just had with Eclipse's debugger (which sadly seems to be one of the most capable GUI debuggers on Linux).

I set breakpoints and they were ignored.

https://stackoverflow.com/questions/4388192/eclipse-doesnt-s...

One time it was the top answer -- I had "skip all breakpoints" on. How it got on, I have no idea, since I did a fresh install of Eclipse pretty recently.

Yesterday it was still ignoring my breakpoints even though that was NOT on. Why? I have no idea.

So I still debug with gdb when the 'bt' command suffices. When I want to do more advanced stuff, I'll fire up Eclipse maybe, but I'm honestly loathe to do so.


XKCD's "Is it worth the time"[1] grid seems appropriate here. Amazing how often I keep coming back to it, and how it really does play out.

[1] https://xkcd.com/1205/


A classic. However I like to note: sometimes it is also worth shaving something off that just annoys you, even if it doesn't take that much longer.

Annoyances are a bit harder to quantify, but they also add up over the weeks.


Annoyances have an effect beyond the time they take up: by definition they hang about taking a little bit of mental energy away from subsequent tasks.


yeah and humans short term memory is quite limited also automating away these small things reduces the risk of human error.


Trivial annoyances can be fixed by CBT (fixing your brain to not overeact), without needing to spend time fighting the world.


Ha. I've been trying to fix my brain with CBT to not overreact for...20? years now.

Sometimes it is just easier to fight the world.

I feel my drive to de-frustrate the world make me a better engineer/designer.


I agree, fixing and creating things is what we do. It makes us happier and better.

Another demotivating argument one might hear often is that building X, learning Y or using Z has no business value because there already exists something that you could do/use.

That argument makes sense if your primary concern is to solve a particular domain problem AKA you are a 'business person'. But a craftsman/engineer/designer etc. Your primary value comes from your skills and knowledge.


A couple of useful additions would be:

1. You can multiply the number by amount of users of your automation.

2. If your automation is valuable to others you gain social attraction or financial leverage or both/similar.

I'm a programmer first and foremost, so the following things are true in my case as well:

3. Automating a task can lead to learning valuable lessons about: automation itself, the task, any tools/languages you use to automate it. This cannot be encoded easily and is not deterministic. As a programmer learning new skills, improving my craft and gaining pieces of domain knowledge is my primary way of investment.

4. Enjoyment of doing the automation, non-deterministic value.

5. Avoiding suffering, the task might not be time consuming but "hard".

Good examples of 5:

* interfaces or synchronizations of values that are not failure proof, so you need to concentrate, which is taxing.

* the task is boring it itself (often the case)

* the task is associated with boring/stressful/generally negative things.


Might be interesting to people here: this blog is hosted on Repl.it on a single repl/container[1] (2GB memory, 2vCPUs[2]) that's also powering IDE functions like editing, collaboration, chat, intellisense, etc.

We're able to fix typos and bugs and have it live-deployed as it's serving traffic. I recorded a gif here of what it looks like from the inside: https://twitter.com/amasad/status/1235742525056380929

Where is the fabled "hackernews hug of death" if a tiny container can handle the traffic? :-)

[1] https://repl.it/@turbio/replit-blog

[2] https://repl.it/site/pricing


This should be upvoted more!

For reference the other HN post and the comments therein - "Let’s use Kubernetes. Now you have eight problems" - https://news.ycombinator.com/item?id=22491170


Hug of death is for non static content. And sometimes people unnecessary dynamically generate their static content.


Unfortunately we fall into that bucket. It's a dynamic app :-)


Where do I go to add language support? Given you have BrainFuck and LOLCODE but not Perl.


https://repl.it/perl6 If that stops working it means we moved it to https://repl.it/raku Check it out. It's not actively supported but we hope to make it official soon


It appears to me that both Perl 6, as well as Raku, are NOT supported at repl.it (anymore)


They got the URL wrong.

https://repl.it/python 404s and I rather suspect they support python. ;)

https://repl.it/languages/perl6 and https://repl.it/languages/raku both work. :)

They're both 2019.03.1 so their "raku" is presumably raku in name only. (Eg doesn't support $*RAKU etc.) Be nice to see it upgraded to a real 2020 raku.


That looks like the previous version shipped with Rakudo Star. A new version was published a very short while ago, so perhaps they will update to 2020.01 soon enough.


You are not using PHP for every request


Even worse. Using node.js


> On a technical level, a CLUI command is conceptually similar to a file path or URL. Since a complete CLUI command is simply a path down the command tree, each potential subcommand is like a portion of a file path or URL. Flags, on the other hand, function like query parameters. CLUI’s resemblance to URL paths means you can send someone a complete, executable CLUI command as a URL. They’re mapped 1:1.

This is really cool.

> Since we have a GraphQL backend, we know all the potential fields and arguments a client can use. By using an introspection query we generate a tree of commands/sub-commands that map onto their respective resolve functions. Now, to add a new admin command all that's needed is a new field on a GraphQL type.

And that's really really cool.

The main thing I see that could be improved would be a clear, simple underlying model or metaphor, a semantic layer that sits between the CLUI and the GraphQL backend, to unify and simplify the various contexts and languages and runtimes and whatever.

I've been toying with a UI demo that unifies GUI and CLI through a dialect of the Joy language. Everything you can do at the CLI can be done through the mouse, and everything done through the mouse has a corresponding textual representation as Joy code. It's inspired by Oberon OS and Jef Raskin's "Humane Interface" (among other influences.) I haven't integrated widgets (yet) because you mostly don't need them, mostly.

W/O getting into a lot of details, there are no menus nor buttons because any text can be used to activate any command and/or enter any data; there are no forms because the UI metaphor (Joy) is stack-based so you just put values onto the stack; and so on.


Autodesk Maya has always been both CLI and GUI based. Every GUI interaction generates a visible CLI command you could have typed to accomplish the same thing. It’s been the way since PowerAnimator in the 90s


So does Stata, for all it's warts [most common syntactical structure of commands is <command> <required positional arg>, <optional unamed positional> <name of optional named>(<optional named>), as in `twoway function y = 3*x^2, range(-10 10) xtitle("expansion rate")`]


I think AutoCAD has been this way for a long time too. The first version I used was 2.14K+ADE; you could invoke any operation from the keyboard (and often had to) but I don't remember if selecting from menus with the mouse would generate the CLI command. In later versions of AutoCAD it did.


Yep, automating CSG, transforms etc. from the command line in AutoCAD was very powerful. I fondly remember a Stonehenge 3D model project from school.


I don't think it was possible to automate anything in 2.14K+ADE (that was before AutoLISP), and its 3-D support was almost nil, let alone CSG.


Your project sounds super cool! Do you have a demo or a DHTML mockup?

If I understand the idea, when you want to invoke an operation that requires four arguments, you first push four arguments of the right type onto the stack (by clicking them or something) and then you invoke the operation by clicking its name (maybe after typing it)? How can you tell when you have the right types of arguments on the stack for the operation — does its name light up? If you want to invoke the operation, how do you find out what the types and purposes of those four arguments are — do you mouse over the name? How are you handling undo — can you just revert to previous stack states, or is there a lot of important state that isn't on the stack?


Cheers!

> Do you have a demo or a DHTML mockup?

I do, but the project's in a weird state right now. It was in Python 2 (and that code should still work fine) but I'm transitioning to a Prolog implementation, and I haven't nailed down the [G]UI for that yet.

The original Python-based project is here: http://joypy.osdn.io/

The code on PyPI is old, the latest code is here: https://osdn.net/projects/joypy/scm/hg/Joypy/summary

There's some Prolog code in there under the "thun" directory but the main new project isn't published yet.

The Joypy code contains two GUI demos, one in joy/gui based on Tkinter (TCL/Tk widget lib), and the other in joy/vui based on SDL via PyGame that renders the GUI using low-level graphic primitives (blitting a bitmap font, etc.)

> If I understand the idea, when you want to invoke an operation that requires four arguments, you first push four arguments of the right type onto the stack (by clicking them or something) and then you invoke the operation by clicking its name (maybe after typing it)?

Yes, exactly.

> How can you tell when you have the right types of arguments on the stack for the operation — does its name light up?

The Tkinter GUI highlights commands when you hover: green if the command type-checks, orange if not (and it won't be run), and grey if the type-checker can't figure it out. (It's crude and incomplete, some details here: http://joypy.osdn.io/notebooks/Types.html )

The "vui" (visual user interface, a distinction w/o a difference; I suck at names) doesn't do that. It's meant as a model to be reimplemented later in Joy so I'm keeping it as simple as possible. It's basically just a text editor that only has to be good enough to bootstrap itself into something more like the Tkinter GUI.

> If you want to invoke the operation, how do you find out what the types and purposes of those four arguments are — do you mouse over the name?

There is a simple "open doc" command (that can also be activated directly from the mouse using "mouse chords", or from a function key), so you can type:

    <Newline>[FOO] opendoc<Ctrl-Enter>
    
anywhere to get the docs on FOO command. The UI has a default system log as the main user interface (sort of like a terminal; Oberon OS has one) so I just print the command docs to that.

Without getting off on a big tangent, Joy code requires a lot of documentation to understand (although it does become readable once you have some practice, like APL or Forth) but the code tends to be very concise, almost like haiku. (It's like Forth, you use lots of little definitions and build up a DAG, and refactoring gives what some call "semantic compression".) So basically you have to have detailed docs, but you kind of generate those as you derive new Joy functions. (Examples: http://joypy.osdn.io/notebooks/index.html )

(Have you ever used Factor lang? I really like how they have integrated hypertext docs in their "monitor" UI. I've often thought that the thing to do would be to write a thin Joy-to-Factor translation layer and leverage all their amazing work.)

I imagine a mature Joy-based OS+GUI would have a ratio of docs to code of 1000:1 or greater, and resemble an extended mathematical treatise (lots of prose and some equations.)

> How are you handling undo — can you just revert to previous stack states,

Well, the Tk Text widgets have an undo facility built-in (which is nice) but uh, I just store everything in a git repo, including the serialized ("pickled") stack. You can use any git tools you like on it. (There is as yet NO internal interface to history, although the TK undo is enabled for convenience its history is orthogonal to the git history. I have a lot of ideas about how to represent history to the users but they aren't in the demo yet.)

> or is there a lot of important state that isn't on the stack?

Nope. :-) I'm using a Continuation-Passing Style in the Joy implementation (combinators work by modifying the pending expression rather than recursive calls into the interpreter) so all state is either in the current stack or expression. (You can define new constant commands that are then effectively named variables stored in the dictionary, but you shouldn't.) This enables a lot of cool things, like easy concurrency, task migration, etc.

- - - -

BTW, your post on memory models ( http://canonical.org/~kragen/memory-models/ ) was very helpful to me, I read it just a few weeks ago! I'm working on a simple compiler for Joy and I had to read up on all that to decide how to do the tricky bits. (I'm going with the "list-structured memory" from SICP for now.) Cheers!


This sounds really interesting! I'm happy my article was helpful to you.

I really like how your notebooks integrate (judiciously chosen) execution trace display with explanation. I think this is something literate programming benefits a lot from. I wonder if there's a way to include a smooth gradient from specific examples like your V('80 P') to more general cases, either with abstract interpretation or a Bret-Victor-style overwhelming battery of data points.

I watched an Aaron Hsu talk from Functional Conf not long ago where he claimed that Co-dfns has a comment-to-code ratio of 400:1 or something, because his dissertation is the comments, and there are several pages of it per line of code. Having seen the glyphs in the talk, I haven't dared to open the dissertation yet; I'm afraid it may open a gate, causing cenobites to come out of xpdf.

I really like RPN calculators because of their immediate feedback — http://canonical.org/~kragen/sw/dev3/rpn-edit is one keyboard-driven prototype with a structure editor — but I think that while they reduce the gulf of evaluation, making it easy to see if the step you just took was the right step, they may expand the gulf of execution, making it harder to figure out what you need to do to get closer to your goal.

An extreme version of this, which is not RPN, is

    InputStream s = foo();
    return new BufferedReader(new InputStreamReader(s, Charsets.UTF_8));
where it takes considerable familiarity with java.io to immediately know how to get a BufferedReader given only an InputStream, because of the intermediate step via an InputStreamReader.

Today I was thinking about the cisco IOS CLI described in https://news.ycombinator.com/item?id=22498665#22500151 — something I haven't used in a long time — and it occurred to me that LOGO or REBOL is close to being FORTH or Joy spelled backwards. Instead of reverse Polish notation, it's forward Polish notation, enabled by all the functions having fixed arity. So, if you're writing left to right, you write your code top-down, as in C or bash, instead of bottom-up, as in Smalltalk or FORTH. You've built a noun-verb system, like the Macintosh, while Unix and IOS verb-noun. Is one or the other globally more usable? I don't know! The Java above is hard for programmers new to Java to write, but it's verb-noun.

One thing that has occurred to me is that in purely functional contexts, in a verb-noun system, it might be reasonable to execute every type-applicable operation and display the results, maybe as a balloon next to the operator name; then the user need only select which of all the possible next states they want to go to. So, for example, if you have two numbers on the stack, you might have their sum, their difference, their product, their quotient, and the results of dup, drop, and swap, each displayed next to the relevant operator; then you can select the desired operator to go to that stack state. That seems like it might help with the gulf of execution, providing you with one step of lookahead. But maybe it would be more distracting than helpful?

But then, you could imagine doing the same thing with a verb-noun system, as long as all the arguments have reasonable default values so that you can somehow get useful visual feedback on the results even before you have chosen all the arguments; for example, for arithmetic operations like that, the default value might be λx·x, the identity function, so that you see graphs of all possible results.

I used to chat with Slava when he was first working on Factor (before he started working at Apple) but I'm embarrassed to admit I've never actually tried Factor. (Or Joy!) Is there a screencast of the hypertext features you mention?

What do you think about Cat?


> This sounds really interesting!

Cheers!

> I'm happy my article was helpful to you.

It was just the thing! Very helpful. Thank you for writing it.

> I really like how your notebooks integrate (judiciously chosen) execution trace display with explanation. I think this is something literate programming benefits a lot from.

Cheers again. I find those traces aesthetically pleasing in and of themselves. I can imagine a (strange, niche) art gallery that had large prints of them on display. Jupyter notebooks have so many good things going on. (Not that they're perfect, but they hit a sweet spot IMO.)

> I wonder if there's a way to include a smooth gradient from specific examples like your V('80 P') to more general cases, either with abstract interpretation or a Bret-Victor-style overwhelming battery of data points.

I'm sure there is, there are so many possibilities. Just the traces alone could be animated or made into (partial) graphs (have you seen http://pythontutor.com/ ?)

Concerning abstract interpretation, if you squint a little, the Prolog code already does that. Markus Triska suggested using the CLP(FD) integer constraints for the math primitives, which was brilliant, so it's doing a kind of abstract interpretation. You can give it a completely general stack "type" (just a logic variable) and it will tell you, e.g. '+' is:

    int(A), int(B) -> int(A+B)
and so on. It's also pretty easy to replace the main operators to get a different (but related) semantics, and I'm pretty sure that relates to what Conal Elliot's "Compiling to Categories".

I'm not sure which Bret Victor thing you're thinking of, but it's easy to do things like evaluation over a domain (rather than a single value), or partial evaluation (again with specific values, domain, or logic vars.) And you can do that trick where you give it the result and ask it to generate programs (as in http://webyrd.net/quines/quines.pdf) and variations on that. I think it would also be easy to e.g. add slider widgets and have them evaluate expressions (possibly already partially evaluated for efficiency) when the user "sweeps" them.

Also, and this is more hand-wavey, I think there should be a way to use the traces to extract information about how programs unfold over time. What I mean is, the traces typically have clear initialization and completion phases with a loop or recursive function in between, those repetitive parts show up clearly in the traces, and it should be possible to overlay them on each other and find the static vs dynamic terms, and maybe do something with that information. (Unroll loops or create new versions that do less work or whatever. Hand wave.)

> I watched an Aaron Hsu talk from Functional Conf not long ago where he claimed that Co-dfns has a comment-to-code ratio of 400:1 or something, because his dissertation is the comments, and there are several pages of it per line of code. Having seen the glyphs in the talk, I haven't dared to open the dissertation yet; I'm afraid it may open a gate, causing cenobites to come out of xpdf.

Heh heh heh. Yeah, that makes sense if you're working in a system that allows for easy refactoring: code should approach the Kolmogorov complexity limit of the problem it solves as it ages, eh? Ripen instead of rot.

> I really like RPN calculators because of their immediate feedback — http://canonical.org/~kragen/sw/dev3/rpn-edit is one keyboard-driven prototype with a structure editor —

Okay that is freakin cool. I'm probably going to have steal some ideas from that if you don't mind? I like the idea of being able to edit and re-evaluate sort of like a spreadsheet. And making the structure of the expression visible like that seems like it would be very useful.

> but I think that while they reduce the gulf of evaluation, making it easy to see if the step you just took was the right step, they may expand the gulf of execution, making it harder to figure out what you need to do to get closer to your goal.

> An extreme version of this, which is not RPN, is

    InputStream s = foo();
    return new BufferedReader(new InputStreamReader(s, Charsets.UTF_8));
> where it takes considerable familiarity with java.io to immediately know how to get a BufferedReader given only an InputStream, because of the intermediate step via an InputStreamReader.

That's where Joy seems to shine, it's been pretty easy so far to set up the context for a function I want to write and then derive an implementation in a kind of mathematical way.

> Today I was thinking about the cisco IOS CLI described in https://news.ycombinator.com/item?id=22498665#22500151 — something I haven't used in a long time — and it occurred to me that LOGO or REBOL is close to being FORTH or Joy spelled backwards. Instead of reverse Polish notation, it's forward Polish notation, enabled by all the functions having fixed arity. So, if you're writing left to right, you write your code top-down, as in C or bash, instead of bottom-up, as in Smalltalk or FORTH. You've built a noun-verb system, like the Macintosh, while Unix and IOS verb-noun. Is one or the other globally more usable? I don't know! The Java above is hard for programmers new to Java to write, but it's verb-noun.

> One thing that has occurred to me is that in purely functional contexts, in a verb-noun system, it might be reasonable to execute every type-applicable operation and display the results, maybe as a balloon next to the operator name; then the user need only select which of all the possible next states they want to go to. So, for example, if you have two numbers on the stack, you might have their sum, their difference, their product, their quotient, and the results of dup, drop, and swap, each displayed next to the relevant operator; then you can select the desired operator to go to that stack state. That seems like it might help with the gulf of execution, providing you with one step of lookahead. But maybe it would be more distracting than helpful?

I had that idea too. The Prolog code does that anyway to type-check (the interpreter is also the inferencer, because Prolog is awesome that way) so there's no reason to throw the result away rather than display it somehow. But with infinite undo you've got that tree of possible evaluation already, eh? It comes down to ergonomics.

> But then, you could imagine doing the same thing with a verb-noun system, as long as all the arguments have reasonable default values so that you can somehow get useful visual feedback on the results even before you have chosen all the arguments; for example, for arithmetic operations like that, the default value might be λx·x, the identity function, so that you see graphs of all possible results.

That would be pretty cool.

> I used to chat with Slava when he was first working on Factor (before he started working at Apple)

That's cool! :-)

> but I'm embarrassed to admit I've never actually tried Factor. (Or Joy!)

Heh, me neither. I want to use it just because it's so cool.

> Is there a screencast of the hypertext features you mention?

Dunno, but you can just download it, fire it up, and click "Help". It's nothing fancy, just a little mini-browser with hyperlinks.

> What do you think about Cat?

I looked at it when I first started with Joy but it wasn't quite right somehow. Slightly too complicated, or wrong emphasis or something, I forget.


By all means, feel free to copy the UI of any of my UI experiments! Most of the things I write I license under a liberal license to make sure people know they can do that; Dercuano http://canonical.org/~kragen/dercuano is in the public domain, for example, and it might have some things in it that you enjoy.

I like Philip Guo's Python Tutor, and I used it a few weeks ago to show my girlfriend some algorithmic stuff, but (following Victor's Magic Ink) I think its mandatory interactivity is a significant drawback. To the extent that it's possible to visualize a program's behavior as a static image — perhaps a zoomable one — rather than an animation or a slideshow, I think doing so is an improvement. (In many cases it's adequate to just use a comic strip, as Victor did in his binary-search visualization in Inventing on Principle, or as you are doing with your V, but sometimes that involves too much compromise.) But Python Tutor is already tackling a very difficult visualization problem, and the static equivalent is an even harder visualization problem.

I enjoy Conal's work but I haven't read Compiling to Categories yet. I don't know much about category theory or Haskell, so I always struggle with his papers.

The particular Victor thing I was thinking about when I said "overwhelming battery of data points" was Up and Down the Ladder of Abstraction, but it also applies to, for example, the circuit example in Inventing on Principle.

I think Prolog CLP(FD) is less powerful than miniKANREN, except in the sense that you can of course implement miniKANREN in Prolog, but I'm no expert. I haven't seen an equivalent to Byrd's mindblowing quine-generation paper that uses Prolog instead of Scheme for either the implementation or the language being interpreted; I wonder if you could get some mileage out of that approach?

What you're describing about modeling traces of programs for a Turing-complete machine with a finite state machine is something I'd like to see explored more. Of course it's straightforward to produce a conservative NFA approximation of a more powerul automaton: whenever the automaton makes a decision based on information that's excluded from the NFA's state, the NFA makes a nondeterministic choice among the possible alternatives. So, given any possible mapping from the state of the more powerful automaton into some finite set of states, you can straightforwardly compute the NFA, and from that you can compute a DFA. Bjoern Hoehrmann's parselov takes such an approach to the problem of parsing context-free grammars, for example. (For better or worse, his favorite logic programming language is SQL.)

A difficulty I have with the programming-as-Kolmogorov-compression approach is that, at least in the case of Co-dfns, it didn't really speed up the process of creating the software; in fact, it slowed it down. It might speed up the process of understanding the software for other people, which is the major benefit in my view of the similar compression of algebraic notation for equations, but I haven't seen strong evidence of that, and I've seen weak evidence of the opposite — legions of programmers throwing up their hands at maintaining APL code, calling it unreadable, and flocking to alternatives as soon as they became available, such as VisiCalc, MATLAB, S, and Lisp, and their modern replacements such as Gnumeric, Octave, Numpy, TensorFlow, R, and Python. I guess I finally need to buckle down and learn an APL after 25 years of dithering.

It's possible that with better visualizations of examples, some of that perceived difficulty will evaporate.

Thank you for this wonderful conversation! Forgive me for not having responded earlier.


Your dercuano looks pretty awesome. I skimmed the PDF so far. :-) I have to be careful with stuff like that or risk being "nerd sniped" and spending the rest of the day doing something other than what I had planned, eh?

In re: visualizing program behavior I look forward to implementing something like an SVG rendering of the dataflow diagrams implied by Joy expressions. It would be easy enough to use Dot but I want something more like the railroad diagrams that e.g. git history tools often have for visualizing branches.

Long ago there was a wonderful website that showed 3D dataflow diagrams (hand-drawn I believe) that had recursion as data lines that went backward to earlier stages in the computation. (IIRC the demo was the GCD function.) I lost track of that, but there's a guy working on "generalized arrows" (in the Category Theory sense) that has something very similar.

In any event, the train yard would be static with data/cars flowing through it.

I don't know much about category theory or Haskell either, but in this case I kind of stumbled across the same thing, I think. I was writing a type inferencer in Python of Joy, and I realized I could use the stack effect comments as the stack itself, and just execute combinators, and that got me most of the way to full inference (it's still incomplete: looping generates one type per loop iteration, etc.)

In a nutshell, the point-free style allows you to swap out the categories that your expressions operate over very easily, and get multiple meanings: diagrams, circuits, types, values, incremental re-evaluation, and so on, from one expression.

In re: the quine gen, yeah I haven't tried it out much yet but the Prolog version of Joy can do that with "iterative deepening". I'm more interested in auto-generating and testing new semantics for existing functions that give greater performance. I appreciate the beauty of quines but I want self-tuning.

I actually got into logic programming from studying a Kanren in Python implementation a few years back. Now you can also implement Prolog in Lisp, so I won't quibble about power, eh? I like Prolog. I found that embedding (imperative, functional) Joy into Prolog was so elegant and so powerful that that, combined with the research on compiling with it, turned me into a complete Prolgo fanboy. So I'm biased. But in general I think it makes more sense to work mostly in the logical paradigm and only "descend" to the more imperative paradigm when the shape of your problem requires it than to camp out in imperative land with mere excursions to the realm of pure logic.

> Bjoern Hoehrmann's parselov takes such an approach to the problem of parsing context-free grammars, for example. (For better or worse, his favorite logic programming language is SQL.)

Ha! That's awesome! I'm going to have to look into him. You probably know that the relational model is the same as the logical relations that Prolog models, eh? In other words, SQL is Datalog, more or less.

> A difficulty I have with the programming-as-Kolmogorov-compression approach is that, at least in the case of Co-dfns, it didn't really speed up the process of creating the software; in fact, it slowed it down.

I think you'd have to ask arcfide to estimate how long it would take to write Co-dfns again. It sounds to me like he bushwacked through a lot of conceptual ground that hadn't been explored before.

I have just enough experience reading Joy code to credit the APL people when they say they can grok a page of line noise, the Forth folks report the same thing. "Intuitive" means "familiar" in computers (Jef Raskin.)

I agree that ease of understanding beats mere compression of code.

Thank you too! This has been great.


The discoverability aspect of this reminds me quite a bit of working on a Cisco IOS command line. At any point while typing a command, you can mash the ? key, and the shell will print out a list of acceptable inputs given what you've already typed (this example stolen directly from Cisco's docs[1]):

  Router# configure ?
   memory             Configure from NV memory
   network            Configure from a TFTP network host
   overwrite-network  Overwrite NV memory from TFTP network host
   terminal           Configure from the terminal
   <cr>

It's really quite a great experience.

1: https://www.cisco.com/en/US/docs/general/Test/dwerblo/broken...


I recall working on a Pix firewall, which IIRC was a product Cisco acquired from someone else and had something IOS-like, and a true Cisco IOS router more or less simultaneously.

The difference in usability between the two was quite notable, exactly for that reason.


In a previous life I wrote (about a third of) a system that configured routers by sending them IOS commands over telnet. It didn't seem like an improvement over SNMP to me — we configured most routers over SNMP, but couldn't for the Cisco IOS ones — but it's definitely a better way to navigate a menu tree than the traditional

    [1] Configure from NV memory
    [2] Configure from a TFTP network host
    [3] Overwrite NV memory from TFTP network host
    [0] Return to previous menu
    Enter your selection> |
For things that don't fit well into a hierarchical tree of selections augmented with bureaucratic forms — either because it isn't obvious what category you're going to find something in (why is "Preferences" on the "Edit" menu‽) or because it involves operations on more than one object at a time, or creating objects that don't exist yet — the improvement is zero or negative.

This appears even in the above example: you can get configuration data from three places and send it to two places (running-config and startup-config), but only four of the six combinations of source and destination are available. If you want to overwrite NV memory from the terminal, you first "configure terminal", and when you're done, you use a totally different command, "copy running-config startup-config", to overwrite NV memory. And there's a third unrelated command to send a configuration to your terminal, "show running-config" (or, as you would expect, "show startup-config" or for that matter "sh start".)

When it comes to things like "ip route 10.2.0.0 255.255.0.0 10.1.0.2" I really don't want to be using the CLI interactively; I want to be using a text editor so that I can copy the line for 10.4.0.0/16 which goes through the same router and just change 4 to 2, and then I can diff the config with the config I'm setting on the other router and see if the differences are only the intended differences. But if I were using it interactively, it would sure be nice to be able to move the damn cursor field by field rather than character by character and see some kind of real-time indication that 10.1.0.2 is not a valid netmask if I get the order of fields wrong.


I agree, this aspect of CLUI reminds of IOS CLI, which in my opinion is one of the greatest example of command lines. Every command is immediately understandable and, most importantly, there are only a few key commands. For IT people: it's the opposite of Brocade FabricOS early versions. There were too many commands with similar confusing syntax. And NO autocompletion in many cases.


Yea, I've had it in the back of my mind to try and find or build a cisco/juniper/etc style cli lib for awhile. It's about the most efficient design I've seen for new users, where I could get a new engineer productive quickly, and for users who don't login or use the cli often, it's quick and easy to be productive quickly.


Compared to other routers, Cisco has one of the least friendly CLIs


This reminds me of what fish [1] (friendly interactive shell) brings for me. Together with z for directory jumping [2] and fzf for interactive lists [3] there's really no need for a "finder" or "explorer".

Aside from it I've run into Xiki [4] that seems to bridge the gap on multiple levels between GUI and CLI. GUI to bring the discoverability and CLI to keep it scalable.

[1] https://fishshell.com/ [2] https://github.com/jethrokuan/z [3] https://github.com/jethrokuan/fzf [4] https://xiki.org/


Macintosh Programmer’s Workshop had something similar in 1986 (http://mirror.informatimago.com/next/developer.apple.com/too...). It was incredibly useful.

Apple’s first Unix copied that in 1988 (http://toastytech.com/guis/aux3.html)

Powershell has ‘Show-Command’ which also is similar (https://docs.microsoft.com/en-us/powershell/module/microsoft...)

I think PowerShell generates the GUI, while MPW commando had human-designed dialogs (and, for complex commands such as compilers, sub-dialogs)

I think this is worth copying in modern Unixes. Those GUIs make it way easier to use rarely used flags than man pages.


Wow, Commando looks really similar to the Kui tool mentioned in a sibling comment [0]. Would you agree? Or was Commando only used for options / an alternate to flags?

[0] https://news.ycombinator.com/item?id=22500032


Commando didn’t do graphical output. It was a tool to help compose a command line. Command output went to the terminal, or, in MPW, into the file being edited (Mac OS didn’t have a terminal)


Ah, I see, input vs output. Could see both being useful at the same time.



Visual Studio Code has replaced ISE.


How do I get intellisense in the VSC terminal? Best I can figure out is I have to make a file and run that.


Not sure what you mean, it does do completion just like the regular Powershell terminal window.


Commando FTW. Kids these days should study some history ;)


Such a shame AUX was abandoned.


This just reminded me of Emacs. There's not a whole lot of menus. All the available commands (also variables and values) can be searched and autocompleted. The initial hump is hard to get over, but after that things are so discoverable and extensible it's a pleasure.

I recently switched to VS Code for creature comforts that come from a much large ecosystem and using more modern OS affordances. VS Code gets close but not quite as pleasant as Emacs.


I wish LibreOffice, GIMP etc. had an M-x way of finding the commands, and a describe-function to ask what exactly a given command is doing. Or C-h b way of sifting through keyboard shortcuts, in just another buffer with search and everything.


GIMP has something similar, triggered by pressing /. I discovered it way too late, but I haven't touched a menu ever since.

Libreoffice has a feature request for such a function [1].

[1]: https://bugs.documentfoundation.org/show_bug.cgi?id=91874


Wow, thank you!


There is a similar thing for Blender: https://blender.stackexchange.com/a/40170


Congratulations to repl.io team on rediscovering Symbolics Lisp Machine's Dynamic Windows / Common Lisp Interface Manager's presentation and listener systems!

Not being sarcastic, even - it's a pretty powerful approach that deserves better, unfortunately distribution of knowledge in Computing Science, especially historical knowledge if you never encountered it yourself, is pretty hard.


That's interesting -- thanks for sharing! I try to be as erudite in computer history as possible but I still somehow missed this.

I pay homage to the Lisp community w/r/t programming interfaces in this post: https://amasad.me/disintegrated


Genera on the Lisp Machine is very much an embodiment of this graphical command line (or rather just command) user interface. There's quite a lot to it. CLIM (and the open source McCLIM) is the current realisation of this.

There's some documentation about 'Commands' in CLIM II here for example: http://www.lispworks.com/documentation/lwu41/climuser/GUID_1...

Commands are first class objects which live in command tables and which CLIM can look at to generate bits of UI and allow parameters to be specified. Central to this in CLIM is the idea of presentations - where domain objects are 'presented' onto the screen and the link to the domain object is maintained. That way you can invoke a command on that object in various ways, for example you can type a command name and then click a presented object which is acceptable as a parameter.

The Symbolics S-packages used these concepts to make (I presume) powerful 3d modelling programs back in the day (I haven't used them): https://www.youtube.com/watch?v=gV5obrYaogU - sorry for the poor video quality.

https://twitter.com/rainerjoswig?lang=en (lispm on here) sometimes posts interesting things about Genera


Ive been wanting to look into this forever but cant get geneva to run on my system


Genera runs best inside a virtual machine of an old version of Ubuntu. I was able to install it when I followed this tutorial: https://www.youtube.com/watch?v=12USa3gU_oU.


Do you think wrapping that all up in a docker container is a bridge too far? I've seen this video before and have thought about installing on this old box I use as a file server but have never got around to it.


ideas have people :)


While I agree wholeheartedly with the stated goals, I do worry that the CLUI isn't quite as perfect s solution as it's implied to be. The CLUI is listed as having all of the upsides of both GUI and CLI but none of the downsides of either, but I feel it's more like halfway on everything. It's /more/ approachable than a CLI, but still /less/ approachable than a GUI and this goes for most of the categories listed. It's still an interesting idea but it strikes me as a bit risky. At what point does less approachable become too unapproachable? I fear CLUI may have accidentally gained many of the downsides at the same time as mere pieces of the upsides


I agree. It feels like an improvement over the very limited interaction from a plain CLI, but it isn't foolproof. The user still needs to know e.g. whether the right way to set an user's role is through 'admin roles' or 'admin user'


replit designer here - yes, totally agree. the current implementation definitely is not foolproof, but it's just the start. ideally it will handle more unstructured commands in the future!


For the avoidance of doubt: I think this is awesome! Keep up the good work!


thank you :)


interesting point. luckily we're testing it in a pretty sandboxed environment so it's not going to overtake replit all at once. I think the power will come from integrating CLUI seamlessly into the parts of GUIs people are really accustomed to. luckily all the questions you raise are totally testable and will be a part of our research process :)


Bash already has autocomplete and there are shells with richer feature sets.

What I would like to see is something like CLUI to be integrated with an IDE or a productivity tool like Adobe Photoshop. PyCharm/JetBrains already embraces the keyboard with double-Shift => Search Everywhere, and other similar shortcuts. Similarly, Photoshop would benefit from keyboard interaction for common tasks. We already have single-pixel nudge actions via the arrow keys, but a CLI prompt you could conjure up and type into would be a game changer for actions that require repetition and precision.

That is, rather than bringing GUI to the CLI, bring CLI to the GUI.


> Bash already has autocomplete

What kind of autocomplete does bash have? Do I need to enable it? I've just tried bash 5.0.16. I don't see any. For example, I've typed `pw`, but `pwd` was not suggested to me.

(I know there's Tab-completion, this is not what I'm talking about. I'm looking for automatic completion. Similar to Google's search suggestions and CLUI demo.)


I think fish has that?


Thanks! Fish is close, but not there yet. It provides only a single autocomplete suggestion. I had to press Tab to get a list of suggestions. So:

bash: no auto suggestion at all, Tab twice to see a list

fish: shows single auto suggestion, Tab once to get a list

zsh + zsh-autosuggestions: looks similar to fish behaviour

Is there some combination of shell/plugin/terminal that provides multiple auto suggestions?


Tab twice.


The feature you are looking for exists in `fish`


> Photoshop would benefit from keyboard interaction for common tasks

Out of curiosity, how often do you use Photoshop, and for what tasks?


Yep, that's the plan -- we're adding to our IDE. Will report back results.


Another great project in this space is Kui[1] - a framework for graphical terminals. It gives a hybrid command-line/UI development experience for cloud-native development.

[1] https://github.com/IBM/kui


nice. I've seen this with markdown previews but makes total sense to generalize


This is cool, and it's great to see you work on this (and thanks for open sourcing!)

One more bit of prior art that might be interesting to you: I worked on the Mozilla Bespin project a long time ago with Joe Walker. Joe was also really big on the command line idea for much the same reason and created [GCLI](https://github.com/joewalker/gcli/blob/master/docs/index.md).

GCLI ultimately landed in Firefox Developer Tools, but I don't think it's in the current shipping version. Funnily enough, I just found a video on YouTube of me demoing the command line in Firefox Dev Tools: https://www.youtube.com/watch?v=YwOwJ1_JaKE

The state of the art in web UIs has definitely moved forward, and I'm really happy to see more experimentation with graphical command lines.


This is great! Would love to hear more about your experience working on it if you are interested in sharing – did you notice any particular tasks where this type of interaction shined?

My dream would be to have something like built into an IDE so I could save edits directly.


As features go, this didn't prove to be super successful (it's no longer shipping with Firefox).

I do still think it's a valuable interaction style for being able to activate less-frequently-used features all from the keyboard. It's possible that the fact that web browsers also have the JS Console is just too much, because the JS Console has a command line that people are familiar with. The interaction model is very different, though. GCLI made it quick to type commands, whereas the JS console requires valid JS.


Interesting, I could see how that could be confusing.


This description sounds very much like CLIM, which was a graphical, clickable CLI originally designed in the early 80s for Lisp machines. (CLIM is much more than that, but building a graphical CLI is one of the things that's easy with CLIM.)

https://en.m.wikipedia.org/wiki/Common_Lisp_Interface_Manage...


I regularly use a pretty GUI-intense program, called REAPER, for editing digital audio. Its a very powerful application, full of amazing features and powerful yet simple tools.

Its a bit daunting at first, and can be overwhelming if you don't really have the patience to dig into it and find where everything is, in terms of grouped functionality.

However, one key thing made learning to use REAPER smooth as butter - the '?' key. This shows the "Action List", which is a list of all the things you can do in REAPER, in a text list .. so I can quickly type '?' - then 'section' and find all the actions related to sections. VERY useful, and quite a great way to explore the periphery of features I would otherwise not have discovered.

In fact, its the very first thing I teach anyone I'm introducing to REAPER, that they should use. I'd say, without this "text-based UI", the rest of the program wouldn't be nearly as accessible. A lot of that has to do with the fact that the REAPER developer seems to have a Power > Eye-candy attitude about the UI design - its clean, minimal, and functional when you first get started - but the UI is also fully tweak-able such that once you start getting productive with it, you find ways to make the GUI really shine (track colours, Layout customisations, etc.)

Anyway, I think its pretty interesting that the entire UI is accessible from the text-based '?' Action list query... I wish more programs would adopt this abstraction.


I wouldn't take this article to be a be all, end all. It's quite thought provoking for me personally. The reason I switched from bash to zsh was simply the UI like interface in path completion with OhMyZsh. The reason sublime works quite well for me is that there are tabs that I love to move around and see at the same time and I like the visual feedback of moving things around and switching contexts. But if I want to do something quickly.. I can easily find the command for from a simple keyboard shortcut.

I think this idea can be refined further and made more and more robust and is a design pattern in the right direction. With more and more percentage of the population heading in coding-friendly direction I see this as a very viable next step.


I think it is an interesting idea that needs some further exploration.

I do see some problems with it that were not addressed. The way the demos are setup are by definition an NP!=P problem. It is easy to verify you found the right command, but may be fiendishly difficult to navigate the tree to get there. Menus with sub-menus having sub-menus at least makes it visually clear which paths you have not taken and allow retracing your steps. Something akin to Ctrl-R in shells may be needed to allow you to type certain keywords to find all possible actions.

Options and parameters are not part of a decision tree as they don't specify a logical action that will follow, they just change the action. Those parameters need evaluating the entire progress in the tree to be able to suggest a next available parameter, option and action. Try it with something like ffmpeg. Modelling this to work in a CLUI will evolve into a hard problem very quickly.

The more actions, options, parameters I add as a user the more important it becomes that I can backtrack and correct mistakes. Corrections may or may not have consequences for the position in the tree I already choose. Starting over even from there might not be the right solution in terms of usability if the correction does not necessitate it.


One interface that reeks of genius is Magit[1]

Taking a sprawling interface like that of git and making it work in a console window in Emacs is an idea that bears repetition across other tools, e.g. tar.

Would I'd the time to work on such.

[1] https://magit.vc/


Is there anything similar that doesn't require me to use Emacs?


Not really. You can use Emacs just for Magit, though, without adopting it for things like text editing, PDF viewing, email, and Tetris.


Check out https://github.com/jonas/tig, a ncurses-based text-mode interface for Git.


There are magit clones for other editors, though less featureful:

https://github.com/jreybert/vimagit

https://github.com/diiq/atomatigit


I sort of want to question what you mean exactly by "use Emacs"? Emacs is a lisp environment / UI framework for application development. So in principle saying you don't want to use an application implemented in Emacs is like saying you don't want to use an application implemented in Electron. I'm only 85% serious there, obviously Emacs has a certain amount of cruft that Electron I assume does not.

You could start an emacs process just in order to use Magit -- you wouldn't have to use it for anything else. However, I totally understand that you might well not want to mess about configuring emacs to load magit and working out how to start it etc. How about these?

https://github.com/vlandeiro/magit-docker

https://github.com/akirak/nix-magit


There are some people who refuse to use applications implemented with Electron.



Sublime Merge does not emphasize text input per se but allows you to type git commands with partial autocomplete/suggestions...


I was with you for the first half, until the demo of the command completion with clickable dropdown options and thought it looked just like the nested menus you're trying to kill. The difference is a slightly less cluttered interface, but for someone who knows what they're looking at is a menu all that different than selecting a command that gives a subset of followup commands on a single line?


The article addresses this:

"Because the tree is hierarchical, you might think that it actually resembles a large dropdown menu. The difference is that search is built directly into its navigation, not just pointing and clicking. One clear improvement that could be made is being able to search for any subcommand without having to specify its parent command first. That way you can access any deeply nested information instantly, similar to spotlight search."


AutoCAD amongst other software has been doing this for about 25+ years, I think. Clicky-clicky if you want, or just type in the command, same output.

IntelliJ also, more recently, with its actions input.


Ubuntu also tried mixing GUI and CLI in its Unity HUD [1] as part of their "intent-driven interface". The HUD retrofitted all existing menus of an application into hierarchical, searchable and "autocompletable" actions. In all applications you could press the super key (the "Windows key") and start typing what you were looking for.

In my personal experience, the search functionality was extremely useful when using for the first time one a complex application such as Gimp or Libre Office. Unfortunately all extra functionalities (autocomplete, for instance) required the applications to explicitly support the HUD and few (any?) application added the necessary code once GNOME 3 appeared.

[1] https://wiki.ubuntu.com/Unity/HUD


I absolutely loved autocad for this. One hand on the keyboard, one on the mouse is an easy way to double your productivity. The speed at which you could draw things was amazing. I had a custom alias file with most commonly used shortcuts and the enter key was bound to right click which removed the need to move your left hand over the keyboard. This was in the 2000. Sadly the more recent versions I have tried make this harder to do. If I hadn’t switched career I’d still be using autocad 2000 !


I use DraftSight with AutoHotkey and a Razer Naga, makes CAD work very swift!


Yeah, spot on ! Autocad has been doing that mix of GUI and CLI for soooo loong. Example :

https://www.youtube.com/watch?v=Hgz2kqm0rsY

20 years ago I remember seeing a person drawing mechanical plans using a lot of keyboard and just a bit of mouse. That seemed really productive.


This idea is so great, really like it. But I don’t know how practical it is. From the article, It improves the UI and interaction of the CLI, "That means that images, gifs, video, graphs, interactive diagrams, buttons, and forms should be able to integrate directly into the CLI experience." which may improve the user experience, But the basic mode of interaction of CLI doesn't change. The CLI experience is still not intuitive. Maybe CLI will work well for simple scenarios, but I don't know if it is a good choice for the complex circumstances. The complex interaction and graphical interface display of some industrial scenes may not be well expressed by the CLI, Even they cannot interact only through the keyboard. So I worry that CLUI will face a situation where complex circumstances are too much to handle and simple scenarios are unnecessary. Actually, there has been some CLI tool through shortcuts and custom instruction to do these things (autocomplete, fuzzy-search, tips or guidelines) with text way, They also did well.


I think the main value of CLUI is that it flattens the learning curve for users who don't normally use the terminal, not that it scales all the way from new users to experienced ones.


Completely agree.


It's been more than 5 years since I've used AutoCAD or other AutoDesk professional design software, but it has this. There's a command line that interfaces very well with its GUI. You can draw shapes entirely in the command line, or you can use it to help you place a second point in a line, for example.


The help > search menu is the thing I miss the most from Mac OS since I switched to windows. Especially in programs like Photoshop where there are dozens of nested dropdowns, hitting cmd + ?, typing a few characters, and hitting enter is such a huge boost to productivity when you haven't memorized all of the keyboard shortcuts, and it even works on menu items that don't have a shortcut. The Microsoft office suite has this functionality as well, and I really wish they would integrate it at the system level like Mac OS does.


Agreed, love this feature and use it often. I wish it saved the last few searches to quickly access commonly searched items.


I really like the general idea of bridging the gap between graphical and text-based interfaces, abstracting away the differences and be able to use a mixture of both. In the realm of interactive programming (eg heavily ide assisted), people with some functional and statically typed programming background would be interested in this magnificent talk about idris2:

[Edwin Brady - Idris 2 - Type-driven Development of Idris]

https://www.youtube.com/watch?v=DRq2NgeFcO0


Using an iPad has inspired me to rethink things like terminal and CLUI is very close to ideas I’ve been wanting for work on for a long time.

My idea originally came from using ssh on my iPad and thinking it would be cool if more native controls were used over RPC instead of text to display what was happening on the server. Then I could more easily navigate the responses and maybe even if there was more intelligent autocomplete which a UI on iOS could take advantage of. Or maybe interactive confirmations and stuff (similar to what was Demo’d). And also then provide an easy way to edit files using either a remote editor or a way to sync changes being done in a local editor. Kind of how vscode seems to do it (e.g. a remote service handling the work)

The one thing a system like I’m describing would still need is the ability to switch from this rich interface back to the terminal when using things like tmux, curses, or vim/emacs because obviously those things still work well.

But the cool thing was realizing that this would also be great on the desktop. Looked into some terminals like Hyper thinking maybe I could hack those up to get a proof of concept for myself, but can’t find the time. And obviously it wouldn’t work for the iPad where I really wanted it.


This reminds me a bit of the Dynamic Lisp Listener from Symbolics Genera-based Lisp machines.


The examples look really cool. I'd like to add a sort of wish I have for such a "smart CLI": Being able to preview the effect of the command(s) you're currently typing, like the files/directories it's going to modify, whether it's going to change something for the entire system or specific users.

Something like that would lower the intimidation factor for beginners even further.


This is really cool. I'm actually building a coding language for UI designers, and a UI like this would be super helpful.


that sounds interesting. do you have anything you can share?


Not yet, but hopefully I'll have something simple to show in the next few months.



This is great and a very powerful technique. Are there any things like this that provide similar interfaces for OSs?


Requires a bit of initial setup, but possible it's what you're looking for: https://github.com/denisidoro/navi

Also, at least some of the scaffolding for CLUI seems to be available at https://github.com/replit/clui


I don't agree that GUIs are a replacement for the CLI. Yes in the past that is all we had, but really they are completely different and should be considered in parallel. CLIs were never really meant for non-technical users though as far as I'm aware, or at least the end user was already expected to have some kind of established context. I'm not really against exploration in this area but I disagree that CLIs are flawed. I'm biased of course, excuse me while I get back to my UNIX/xterm/tmux/vim development environment.

EDIT: I would like to point out that I've only been in the industry for 6/7 years so it's not like I started my career where this established environment was the only choice.


This might be what they're getting at. Discoverability with the basic Python repl is bad. You can use help and dir and both are clunky. But install ipython and you're off to the races with autocomplete menus you can arrow key through.


ptpython is great at that also and probably easier to grok at first.

The fish shell does much of this as well but is not as attractive.


Interesting idea. I expect it would be a hell of a lot more impactful if the demo used some well-known commands like `tar`, `find` or `grep`, though, all of which have absolutely heaps of options and complex command structures.


They've got some great ideas and insight here. The thing is, there already is a wonderful two-dimensional, general-purpose, interactive terminal/graphic interface: it's Emacs. And it really is awesome!

I think this is a corollary to Greenspun's Tenth Rule ('Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp'): any sufficiently powerful UI will be an ad-hoc, inextensible, inconsistent, weaker version of Emacs.


They mock standard OS tree menus and then advertise their...tree menus, and justify it by saying theirs have search, ignoring that OS tree menus also have search


Seems to be in line with my fav Postgres tool pgcli: https://www.pgcli.com/


Cool thinking.

And thought provoking. I find myself increasingly being annoyed by GUI's with their rich interfaces. An interesting project is lazygit which uses gocui. For me it is useful and appealing alternative to the command line git. With each pane you press a meta key to get list of commands for the pane, and it would be interesting to see a mash up with replit somehow.


This is what Microsoft Office has been doing for the past few years.

For those unfamiliar, modern Office versions use ribbons instead of menus. Ribbons have a few tabs like home, layout etc. The tabs change depending on what object you're interacting with, so i.e. if you're editing a pivot table in Excel, you get two new tabs for working with pivot tables. That means you only see the options that are actually relevant to you. Each tab has buttons separated into groups. So, there might be a "alignment" group with "left", "center", "right" and "justify" inside. Most buttons have detailed descriptions of what they do and multi-layered, visible keyboard shortcuts that activate them quickly. Some even have an additional drop down for more options, so i.e. the "view" button in Access might switch you between the two most common views when clicked, but you can expand it and select a different view if need be. The latest office versions also have a search field that allows you to find any command, no matter what tab it is in. It has autocomplete, so typing piv usually shows you "pivot table" as one of the first suggestions.

I use Excel and Access pretty often, and do some moderately complex things with them, but I almost don't use the traditional ribbon at all. I use shortcuts for the commands I need very often, and search for the rest. If I don't know how something is called, I go through the commands on the relevant tabs and find it eventually.

I think this kind of UI scales pretty well. MS Office apps are pretty complicated and packed with features, especially the pro versions, but I think that UI paradigm is pretty scalable and nice for users.


What follows is only partly related to the overall conversation, rather an answer to the ribbon episode.

The ribbon in MS Office came along roughly at the same time as 16:9 and 16:10 screens (on laptops in my memories anyway). Already on a 4:3 screen, WYSIWYG editing wastes much space on left and right of the screen, to show paper margins and page limits. And that goddamned ribbon eats up all the top of the screen, making you see only a limited band of what you could see on that very screen. Had no one the idea to make the ribbon a vertical tool bar on the left or right, like in Photoshop/Gimp and a number of other tools? Such a feeling of UI failure at the time. At that moment my computers were already all running Linux anyway, so I've never used it more than a few times on a coworker's machine.

Now I no longer use WYSIWYG software. Text editing with the WYSIWYG paradigm feels superficially seducing, until you realize it actually hides the actual document content. How many times has Word shown some items in a bullet list with a different size without any visible reason ? Or in Google docs one bullet horizontally misaligned? Why? No one knows.

When editing text, seeing how the final document would look like is not that important. It's more important to know the state of what you're editing. With markdown or asciidoc what you see it what your document actually contains.

On top of that, WYSIWIG assumes that there is one final document appearance, which is just not true for a digital document in a digital world that could be rendered countless ways in different styles (unless your workflow targets documents in try-to-mimick-paper-form, like PDF, until that changes).


> "On a technical level, a CLUI command is conceptually similar to a file path or URL. Since a complete CLUI command is simply a path down the command tree, each potential subcommand is like a portion of a file path or URL."

Sounds like walking the tree of a REST api... potential CLUI framework for REST?


Bashing premier pro is a low blow. It’s a very powerful tool that really can’t be replicated in Cli. Even using ffmpeg CLI is a painful experience.

That being said code completion, contextual help and form-ish guis give a better user experience.

The most used UI element is a button and thereafter is the search input.


Most of the tools to do this exist in ordinary terminal emulators, with ordinary shells. This would be interesting as an extension for Fish or similar. AFAIK (somewhat) typed auto-complete information is already available for a lot of commands.


The article describes pretty much what SAWS has implemented - https://github.com/donnemartin/saws

(mad props to ~donnemartin for the implementation!)


Most of this research program is already realized in Windows 10, where you press the Win key and get universal search through programs, settings and files.

(And unwanted Bing search results that open in Edge, but that’s Something else)


Totally different. That only works for finding programs, not running commands in them.

Windows is 15+ years behind Mac in simply implementing menu search inside programs.


I never used it a great deal, but I had the impression that MPW (Macintosh Programmers' Workshop) was an evolution of the command line that unfortunately didn't really catch on.


With the prevalence of search-driven interactions and increasing popularity of GUIfying the CLI, I feel like we are somehow converging to Oberon. I wonder how that will look like.


Presentation-based UI for PowerShell:

https://github.com/dharmatech/PsReplWpf


The combination of this and a ncursor app framework is much better than GUI application. Unfortunately, I don't find an active great ncursor app framework.


so it's like bpython (https://bpython-interpreter.org/)?


Part 1 of 4721: A GUI program in a domain that usually strains all a computer's resources, probably ought to perform within soft realtime constraints, and is aimed at professionals is complicated.

Part 2 of 4721: Let us now persuade you there is a better way by demo'ing a souped-up terminal window that helps non-specialist Unix enthusiasts enter a record into a database.

???

Part 4721 of 4721: As we have clearly shown, our realtime video-editing CLUI application is more approachable, discoverable, interactive, and scalable than Adobe Premiere.


This is awesome! <3

I think the technique of creating UI forms based on GraphQL metadata is going to be key for building the admin tools of the future.


They should name the shell CLASH.... for

Command Line Again SHell

I think the idea they have is awesome. Managing servers with this would be a dream!


Last year I made a bulk photo management software using this exact UI pattern. It’s very effective.


This is already implemented, modern bash offers completion and suggestions, which look exactly like shown (text only though) when you press Tab.

This includes parameters, flags (with documentation), context (eg files in current directory).

Autocomplete is available for most commands on modern Linux installations.


Bash is apparently capable of showing the completions with explanations, however there doesn't seem to be a de facto standard way of doing it. Or did I miss something? Are there like libraries to help out with this, so that the help text is shown consistently?

But yeah, agreed that pursuing this path would be less effort and get 90% of the way to the goal.


How come noone mentioned Aza Raskin's Ubiquity? This is HN after all!


someone could improve the scalability of windows by adding better scripting options. Like how can I open 10k windows , programatically change a form input and then click the submit button?

Selenium comes to mind..


I use Zenity to create interactive graphical dialogs from shell scripts.


Implementing a working and fast CLUI (as a search feature) was one of the easiest ways to get a real WOW-effect from our customers. /founder here

think of: the website (and search results) updates in realtime with every letter you type


It isn't a command line "interface", it is a command line "interpreter". If you don't know this you have lost at the start. I'll stick to my shell, thanks!


Matlab, Mathematica et. al. are used by tens of thousands of people daily. You have several decades of catch up to get anything resembling feature parity.


Hey! I wrote this command in a GUI CLI!


So, did you ever heard the /etc/bash_completion?


Unless I'm missing something this seems to just be a blog post about a prototype of an idea, and not something you can actually use.


Yeah also they are talking about GraphQL backend so I suppose it's just a gimmick you put on your website and not an actual CLI.


I am quite annoyed with text user interfaces, especially in lui of a proper CLI. On two occasions that I asked people to make a CLI for something and then they made some abomination that can't be used from a script but needs to be used interactively.




Applications are open for YC Winter 2021

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: