Help users select a hierarchical state machine for C?  - Page 1
Forum section: electronics / beginners

author: jnz
author_rank: Frequent Contributor
timestamp: September 07, 2022, 08:27:23 pm
content: I'm not really a beginner. I just see so much code duplication and NIH syndrome around state machines that I wanted to examine options found on github, to see if there was at least some base consensus that "You could probably do worse than this one". I recently took over a project that had a poor FSM that was initially reasonable but ballooned into a mess of overwriting events and unexpected transitions. I fixed it, but eventually may replace with an HSM.I found a few options and while I don't need one right now, I think I'll probably try them out soon. So.... Thoughts on these?1.https://github.com/kiishor/UML-State-Machine-in-C- last update 3 years, 9 watchers, 33 forks, 100 stars- primary .c:https://github.com/kiishor/UML-State-Machine-in-C/blob/master/src/hsm.c- I personally hate pre-processor statements like he has. I think it's unprofessional and difficult for no reason. Esp because he is putting them in to limit function arguments!- But, otherwise, the main loop is pretty reasonable.- All variables for the statemachine to interact with a included in the base statemachine object. Keeps things locally contexted which is nice.- I like that handler() per state only need to return HANDLED, NOT HANDLED, or SELF-TARGETED- The process here is you need to write a function/handler for every state (optional entry and exits) and that you are manually coding the transitions/traversals where every handler will probxhly have its own switch statement. It’s sort of a lot of switch statements.- Includes no obvious way to get event data / context in the machines. Seems easy to add to the object that contains the EVENT (state_machine_t)2.https://github.com/TheHumbleTransistor/HTHSM/- last update 6 months, 7 watchers, 4 forks, 23 stars- primary c:https://github.com/TheHumbleTransistor/HTHSM/blob/master/src/HTHSM.c- The code practices seem good- The state nesting process is by explicitly defining substates via a macro.- Spelling mistakes and issues with example code.- Unlike others, entry and exits are switch cases and not separate functions. There is one handler per state.- Recursively searches states, could get stack heavy on a complex machine- Offers a normal continue, as well as a skip superstates process, for when you want to transition to another state but not call the other states methods (emergency skip, or state teleporting)- Appears to strongly favor a queue of events. Test code uses MSSYS sys/queue.h that you likely won’t have on embedded. Plenty of options there.- No obvious way to include event context. All events are integers. Including extra data per signal is up to you.3.https://github.com/howard-chan/HSM/- last update 4 years, 6 watchers, 28 forks, 55 stars- primary c:https://github.com/howard-chan/HSM/blob/master/hsm.c- I don't think naming a C variable "*This" is good practice. I get it, but *me and *this are still better than *This.- Much of the C is spent allocating the states to each other by code and not by define- Excellent documentation / readme. Easily the most complete example. Intention of how to use this code is clearly defined. Diagrams are meh ascii, but work.- There is an obvious way for data context to arrive at a state. Although seemingly a similar but separate way to get a *param to entry/exit handlers.- Almost seems like they went out of their way to not use switch statements in favor of if-else blocks. - Possibly because they also wrote a Python version long before there were switches.- Does not just assume you have OS functions or even printf(...), includes a general function call to put your own print functions in, smart.- EXCELLENT logging options including levels, colors, and other advanced features. Ability to supress logs for one chatty run, enable human readability, indented logs, etc. Someone really considered how this would be used.- Along with normal ENTRY and EXIT, an INIT is included to guard or automatically transisiton to a start state. So it's possible to go from one state anywhere to another, or some state to a new parent state with a default start point. Some options don't allow for this and you must always transition to a sub-state if there is one.- Is not designed or mentions event queues, but no reason they couldn't be added to ensure you aren't overwriting an event while inside the machine4.https://github.com/MadsAndreasen/HierarchicalStateMachine/- last update 5 years, 5 watchers, 7 forks, 19 stars- primary c:https://github.com/MadsAndreasen/HierarchicalStateMachine/blob/master/c/hsm.c- Code is slightly difficult to follow, double pointers and single letter variables, cool guy style5.https://github.com/jawebada/libmbb/- last update 8 years, 3 watchers, 6 forks, 19 stars- primary c:https://github.com/jawebada/libmbb/blob/master/mbb/hsm.c- I read this one the least, just found it, but seems very easy. Good coding practices.- Includes an implementation of queues. Good, you won't overwrite an event, bad it's just another thing.- Functions included to traverse the HSM seem nice to have (is_in, is_ancestor). Seems to rely on more than just a pointer to parentI know lots of people will say "I have one that is better than all of these"... but if you didn't post it to a public git, it doesn't really count!Anyone have thoughts on these or want to add to the list? If I had to pick one off the top of my head, I'd have to select #1 and remove the stupid pre-processor argument modifiers, but it's mostly because of the number of stars, age, and initial readability.

