It's been a decade+ since I used to catch the Green line at Park St, but at that time it was the noisiest, squealiest station that I regularly used. Not surprising to learn that parts of that station are left over from the 1890s.
IMHO there's no gatekeeper of what the "real" web is or should be. It grew organically - regular people building things they liked or needed. It's certainly more of a life necessity than it used to be, but that happened organically too.
I know there are strongly held opinions about this, but I for one see no reason why the "application web" can't peacefully coexist, and interlink with, the document web. In my opinion it therefore makes sense to allow for different models for the application web, ones that do not revolve around a document.
On the other hand, if we're just bashing on javascript being the lingua franca of the web, that's a train I'll happily board!
I've got a pretty large flutter app in production, using just the flutter-provided building blocks like ValueNotifier, ListenableBuilder, InheritedWidget, etc. It has scaled quite well for me.
The main issue IMHO with many of these boilerplate-reducing packages is that they feel like one-way trips. Most of them require a change to widget inheritance, and they all have slightly different syntax and semantics for wiring things up to state changes. This means if you get a few years into a project, migrating away from the package you chose at the beginning will probably be very difficult.
So while the quick example in the readme of this package looks simple and understandable, locking in to a third-party library makes me nervous, especially if the main benefit is just fewer keystrokes. Does anyone have experience or informed opinion here that would be willing to chime in?
I believe that no matter what framework you use, you’ll encounter similar challenges. Every framework introduces its own complexity by nature — the key difference lies in whether its abstraction can reduce the complexity of building sophisticated applications to a manageable level.
To me, the strength of a framework isn’t just about reducing how much code you write — it’s about providing a way of thinking that helps developers build and maintain applications more easily.
For this project, my goal is to fully leverage the composability of Vue’s Composition API and provide automatic dependency tracking to help developers write cleaner and more reactive Flutter applications.
I still haven't found a way to coax MathML into looking the way I want it... Even using the same fonts (like Computer Modern or its descendants) there's still something not quite the same as LaTeX-drawn math. It's a nitpick but noticeable for me.
Been a happy customer of Fastmail for ~10 years now. Nice web and mobile interfaces. I've never been impacted by downtime in that time (to my knowledge).
Thank you very much for all this feedback! I really appreciate your consideration.
For your note on different states for screens. Can you elaborate or give an example? I'm quite interested in this mode that you're describing.
The ellipse issue sounds like snapping getting in the way. It's on my list to come up with a better heuristic of when to apply snapping or not. One example of an idea I have here is to incorporate some hysteresis effect - essentially examining the local history of mouse movements when deciding to apply snapping or not. Right now each mouse movement is treated independently.
Also, were you in dark mode? It's definitely not intended that the whole screen should change color - a popup should dim the content behind. The whole screen changing color sounds like a bug and I'll investigate.
>For your note on different states for screens. Can you elaborate or give an example? I'm quite interested in this mode that you're describing.
I meant the very obvious feature (you might already have it) of objects with properties and a unique id, then a state that indexes snapshots of those objects with different properties. With the ability to diff between states by id of the object. So State1:[Square{id:0, x:0, y:0}], State2:[Square{id:0, x:screen.width, y: screen.width}], where going from state1 to state2 would tween the square from top-left to bottom-right.
I am assuming you already have something like that (you already have the objects, the properties, and some states like undo/redo) and it's about exposing the ui around it with labeled states at the user-level.
> Also, were you in dark mode? It's definitely not intended that the whole screen should change color - a popup should dim the content behind. The whole screen changing color sounds like a bug and I'll investigate.
That's what it was! I tried with light mode in firefox and it worked much better.
Ah, ok - thank you for elaborating on that. I don't actually have that type of interactivity at the moment, though you're right in saying all the information is there in order to make it happen. I also like your idea of changing between the states via some collapsible menu. In theory all of this could be achieved just by building on what's already here. Do you mind sharing what sorts of things you might use this for?
Glad to hear dark mode was the other issue :-). I'll investigate further, it's probably just a matter of a flag not being propagated properly during the scene change.
This is a great point and not one that I had considered. I suspect I am the same way - scanning back and forth while studying a diagram.
It's possible this tool may be more appropriate for e.g. presentation of info to a mixed audience. Technical people may have questions that can be answered with detail that non-technical people would find distracting, if it were visible on the main diagram. And "presentation" here could be a literal presentation in a conference room, or documenting something on a site that people visit on their own.
You could make the argument in that example that you should create two diagrams, one for each audience. I think that is a valid argument - but I can also imagine maintaining two separate diagrams that present similar information could be irritating.
If you're fond of state machines as an abstraction for system design, I highly recommend reading the Harel statechart paper. It's well-written and understandable. And, it's truly a useful extension of the type of state machine diagrams software engineers typically produce.
Is there a modern reference implementation of statecharts? My understanding is that there's tons of offspring and they all kind of disagree. Same with regular FSM at least from limited understanding from this book https://ptolemy.berkeley.edu/books/leeseshia/.
I'm a little worried the author (Lee) may have a particular PoV and perhaps this wasn't the best resource to learn from?
I'm building an automated environmentally monitored +. controlled mushroom fruiting chamber. V1 I got by just with very basic state machines but I'm trying to take it up a notch in sophistication and do it the "right " way.
The ?modern reference specification is UML statecharts. However I'm under the impression that not all features are efficiently implementable. For example Miro Samek's book covers a subset for real-time systems: https://www.state-machine.com/psicc2 I highly recommend that book even if you end up rolling your own implementation.
Thanks! A quick glance at the book and it seems like it's focused on event-driven. Also seems kind of aligned with Lee's "actor model" stuff. I will read it more.
I am ok-but-not-great programmer, hence trying this project to get better. It seems like I should learn UML proper and this book looks like a good way to start; my "architecture" diagrams are pretty laughable. I bounce between trying to be formal and learn what "proper architecture diagrams" are vs. thinking I'm spending way too much time not coding.
I'm on a dirty and probably not-so-great hybrid of timer + event (mqtt) right now. I really want to try fully event-driven but it's a big change and I'm not very familiar with what it would entail. My original goal with this project was to implement MPC from scratch. V0 was mostly learning esp32 stuff and very basic bang-bang and timer control + FSMs that probably matched no formal specification. I've finished(or at least froze) the V1 microcontroller am starting the basic control/"driver" layer now, which is FSM based, so this reference is perfect timing. Thanks again!
Yes, very event/message-oriented. The state machines exchange messages and process them to completion. I'm not sure who Lee is (Actor Model proper is Carl Hewitt, Gul Agha) but it's interesting that you make the connection, I agree. Erlang, the actor language that never heard of the actor model, has an FSM class that is also interesting to look at.
UML is a standardisation of a bunch of different techniques for drawing pictures about systems. Drawing pictures can be useful for thinking about things, especially if you're a visual thinker. But statecharts are really the star of the show I think, they represent something that is easier to understand as a picture (hygraph) than as code.
There is for JavaScript called XState. I think it is SCXML compliant .You might also take a look at qmuntal/stateless (not SCXML compliant), a golang module. It has rudimentary sub-state functionality.
I'm in the process of writing a golang library, if you're interested in seeing some raw development (IE, I'm in the middle of designing dev UX, and the guts of the lib have yet to be implemented).
You may also consider n8n for your uses. As workflow management goes, it is quite robust.
For embedded work, I honestly don't know. I do know that golang can be transpiled into C (https://tinygo.org/) and tinygo + qmuntal/stateless might work really well for your use-case.
Thank you so much! For context, this for a "driver" running on a pi that controls actuators on an esp32 via MQTT. So the the most basics states just clones of the states (On/Off) on the esp32, while more complicated states would combine actions like fan + humidifier. I've written everything on the pi in python so far. But that was all V1 and I'm starting over so maybe I'll try something new.
You might map out your functionality and see what you actually need in terms of programmatic functionality. LLMs are actually decent at creating the boilerplate if you know what you need.
Here's an example I had Claude throw together for states/substates for a door with a lock
stateDiagram-v2
[*] --> Closed
state Closed {
[*] --> Locked
Locked --> Unlocked: unlock / disengageBolt()
Unlocked --> Locked: lock / engageBolt()
}
Closed --> Open: open [unlocked] / swing()
Open --> Closed: close / checkSensors()
note right of Closed
Composite state with
two substates
end note
note left of Open
Simple state
end note
Locked: entry / engageBolt()
Unlocked: entry / disengageBolt()
Open: entry / startTimer()
Open: exit / stopTimer()
The syntax in the text labels is written the same way the Harel paper proposes: <State>: <entry/exit> / <action>()
I want to be able to do things like prove certain bad states are unreachable or that a certain state of the system will eventually be reached, stuff like that. I'm intrigued by the idea of analyzing/enumerating traces and the dynamical systems perspectives of trajectories through state space (background in physics- statistical mechanics).
My thinking is that the more formal and precise I am with specifying the state machine to begin with, the easier the analyses/modeling will be. I'm following a configuration-driven approach where the whole system is specified/composed from YAML/JSON, so I was planning in this iteration to come up with like a pydantic model to specify state machine behavior.
I haven't looked into 'formal' verification methods for FSMs, so I did some light googling. I found this guy [0] which gives an overview of potential methods.
I'll have to think about testing methods more. There are a few things I would want to know about a single FSM: does it exit (various exit states, either error final state or valid final state), are there unreachable states, does it loop in places it shouldn't, does it enter states it shouldn't for a given stimuli (Events + Guards are the params for this test). I think there's also a place for event fuzzing to try and break the machine.
It's not available, but I once made a researchy Statechart->Java compiler. For the concurrency, it leaned on Java's green threads.
Since then, I sometimes do manual implementations in code. For example, the Swift code of an iOS app I wrote has an ASCII art diagram of a hierarchical Statechart, for making the UI and NFC event handling solid (despite SwiftUI quirks and inconsistent docs at the time).
I discovered the above implementation about the time I finished reading through the paper. I need to go back through and finish taking notes.
I think there might be room to add `any` and `all` guards that take many guards as arguments.
The other thing I've been pondering is the apparent similarity between ASTs and the sort of graph a statechart forms. If we compress state and chart into a single object, now you have states that can have parents and children (the semantics of what is an active state would vary with your node type, IE compound or parallel). Then your edges would the transitions between nodes.
The semantics of the whole thing starts to look vaguely like there's a programming language that could emerge if the intermediate representation is hammered out well enough.
At Amazon Robotics we built a robot control system that executed state charts (described in an extended version of SCXML) in real-time for managing the core behaviors of the robot.
To help people not have write the charts by hand, we built a DSL (originally in python, then in Kotlin), to author robot behaviors that then compiled down to SCXML. Conditions on guards were written in a tiny expression language we wrote, enabling you to look at various signals from the hardware and software at runtime and make decisions based off them.
The nice part of this setup was that it opened up a path for doing more formal analysis on the behavior. E.g. you could easily find "terminal" states that you could enter but not leave. You can also imagine things like checking things like which states in a parallel or in concurrently running machines, aren't allowed to be active, and verifying there is no path in the state graph that allowed that to occur. There were other nice properties as well, like getting a graphical visualization of your program state "for free"
It was definitely a more constrained model than a "full featured" programming language, but for our use case, controlling machines in a reliable way, it worked out very well!
I appreciated this - well written and useful review of their business and why they think it didn't work.
In addition to the challenges listed here, IMO there are rapidly diminishing returns for the type of recall learning that spaced repetition enables. As you progress further in your career, there is much less emphasis on what you know, and more emphasis on how you apply it, how you communicate, and how your knowledge ends up helping others around you. I suspect most professionals decide at some point that they need to start "paging out" specific knowledge to make room for broader experience, retrieving it from the bookshelf (swap partition) when needed.
I'm also curious on the fixation with creating a startup in the VC-funded sense. Why choose able-to-find-VC-funding to be your metric of success?
For my day job I'm either "Getting things done" or Zettelkasten anyway because it's more about retrieval than memory.
But for languages, SRS is great.
And I'm also glad I memorised a whole bunch of math formulas way back. E.g. Boolean algebra I keep using an identity that I couldn't find on identity sheets by web search.
If you're not restricted to Bezier for graphics (it's a very common choice as the path primitive for vector graphics), there are other classes of curves that you may find are a better fit. In particular, I think animations typically feel better if they move at constant speed - which is nontrivial with Bezier curves because they do not have an exact closed-form arc length parameterization. Something like pythagorean hodographs could be a better fit for your application.
I am not a mathematician though, so if you have other insight I'd be glad to hear it.
Instead of using closed form, they can easily computed with the approximation of the curve with segments, and you place the points where there is most curvature or where the 1st derivative isn't close to zero
Yes - but there are other curve classes (like P-H) that have an exact solution and don't need approximation. Bezier curves have tons of nice properties but also a lot of shortcomings, for example not being able represent conic sections like circles and ellipses without introducing weighting (rationals), which complicate computations even further. So, depending on what you're doing with them, it's worth exploring other curve types IMO.
