Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What is a stateless user interface?

blog.ezyang.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: What is a stateless user interface?

#21

Post by js8 »

I was thinking about similar thing recently. The UI state should be isomorphic to the state of the application (which is arguably hard to do with the command line, but I digress).

So every action that user can take in the UI has clear correspondence in valid change of the application state.

Also, this would affect composability. If the state of the application of composed of smaller elements, the UI should be composable too.

So just be defining the application state (this perhaps includes edited document in editors), and possible transitions (which is a category), one should get a skeleton of how UI would behave.

Re: What is a stateless user interface?

#22

Post by Zardoz84 »

miguelrochefort wrote: post #10

The enemy is ambiguity. To avoid ambiguity, you need to be explicit. Being explicit is expensive. Thought prediction (auto-completion) is the solution. We need a computer-assisted predicate-oriented language. This will become the only UI we need.

> Thought prediction (auto-completion) is the solution.

Use fish shell

Re: What is a stateless user interface?

#23

Post by miguelrochefort »

will_pseudonym wrote: post #11
miguelrochefort wrote: post #10

The enemy is ambiguity. To avoid ambiguity, you need to be explicit. Being explicit is expensive. Thought prediction (auto-completion) is the solution. We need a computer-assisted predicate-oriented language. This will become the only UI we need.

I have been wanting to build this for years. We should chat!

My very existence is defined by this vision. Let's talk.

Re: What is a stateless user interface?

#24

Post by miguelrochefort »

vinceguidry wrote: post #13
miguelrochefort wrote: post #10

The enemy is ambiguity. To avoid ambiguity, you need to be explicit. Being explicit is expensive. Thought prediction (auto-completion) is the solution. We need a computer-assisted predicate-oriented language. This will become the only UI we need.

How is this better than hooking into bash-completion? I don't see this avoiding ambiguity.

- Text isn't sufficient to a rich interface.

- Auto-completion is best when you start with arguments (as opposed to a function or predicate).

Re: What is a stateless user interface?

#25

Post by will_pseudonym »

miguelrochefort wrote: post #23
will_pseudonym wrote: post #11

Earlier quoted context omitted.

I have been wanting to build this for years. We should chat!

My very existence is defined by this vision. Let's talk.

My email address is willhinsa at google's email service. Yours?

Re: What is a stateless user interface?

#26

Post by louthy »

kornish wrote: post #15
louthy wrote: post #14

I think cabal is the primary reason why I do far less Haskell coding than I'd like. Coming back to projects to find that they've suffered from severe 'code rot', even when sandboxing. Then finding it basically impossible to recover from because some library version somewhere isn't happy, but the only thing that's reported are cryptic error messages. I've previously had to rebuild my dev environment from scratch on bo…

Luckily, Stack [1] allays a lot of the reproducible build hell that Cabal sometimes provides. I would highly recommend trying Stack out before deciding that the Haskell package management system is a dealbreaker for you. More and more open source projects are using it - and if they aren't, perhaps that could make a good first contribution to a larger project (if you're having build trouble with vanilla Cabal, others…

Thanks for the heads up, I will take a look :)

Re: What is a stateless user interface?

#27

Post by louthy »

cwp wrote: post #20
louthy wrote: post #14

I think cabal is the primary reason why I do far less Haskell coding than I'd like. Coming back to projects to find that they've suffered from severe 'code rot', even when sandboxing. Then finding it basically impossible to recover from because some library version somewhere isn't happy, but the only thing that's reported are cryptic error messages. I've previously had to rebuild my dev environment from scratch on bo…

You might want to look into Nix for Haskell development. Nix a pure, lazy, functional DSL for describing packages and dependencies, and thus naturally attractive to Haskellers. As a result, there's good support for Haskell in the nixpkgs package collection, and helpful folks on the mailing list if you run into trouble. Stateless, deterministic builds are what nix is all about!

Thanks for the heads up, I will take a look :)

Re: What is a stateless user interface?

#28

Post by kazinator »

chongli wrote: post #19
kazinator wrote: post #9

Earlier quoted context omitted.

There are ways forward. For instance, instead of a small number of tools which mutate their state, why not let the user clone variants of the tools which are configured differently. Let me configure two or more copies of the move tool, one configured for layers and one for selections. Let me give them different icons and let me position it in a custom toolbox. Don't make me do the equivalent of swapping bits on a mul…

The gimp already has this feature. It's called presets and it works well enough. Just set up your tool exactly the way you want it and then save a preset. You can even configure the preset so some settings (such as colour) pass through the preset.

If it exists in the version I'm using, it is certainly not discoverable. I don't see any hint of this in a two-level-deep manual search of various menus. I would expect to find osmething like this if I right click on the toolbox (context menu pops up, with one of the choices being "Add New Preset ..." or whatever). Or in the Tools menu, with a menu item being "Manage presets ..." or whatever.

Ah, finally found it. You have to click on the little docking triangle on some specific Tool Options dialog for a given tool. It is in this docking-related menu that a command is found to bring up the Tool Options Menu! I think I didn't notice it before because it's totally "off topic" for docking. (Why would a semantically important feature be found under a little docking triangle?) It is this Tool Options Menu which has the preset management commands.

If you right click anywhere on the Tool Options, you get context menu with one-button context menu which says "Tool Options". When you click that button, it just disappears: there you are in Tool Options as before! Right clicking on a Tool Options object would be the obvious place to have the Tool Options Menu. Then the preset stuff would be more discoverable.

Re: What is a stateless user interface?

#29

Post by eru »

kornish wrote: post #15
louthy wrote: post #14

I think cabal is the primary reason why I do far less Haskell coding than I'd like. Coming back to projects to find that they've suffered from severe 'code rot', even when sandboxing. Then finding it basically impossible to recover from because some library version somewhere isn't happy, but the only thing that's reported are cryptic error messages. I've previously had to rebuild my dev environment from scratch on bo…

Luckily, Stack [1] allays a lot of the reproducible build hell that Cabal sometimes provides. I would highly recommend trying Stack out before deciding that the Haskell package management system is a dealbreaker for you. More and more open source projects are using it - and if they aren't, perhaps that could make a good first contribution to a larger project (if you're having build trouble with vanilla Cabal, others…

And converting Cabal projects to Stack is really easy: at least for the simple projects I've tried Stack's automated conversion tool did all the work.

Re: What is a stateless user interface?

#30

Post by eru »

louthy wrote: post #26
kornish wrote: post #15

Earlier quoted context omitted.

Luckily, Stack [1] allays a lot of the reproducible build hell that Cabal sometimes provides. I would highly recommend trying Stack out before deciding that the Haskell package management system is a dealbreaker for you. More and more open source projects are using it - and if they aren't, perhaps that could make a good first contribution to a larger project (if you're having build trouble with vanilla Cabal, others…

Thanks for the heads up, I will take a look :)

The developers are stack will be really, really happy to hear your thoughts, when you used stack.

(I know this because they kept following up with me a few times, until I finally got around to giving it a try.)

Post reply on HN