author: Nominal Animal
author_rank: Super Contributor
timestamp: September 08, 2022, 06:05:19 pm
content: State machines are simple and configurable enough that I've never seen the need for a library implementation.It seems to me you completely ignored the very key point for me: maintainability, which you could split into documentation, verification, and testing.Since I dislike code generation, I typically create an unit test/build target that checks/validates/explores and emits the exact machine structure, usually in Graphviz format; and when I'm happy with it, I create some kind of grid-based visual representation using various tools (sometimes even directly emitting the machine description in SVG).While most implementations tend to have warts and other imperfections, I've found that the most important thing for long-term maintenance is us humans correctly understanding the machine states and when, why, and how the transitions are implemented. So, not so much a "code" problem; much more a "documentation" problem.How are you doing the documentation side, jnz?

author: jnz
author_rank: Frequent Contributor
timestamp: September 08, 2022, 08:10:48 pm
content: Look at the .c file for each, I don't think that's work that should be re-done over and over.None of this is code generation, so I'm not sure what you are talking about there.My personal choice for machine documentation is PlantUML state diagrams. Committed with their PNG into GIT. Markdown+PlantUML when they are lined out and tested, so that not only do I have an HSM state chart, but I have the human who wrote it explaining the intention of each state and event.

author: Nominal Animal
author_rank: Super Contributor
timestamp: September 08, 2022, 10:31:19 pm
content: Quote from: jnz on September 08, 2022, 08:10:48 pmNo, but every single state machine I've ever implemented has been different.Quote from: jnz on September 08, 2022, 08:10:48 pmThe problem with that is that you do not have any way to ensure the code does what the state diagram says. This is a major source of errors, especially when the human switches jobs and you're just left with what they wrote.So, to fix those issues, the typical next step is to find a way to describe the state machines in a way that allows the necessary C code to be generated automatically. (Compare to e.g. flex+bison parsers.)I and others have gone that way, and found that it has its own set of problems, and is rarely a good solution. (In the cases it is a good solution, tools like flex and bison tend to already exist, and you tend to look at things from a Backus-Naur-like perspective anyway.)The solution path that has worked for me, is to implement the state machine core and state tables in a sufficiently modular way, so that I can use the code for A) for the original intended purpose, but also B) to generate the state machine description and documentation in a human-readable way.None of the sources you referred to have any kind of support for actually describing the state machine accurately. Your documentation does not describe the state machine, it describes what the human who wrote the documentation believes is a description of the state machine.A typical implementation is of an user interface. To support autogeneration of the full state machine graph, you want each possible translation to be described in the data structures as opposed to C code. (You will always have C code thattriggersa transition; you just need the data structures to list all the possibilities.) Hierarchical state machines work well when the user interface contains user tunables or configuration values, but they also make it possible to limit the detail/depth into which the state machine documentation reaches into; for example, if just 4-5 differenttypesof tunables are used, there is no reason to repeat the edit procedure for every single tunable. On microcontrollers, I like having my states stored in Flash only, which also affects how the states are described.For something more like a file format parser, the preferred implementation is rarely a nice state machine, and instead certain hierarchical levels are implemented in the code somewhere that makes no sense at the state machine graph level; for example, because cache locality affects throughput, and certain operations are just more efficient to do in a certain order. Such constraints cannot be described in a state machine graph in any sane way.As an example, some time ago I found myself needing to share a single UART channel (bidirectional, full duplex serial binary stream) between Linux terminal console, and a microcontroller managing a small display and some buttons, for a tiny network appliance. Because one sub-stream is latency-sensitive, you don't want to use stuff like netstrings that leads to buffer bloat, but something lightweight that can switch between sub-streams anywhere within a few byte boundary, with obviously as little overhead as necessary. My solution is an escaping scheme that requires only three or four bytes of buffering, has an absolute maximum overhead of 33% (in 3, out 4) or 25% (in 4, out 5), and is easily described as a state machine. However, since the comms with the microcontroller need a sensible format also, I developed a list-based hierarchical format, performing the same function as XML, but trivial to parse. Trick is that the bytes reserved for the data format structures are escaped at the sub-stream level. Essentially, on the microcontroller, I have a tight little state machine that provides console output and consumes console inputs, consumes user interface button events (with debouncing and autorepeat), and transfers data nodes (lists, in my case) between a display manager subsystem.Now, how do I document that in a way that allows someone else, say after I die, to reuse all that good work, not just maintaining the device, but also reuse and extend it?If your solution is to have me write a description of it in 'prose', or say as images and diagrams, then you must understand that that would just be a description ofmy understandingof the code. To me, that is not sufficient. I want A) a diagram generated from the state machine itself, so that it describes the state machine and not someonesunderstandingof it, and B) ways to test the state machine, for example to ensure that every UI state is reachable within a small number of events, that every UI state is reached, and that no UI state is a dead end.As I mentioned earlier, my solution is to implement each state machine the way I believe is most appropriate (and thus far, it greatly depends on the use case, so much so that code reuse is really not worth it, especially given the limited resources on the microcontrollers I use), in a way that lets me write additional code used only during build time (i.e., not included in the final firmware at all) that can describe and test the state machine for me. When that is not possible (for example, the above UART channel multiplexing and structured data formatting, because a traditional state machine implementation would be way too slow and inefficient), I implement separate code to be run on the target firmware, and a naïve instrumented implementation that can do the testing and describing for me, and build test cases that run both for each input, and verifies the outputs also exactly match. While I cannotprovethat the two are identical, it is easy enough to construct both normal and abnormal (pathological) input cases –– intentionally invalid, say bit-flipped inputs ––, as well as purely random inputs, to ensure at least astatisticalprobability of bugs/correctness. It also provides a nice way to test future changes and additions, as long as the two are always kept in sync.See? For me, things like these are just tools, and I cannot in good conscience select a tool based on how attractive it is to me. I need it to be multi-functional, since anyone as verbose as I am can spout out simple but robust ones to a desired probability of suitability faster than I can evaluate an existing implementation to the same probability. Code is easy, but thorough reliable documentation very hard, and just as important for longevity/maintenance as the code itself is. It is the latter that is usually lacking in the existing solutions, but would make a big difference to the end products and developer sanity (and frequency of burnouts).

