Co-Christian-routines Tismer continues: > Aaron Watters wrote: > > > > The ineffible Gordon McMillan retorts: > > > > > As a fuddy-duddy old imperative programmer, I'm inclined to think > > > "state machine". But I'd guess that functional-ophiles probably see > > > that as inelegant. (Safe guess - they see _anything_ that isn't > > > functional as inelegant!). > > > > As a fellow fuddy-duddy I'd agree except that if you write properlylayered > > software you have to unrole and rerole all those layers for every > > transition of the multi-level state machine, and even though with proper > > discipline it can be implemented without becoming hideous, it still adds > > significant overhead compared to "stop right here and come back later" > > which could be implemented using threads/coroutines(?)/continuations. > > Coroutines are most elegant here, since (fir a simple example) > they are a symmetric pair of functions which call each other. > There is neither the one-pulls, the other pushes asymmetry, nor the > need to maintain state and be controlled by a supervisor function. Well, the state maintains you, instead of the other way 'round. (Any other ex-Big-Blue-ers out there that used to play these games with checkpoint and SyncSort?). I won't argue elegance. Just a couple points: - there's an art to writing state machines which is largely unrecognized (most of them are unnecessarily horrid). - a multiplexed solution (vs a threaded solution) requires that something be inside out. In one case it's your code, in the other, your understanding of the problem. Neither is trivial. Not to be discouraging - as long as your solution doesn't involve using regexps on bytecode <wink>, I say go for it! - Gordon
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4