3 ms·

Would you please elaborate. My experience has been that formal understanding of theory (say of state machines) equips one to handle complex problems and in no w

by sateesh 13y ago

Would you please elaborate. My experience has been that formal understanding of theory (say of state machines) equips one to handle complex problems and in no way indicates how well the code is written. For example, a GUI application code (say) making use of a framework wouldn't give any indication of whether the author had any formal understanding of state machines or not. In my opinion to write a good readable code one need not have a formal understanding of CS theory, but the understanding of CS theory is paramount in writing code for complex problems (say writing a compiler).

blibble 13y ago
7 booleans to try and maintain state instead of a single enum value happens quite a lot in my experience
PeterisP 13y ago
GUI application code actually is one that often can be very clearly thought as a DFA. In particular, the UI often is non-static and can be in certain states, with the effect of user actions (and possibility of certain actions) depending on that state. If it is implemented or "grown" ad-hoc, it sometimes may turn into a jumble of interdependent code and flag/visibility variables, but very often the exact same behaviour can be modelled and implemented much simpler if you think of it as a DFA. For example, the UI of recently popular single-page webapps, where JS is used to change 'screens' without page load, or change functionality by hiding/adding large parts of the page, can often be naturally be thought of as DFA, planned (on paper or wireframes) as states='screens' and transitions between them, and then implemented as DFA. Thinking of UI as a DFA also forces you to consider the 'proper' effect of every user action in every state, which is just good UX practice. For example, in a classic url-based web app you may draw a graph/process of how an user proceeds through making a purchase on your site. Usually it will include only the typical process - but if you think of it as a DFA, you define behavior for actions such as 'requested url /ordervalidation/step2-address' at every state, since the result likely should be different depending on if the user went there from step1 by clicking 'ok, i want to buy this', step3 by clicking the back button, or two weeks later by clicking on a link that he accidentally bookmarked.

by sateesh 13y ago

blibble 13y ago

7 booleans to try and maintain state instead of a single enum value happens quite a lot in my experience

PeterisP 13y ago

GUI application code actually is one that often can be very clearly thought as a DFA. In particular, the UI often is non-static and can be in certain states, with the effect of user actions (and possibility of certain actions) depending on that state. If it is implemented or "grown" ad-hoc, it sometimes may turn into a jumble of interdependent code and flag/visibility variables, but very often the exact same behaviour can be modelled and implemented much simpler if you think of it as a DFA. For example, the UI of recently popular single-page webapps, where JS is used to change 'screens' without page load, or change functionality by hiding/adding large parts of the page, can often be naturally be thought of as DFA, planned (on paper or wireframes) as states='screens' and transitions between them, and then implemented as DFA. Thinking of UI as a DFA also forces you to consider the 'proper' effect of every user action in every state, which is just good UX practice. For example, in a classic url-based web app you may draw a graph/process of how an user proceeds through making a purchase on your site. Usually it will include only the typical process - but if you think of it as a DFA, you define behavior for actions such as 'requested url /ordervalidation/step2-address' at every state, since the result likely should be different depending on if the user went there from step1 by clicking 'ok, i want to buy this', step3 by clicking the back button, or two weeks later by clicking on a link that he accidentally bookmarked.