author: golden_labels
author_rank: Super Contributor
timestamp: September 09, 2022, 05:40:35 pm
content: Doesn’t this thread belong toComputers → Programming?MadAndreasen’s HierarchicalStateMachine can be eliminated instantly: it misses licensing terms. And it does despitea request has been madeto provide that. It was closed by the reporter himself, but nonetheless that should at least be a hint to the maintainer that something is missing.howard-chan’s HSM looks like a half-baked idea, which received little attention and was abandoned in that state years ago. Little activity from the author on GH(1)is an indication that downstream will be left on their own. The project has no tests, which are the primary value you get by using a ready solution for a state machine.That leaves you with three options. And no one will tell you, which one is the best, because “the best” requires constraints. You must have specific goals and teast each candidate to see how well it fits the scenario.(1)They may be active elsewhere, but we have no way to tell that.

author: jnz
author_rank: Frequent Contributor
timestamp: September 10, 2022, 04:42:18 am
content: Quote from: Nominal AnimalYea, I can’t get into all of that… but you made the points that…- it’s so easy you would never use a library- every time you write unique code that makes its own documentation…- by coding to with something like a plantuml diagram I have no way to tell that my code is doing what it is supposed to, if I use a library, apparently I could never test- by coding to GraphViz you can be exactly sure your unique every time code is perfect because of course you’ll test itI think I see your point of view. I knew a guy who wrote similar things, works at the National Institute of Health.

