The terminology of signals (and slots) has been used in Qt [0] since the 1990s I believe.
Still, it is unfortunate that the article begins with “Let's start with an extremely broad definition” (of signals), then continues with what sounds like signals in general, mentioning React only as an example, but then turns out wanting to only talk about signals in the particular reactive UI sense common in web development, without properly introducing that narrowing of focus.
I guess that focus can be expected from a blog on a site about a TypeScript signals library, but from the way the first few paragraphs are written, it’s certainly confusing when reading the article without further context, coming from HN.
“Signal” was used for a time-varying value in a reactive system for a very long time (I thought it was as far back as Fran in 1998, but I was remembering wrong—I was only able to find usage in Grapefruit in 2009, older references welcome). One way or another, in a functional reactive programming system, you need distinct names for:
(a) A thing that happens (or might happen but ultimately doesn’t) and is associated with a value of some sort, such as the mouse coordinates of first left-button click the program sees;
(b) A list of the above with monotonically increasing times, such as all the left-button click coordinates in order;
(c) The above plus an initial value, representing a piecewise constant function of time, such as the state of a toggle;
(d) A (conceptually) piecewise continuous function of time, such as the position of an animated object.
[To avoid “time leaks”, i.e. accidentally retaining all change history from the beginning of time, you also need
(e) A computation that reads the current time, such as the mouse coordinates of the next left-button click the program will see;
but that’s not supposed to be obvious—it took more than a decade to figure out.]
Possible names include: event occurrence [for (a)], event stream [for (b)], event [either (a) or (b)]; behaviour [(c) or (d)—the library may not distinguish them in the API or only provide (d)]; reactive [Conal Elliot’s name for (c) as opposed to (d)]; signal [(b), (c), or both]. All of these make sense in isolation. I don’t think you can win here.
[Perhaps the worst word to use is “stream“, because people start trying to fit streams with backpressure in there. FRP only makes sense as far as you can assume any recalculations happen instantaneously, meaning at the very least before the next input change happens. If you forget that, you get Rx instead of FRP, and that’s not amenable to human comprehension—or indeed sanity.]
> I’m not sure what you mean by "Rx" in this context.
From “reactive extensions”, a name for a family of libraries[1] (RxJava, Rx.NET, RxJS), AFAIK one of the first attempted implementations of mature FRP ideas in the imperative world and one messy enough that it took React’s success for anything similar to reënter the mainstream.
Compare the enthusiastic HN reception of “Deprecating the observer pattern” in 2011[2], mostly by people who heard of FRP in the functional-language setting, and the vitriol it received in 2018[3], apparently from people for whom FRP came to mean Rx (and similarly confused things like Bacon.js). It is this vitriol that I meant to preemptively redirect by the mention of FRP ≠ Rx, so if you’re not aware of this history it’s no big loss to ignore it.
(Yes, I am very much No-True-Scotsmanning this. That should not be taken to mean that reconciling FRP with side effects is a trivial problem, though,—I’m not sure it’s even a solved one. Only that Rx and its ilk suck as a solution.)
> My background is much more in the systems (and indeed, "signals" in the theoretical sense).
> I still think the name "signal" here is quite bad, since it's the abstract concept of something-that-carries-information
I think the intention was to allude to physical wires and conceptual analog or digital things they transmit, as in “reset signal”, “differential signalling”, etc. It does seem to me to be an apt term for a (continuous-)time-dependent doodad in a program, given “variable” is taken.
Your description sounds more like the information-theoretic “channel” or “transmission medium”.
The term signal was used, because RxJS had already taken the term "Observable" to refer to their primitives, which are actually more like streams.
Because of this, Ryan Carniato of SolidJS referred to his own observable primitives as "signals" and this has become the default terminology to talk about this type of pattern within the context of web development.
Really, signals should be thought of as a type of observable.
I felt similarly disappointed, as I was expecting a cool intro to DSP or something similar. But nope, another BS buzzword from the magical world of webdev.
Signal isn't overloaded. It's use here is the same as it's use elsewhere. It just requires contextual information to know what it means. A Qt programmer might think of signals and slots, a UNIX programmer might think of UNIX signals, etc. Jargon sure. Overloaded? I don't think so. Only thing here that bothers me is how vague the title is.
Then I thought for a moment it was talking about a "signal" in the information theoretical sense
All I came away with was that they've invented a new name for event driven architectures and/or data flow programming.
I know naming is hard but we need to stop overloading terms.