Happy Easter
Easter. Enjoyed the time with the family.
Don't you hate it when you have a potentially nifty thought, but you don't feel smart enough to bring it to completion? For what it's worth, here are the rails in my train of thought:
- In user interface design, and perhaps in software engineering, there is a commonly-accepted rule that "modes are bad".
- What are modes? State that affects behavior.
- Why is it bad? You have to remember what state you're in to predict behavior, making it harder to reason about a system.
- What does this sound like? Pure functional programming.
- What could this mean? Here's where I'm not smart enough.
On the other hand, I do very much enjoy stumbling upon a right set of refactorings to get me where I want to be.
follow on Mastodon
follow with Feedly
RSS for the rest
[HTML_REMOVED] [HTML_REMOVED]Why are modes bad?
[HTML_REMOVED]Aren't they the whole concept behind a state-engine program?
[HTML_REMOVED]Are state engines inherantly bad? [HTML_REMOVED]What's a better way to implement a system that requires net-based synchronization and/or massive undo/redo-ing of actions (etc etc etc) if not a mode-based engine that logs/sends the command tokens for each action? [HTML_REMOVED] ... [HTML_REMOVED]...Am I using the wrong terminology again? [HTML_REMOVED]
In UI design, modes are bad because they require the user to always remember what mode their in. And as a side effect of our humanity, our muscular memory doesn't have access to modes so it's better if every command always does the same thing. Read Jef Raskin's The Humane Interface for better sense of this.
In software engineering, it can really bite you if you design a class like this:
[HTML_REMOVED] Class o; o.setBehavior(behaviorOne); o.doSomething();
// later on...
o.doSomething(); // What's the behavior going to be? You don't know unless you check the mode. [HTML_REMOVED]
Or:
[HTML_REMOVED] foo(o);
void foo(Class& o) { o.doSomething(); // What's the behavior going to be? You don't know unless you check the mode. } [HTML_REMOVED]
Also, if you have a class with no mutable state it is called immutable. Java's String is a good example of an immutable class. Why immutability? Because it buys you considerable leeway in terms of implementation. You can pass around pointers instead of copies, you can refcount the internal buffers, substr doesn't have to copy, etc. etc.
State machines are certainly a valuable concept. But they can be implemented without mutating state, too:
[HTML_REMOVED] -- Haskell-like syntax. nextstate :: State -> Input -> State nextstate A 0 = B nextstate A 1 = A nextstate B 0 = A nextstate B 1 = B [HTML_REMOVED]
i think i see where you're going, or maybe not. Interesting thought about how to make something better than remembering states :D