author: jnz
author_rank: Frequent Contributor
timestamp: September 10, 2022, 04:58:05 am
content: Quote from: golden_labels on September 09, 2022, 05:40:35 pmHow is the Howard-Chan a 1/2 baked idea? In what way? Because I spent time with all of these now and it is by far the most complete. The logging alone on this one is superior. That each event get a pContext is good. Maybe I missed something?The 2nd most stared and forked “received little attention”?I also can’t really bag on someone for not pushing to a public GitHub or code age. You don’t have to use it, age doesn’t infer completeness, and if you were to look at my public GitHub, it’s bare bones empty yet I’m working on firmware and projects and managing employees doing the same every single day.Lack of tests I agree with. But if you actually looked past the tests folders on the others, all they do is define the world’s simplest machines and with basic inputs run through each state A>>B>>C>>D>>A. The tests barely go more than one level deep. Curious for code bases that mostly work on recursion. If this was a deal breaker, just run the Howard-Chan code with your own basic test, and then fill it out with a proper test like you should regardless if they did or not.What did Howard-Chan do to you anyhow?

author: bingo600
author_rank: Super Contributor
timestamp: September 10, 2022, 06:26:05 am
content: I think Miro's is free if you can live with GPLhttps://www.state-machine.com/https://www.state-machine.com/licensing

