11–20 of 30 posts
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.
Earlier quoted context omitted.
Image editing is one of those great examples of the workflows being so diverse that no generalized interface solution will be very good for all of them. What's tickling my brain at the moment is the idea that these complex apps might be better as languages first, just shipping with thousands of well-organized example scripts that cover all the bread and butter - in the same way that synthesizers moved towards being p…
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…
If you want this worked on, you should contribute to the project. Not saying you need to learn how to actually code on Gimp, but just to add your voice to the mix.
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'm not a hugely experienced Haskeller, so I've almost certainly made 'classic mistakes', but as a system it is so unstable that I couldn't really commit to any large projects, which is a shame, because I really, really rate Haskell as a language.
In stepped F#, and although not as nice a language Haskell, the tooling works. It would be great to see this resolved once and for all.
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…
Maybe less unnecessary or confusing state could be a good thing, but taking state out of interfaces altogether sounds like throwing the baby out with the bathwater. The whole point of interfaces is interacting with and modifying the state of the computer based on what the current state of the computer is, after all.
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.
Beautifully succinct and widely applicable. It is a gem, thank you.
Earlier quoted context omitted.
Image editing is one of those great examples of the workflows being so diverse that no generalized interface solution will be very good for all of them. What's tickling my brain at the moment is the idea that these complex apps might be better as languages first, just shipping with thousands of well-organized example scripts that cover all the bread and butter - in the same way that synthesizers moved towards being p…
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…
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…