author: Nominal Animal
author_rank: Super Contributor
timestamp: September 10, 2022, 08:18:57 pm
content: Quote from: jnz on September 10, 2022, 04:42:18 amNo, I wrote that"No, but every single state machine I've ever implemented has been different."It means that using a library would have constrained the surrounding code to a less than optimal API.It is the same problem why the Linux kernel does not have a stable internal API. No, it is not because they hate out-of-tree developers, it is because having a fixed API for something internal is a development constraint. Such constraints lead to extra complexity (elsewhere) and thus maintenance burden. It is a simple evaluation to decide whether the library saves enough resources (time and effort) to account for the internal design restrictions. I love to use well-written libraries; it's just that for state machines, I've found that the implementation is so cheap that the internal design restrictions cost more than using any of the ready-made libraries I've seen would save.Quote from: jnz on September 10, 2022, 04:42:18 amEvery time I write code I write unique tests that (try to) verify that the code does what the documentation says it does. For things like state machines, complex data structure management (like trees, forests, heaps, and interlinked trees, lists, arrays, and heaps), it iseasierto reuse the core code, and write "test cases" that instead of testing specific input versus output,describethe structures generated. If you do it in a form that illustrates to the human user those data structures and how they work, those descriptions work wellas documentation.I do it, because in the long run, it saves effort, and increases the quality of my work product. I'm ridiculously far from perfect, but I'm willing to put in the effort needed to have that output be reliable, robust against unexpected input, andusefulin practice.Quote from: jnz on September 10, 2022, 04:42:18 amWhat? I never claimed anything like that.What I said, is that if I use a library, I want the library to help me do the aforementioned tests and documentation. None of the ones you suggested have any support for those – essentially, by using one of those you trade a couple of hundred lines of already written code to stricts constraints on how you define the state machine, with zero help in unit testing or documentation –, which in my opinion means none of those are worth consideration.I did not say that "if you use a library, you (whatever)". I said that none of those you suggested seem worthy of consideration; implying that maybe you should widen your search a lot, since I would not consider those for anything. I never implied that I wouldn't use a library if one fit my needs, only that thus far, the problems that I use state machines to solve have dictated so different APIs that I never saw the need to look for a library implementation; the implementation has always been dictated by my very different needs in each case.Quote from: jnz on September 10, 2022, 04:42:18 amNo, just no.I often write unit tests that describe complex structures using theGraphviz DOT language. DOT is human-readable, and very easy to emit, and there are a host of command-line tools that turn that output into images in various formats.Visual inspection of such graphs describing state machines is easier for us humans, than reading a prosaic description of such states and trying to construct a mental picture of the state interactions. In many cases, a relatively short description of theeffectsof the state machine, coupled with a clear and complete image of the state machine graph, works better as documentation than what a typical developer can write down about it otherwise.When the state machine graph is emitted from the state machine implementation itself, we eliminate a whole source of bugs, a whole category of bugs: the difference between what the developer intended, and what the code actually does. (I also often mention how important it is that comments in code describe what the developer intends the code to achieve, instead of describing what the code does: "keep a count of the number of changes applied", instead of "increment count by one".)Unit testing is still necessary to help us humans understand what the state machine actually achieves. No matter how good the documentation is, practical tests will ensure the machine design is fit for its intended purpose, but also help future developers understand what exactly does the state machine achieve.Quote from: jnz on September 10, 2022, 04:42:18 amAh yes: when you dislike the message, paint the messenger evil, so you can completely ignore the message. It is easier, if you twist their words into something thatfeelsicky, too, instead of consider the message as-is. Well done; you have a bright future in Social Media, comrade.If you had bothered to do aSearchusing "state machine" as the search term, and limiting to user "Nominal Animal", you could have easily skimmed over and seen what I've written about state machines here in the last two or three years. Here are some pertinent ones, in no particular order:Arduino push-button contact bounce as a four-state machine.In a thread,Generating a finite state machine from legible source, Idescribedexactly how I would do it and why.After doing some real-world experiments since then, I've found that in the cases I've used state machines for, a DSL is a bad choice, because code generation itself is a huge maintenance cost. That is, any problems found in the generated code take a lot more effort to fix than just fixing the code; and these kinds of bugs are relatively common. This is why I shifted into having the state machine be implemented in such a way that the same core could be used to test and describe the state machine state graph.As I am very interested in doing comments and documentationright(that is, in a way that actually works), and do not believe I am always right, in the thread aboutState machines, is this topic taught any more?, Ishowed a diagramand its corresponding "Mealy" machinestate tablefor the classic cat-dog replacement for illustration.You'll also note that I can be very argumentative, and why. No, I don't just jump on anyone who disagrees, only when they misunderstand or completely ignore important details or especially when they state they do not believe my argument or statements without stating why. Some like it, some hate it; for me, it is something that I still need to work on.Therefore: No, I am not anything like the politician you compared me with. For one, I am direct and honest, but very argumentative by nature. Also, I truly try to be useful to others instead of furthering my own opinions, and am easily swayed by a good argument. If you look carefully, you'll see how I concentrate on theopinionsand suggestions, and try (but sometimes fail) to avoid characterising the person having the opinion. Yes, you can find a post where Dave himself calls me a troll, but you can also find posts where Dave calls my post the post of the week. It is normal, really, when the conversations are direct and honest. If you look at e.g my recent threadasking for led backlighting suggestions, or indeed compare my opinions across a subject over the few years I've been a member, you'll see that I not only do change my opinions based on good arguments, but also truly appreciate it; and moreover, I definitely do admit it whenever I'm proven wrong. I'm not here to elevate myself or play social games, I'm here to learn and help others; to be useful in general.Also, don't bother try painting me as a "Linux zealot", either. Tux is my mascot only, not my idol, and I frequently use about a dozen different software licenses all the way from Public Domain/CC0-1.0 (in my examples) through GPL and BSD to fully proprietary licenses.

author: jnz
author_rank: Frequent Contributor
timestamp: September 11, 2022, 04:43:01 am
content: Quote from: bingo600 on September 10, 2022, 06:26:05 amYea, QP is an interesting topic. People seem to like it. For me, the licensing would be a deal breaker. It would be $3500 or so per product if I wanted to use it. That’s a lot for what it is.I also hate their “IDE”. I’m not sure I want a 1990s GUI in my tool chain. Also, it’s a whole new syntax, DSL, and process to learn. Its too many steps removed from what I do that actually makes the company money.But I do recognize that people seem to like it.

author: jnz
author_rank: Frequent Contributor
timestamp: September 11, 2022, 05:12:01 am
content: Quote from: Nominal Animal on September 10, 2022, 08:18:57 pmBrother… Think before you start typing. No one has the time and will to read that. In five years, when looking for an HSM, a random is going to see this thread, and I promise they will skip over your wall.Try some time onhttps://hemingwayapp.com/and a word budget less than 400.Instead of a winded monologue, put your code where your keyboard is. Post it and I’ll add above with review as a special example.

author: Nominal Animal
author_rank: Super Contributor
timestamp: September 11, 2022, 12:27:22 pm
content: Ah, I see. You're the "let's throw code and see what compiles" -type of developer, better ignored than interacted with. Done.

author: tggzzz
author_rank: Super Contributor
timestamp: September 11, 2022, 11:41:39 pm
content: Quote from: jnz on September 11, 2022, 05:12:01 amAh. Someone that can only digest short and very simplistic discussionsI suggest you stick to copying what your neighbour does, since that saves thinking and weighing up judgements.OTOH engineers want and need to understand the relative benefits and problems of different techniques.

author: jnz
author_rank: Frequent Contributor
timestamp: September 12, 2022, 10:50:21 pm
content: Quote from: tggzzz on September 11, 2022, 11:41:39 pmNot at all. But I'm of the mind that if you can't explain something quickly. You don't actually understand it. Also, asking someone to invest that kind of time/energy for what should be a few sentances, is a disservice to everyone. I read his posts, the future traveler won't. The point of writing isn't always to think.As expected.... no amazing code will be posted by anyone with strong opinions on the topic. More NIH. If you want to call that engineering, that's fine with me.Quote from: tggzzz on September 11, 2022, 11:41:39 pmAgreed. That's why I make the topic. Did you have an idea why #1 is better than #3 for instance?

author: Nominal Animal
author_rank: Super Contributor
timestamp: September 12, 2022, 11:46:51 pm
content: Quote from: jnz on September 12, 2022, 10:50:21 pmWhat an idiot you are.If you had understood one percent of what I wrote, you'd understand that there would have to be a problem to be solved, for any of us to provide any code.None of us are going to write yourhomework"library" for you, because it is not an appropriate solution here.If you had the capability of specifying an actual problem (that happens to be best solved using a state machine), I'd be happy to write some example code. But you do not, because you have admitted you cannot even solve any problems on your own, much less describe them coherently. You are the sort of "person" who takes stuff others have done, mashes it all together like a ball of multi-colored putty, decorate it with the latest buzzwords, and claim it is good engineeringbased on what the code looks like in your preferred source code editor; with zero understanding or comprehension of the design or functionality or tradeoffs, and no design capability yourself.I wish you'd really switch to something more suited to your "skills", like social media. You certainly have the mindset for that, not engineering or science. I'm sure you could be a famous influencer for involuntarily celibate hikikomoris, for example.

author: tggzzz
author_rank: Super Contributor
timestamp: September 13, 2022, 12:00:19 am
content: Quote from: jnz on September 12, 2022, 10:50:21 pmOn the contrary. Trite short answers usually skip over important preconditions and consequences. Considered subtle opinions are usually long.It isn't surprising politicians like "sound bites".QuoteHe was taking the trouble to address you and your questions, not some hypothetical future traveller.QuoteApparently not, in your world at least.But if you don't want to think, why ask a question in the first place?QuoteThat contradicts your previous statement. Any interesting code would have to be much longer that the explanation, and by comparison the code would be obfuscated.QuoteI think #76 is a better number.

author: jnz
author_rank: Frequent Contributor
timestamp: September 13, 2022, 06:50:02 am
content: I see ad hominem attacks.I don’t see code or review on the samples I posted.What an amazing coincidence.

author: tggzzz
author_rank: Super Contributor
timestamp: September 13, 2022, 07:45:02 am
content: Quote from: jnz on September 13, 2022, 06:50:02 amBut are the comments about justified or not?You fail to address the points made, either deliberately dodging them or failing to understand them. We can't be certain which.

author: golden_labels
author_rank: Super Contributor
timestamp: September 13, 2022, 11:35:36 am
content: Nominal Animal, tggzzz:Do you people really find it is worth your time?I provided a hint, that would allow OP skip 40% of work and focus on the more likely candidates. I got a confrontational response, finished with some delusional suggestion about my message being a personal attack against one of the authors. To me it’s a very clear signal to simply withdraw from the thread.xkcd 386applies.

author: Nominal Animal
author_rank: Super Contributor
timestamp: September 13, 2022, 01:34:22 pm
content: Quote from: golden_labels on September 13, 2022, 11:35:36 amGood question.I do agree that yourreply #4is the most immediately useful reply; I should have Thanked it to express my agreement and support. (Doing it this late feels like it might be perceived as an attempt at manipulation or rewriting history, and I never willingly do either.)However, there is the fact that these discussions are well indexed by search engines. I do not care about the people who find this thread and are looking for immediate answers to the superficial question they think they have; but I do care a lot about the people who are after a deeper understanding, trying to learn, trying to learn things properly and not just on the surface; interested in the technical arts, science, and engineering itself, so they can integrate the knowledge and apply it in their work later on.It is those people that I want to help and mentor. I've been lucky, and have been in that kind of situation many times already, and I can honestly say it is a wonderful feeling when later on they show you what they've managed to create with your initial help/mentoring/guidance: it increases the number of good people and good things in the world. It definitely makes this worth it.Later on, when I am no longer irked by the comments towards my "person" –– they are not, they are towards the output of a pseudonym, Nominal Animal –– I will probably regret my tone and the first paragraph in#14, but not the content from the second paragraph onwards, nor the effort that went to writing it.Back to the question. In my own case, it looked like it would be worth it when I posted thefirst replyto the original post; at that time, the question was already over 20 hours old with no replies. I did have to consider hard whether to post#3or not, but the possibility that my elaboration and personal experience might help those wanting to truly learn to make up their own minds, overrode my misgivings.By#8, I realised the thread is not going to evolve into an useful discussion on implementation of state machines, and instead is devolving into childish "why aren't you just answering my question, I need it for my homework" -type of whining (i.e., OP is only interested in comparing libraries, not their use cases or the reasons behind a selection), but at that point I was already angry about how OP was mischaracterising my posts, and that overrode my misgivings. At#11, I had decided to drop the thread.I did decide to readtggzzz's post, because it is always possible that I had made an error or misunderstood something earlier (and I do want to acknowledge when that happens). By the time I came back to it, OP had already replied, and the way they completely ignored the entire discussion on exactly why none of the suggested libraries seem like a good solution, and just painted that argument as a symptom ofNIH; and that was so incorrect andunfairthat I just had to post#14.The meta-question, "Why did you bother writing this wall of text to answer such a simple question of whether it is worth my time, one that could be considered a rhetorical one?", is simpler to answer: because I find such answersuseful. They are related to the fact that plain opinions are useless unless you are looking at popularity only, but the reasons/facts/experience behind those opinions are immensely useful and even let one evaluate different opinions against their own current needs/understanding/criteria.Sure, some absolutely hate these walls of text of mine, and I've told other members that it is completely okay to ignore me if they annoy or irk them, and I do get it. I just cannot change it. Yet, according to the occasional positive feedback I get, some do find these useful, and the few members that have reached out to me have all definitely been the sort of people I love to help –– trying to learn and understand, instead of just trying to find how to spend the absolute minimum effort to get paid –– so in the balance, itseemsI am contributing positively, even being so verbose.I do have brought my verbosity up for discussion a couple of times, though, and if concluded by Dave or the moderators here that they are less than useful contributions, I will stop posting. I will still read, because there are many members here with lots of experience and advice to be shared, and I find their output extremely interesting and useful.

author: tggzzz
author_rank: Super Contributor
timestamp: September 13, 2022, 01:47:01 pm
content: Quote from: golden_labels on September 13, 2022, 11:35:36 amI can't disagree with any of those points, unfortunately.The first post was not from a first time poster, and was comparatively well thought out, even if it was missing some important considerations. As such it seemed to be worth responding, to nudge the OP into finding ways he should answer his questions.The reason for my later replies is solely to help someone to learn how to approach problems and ask questions -and not piss people off.But overall you are right