<p>So I was considering making a better version of <a href="https://scratch.mit.edu" rel="noreferrer" title="Because I don't have many languages to my name.">Scratch</a>, because I started my programming hobby using it. However, as it stands, Scratch is unsuitable for usual programming, mainly because it's intended for young kids, but event-based programming has stuck with me. Programming with events in Python is always an adventure, and I found myself going back and forth between the web and my program to figure out how to make Tkinter listen for specific events and respond when one was received.</p>
<p>But I wonder what other programmers think about this. <strong>What are the pros and cons of focusing a language around events?</strong></p>
<p><sup>Specifically, a language with bitwise operators, ability to write text on the screen rather than saying it, detecting for clicks and basically everything Scratch doesn't have but the programmer and Cueball demands to have. </sup></p>

<language-design>
What are the pros and cons of focusing a language around events?
CC BY-SA 4.0
2023-05-18T13:32:02.050Z
For the love of programming, *please* make it have proper functions this time
Seggan
CC BY-SA 4.0
2023-05-18T13:32:40.890Z
Proper, as in what kind?
SectorCorruptor
CC BY-SA 4.0
2023-05-18T13:33:15.050Z
Scratch functions can’t return values
Seggan
CC BY-SA 4.0
2023-05-18T13:34:12.027Z
Obviously. I was also planning to allow programmers to import modules and do basic stuff like that
SectorCorruptor
<p><a href="https://en.wikipedia.org/wiki/Event-driven_programming" rel="nofollow noreferrer">Event-driven programming</a> is a popular paradigm, particularly suited for interactive applications and networked applications, which must do things in response to input from the user or a network socket. It's a built-in part of how the DOM works in web programming, and there are many popular libraries which add or extend event-based functionality to mainstream languages. So yes,  events are a perfectly good idea to build a programming language around.</p>
<p>However, like all programming paradigms there are indeed some drawbacks to using events for everything. These drawbacks are well summarised in the book <em>Functional Reactive Programming</em> by Stephen Blackheath &amp; Anthony Jones, which I'll paraphrase here:</p>
<ul>
<li>Multiple listeners to the same event may be invoked in an unpredictable order. There may be logical dependencies between listeners to the same event, which the event listener can't know about.</li>
<li>A listener might not get an opportunity to subscribe before the first event is triggered.</li>
<li>If many listeners update some shared mutable state, the program becomes like a messy state machine that is difficult to reason about.</li>
<li>Listeners on different threads can cause deadlocks, and an event published on a different thread may be received by a listener after it unsubscribed.</li>
<li>A listener may forget to unsubscribe when its owning object is no longer needed. This keeps its callback function in memory, and the callback function holds a reference to the object, causing a memory leak and performance degradation as the publisher still invokes the stale callbacks.</li>
<li>A listener which triggers new events may accidentally cause unbounded recursion.</li>
</ul>
<p>Blackheath &amp; Jones call these the &quot;six plagues of listeners&quot;. To these, I would add another one:</p>
<ul>
<li>If some data needs to be recomputed when any data it depends on is updated, then it may be wastefully recomputed several times if multiple dependencies change at the same time, each triggering their own &quot;update&quot; events.</li>
</ul>
<p><a href="https://en.wikipedia.org/wiki/Functional_reactive_programming" rel="nofollow noreferrer">Functional reactive programming</a> (FRP) is a paradigm related to event-driven programming which addresses these issues, although it comes with its own downsides ─ particularly its conceptual complexity, difficulty of implementation, enforcement of a rigid programming style, and it can make programs more difficult to debug. That said, I have found it a very pleasant paradigm to write in myself, albeit I had to read the aforementioned book cover-to-cover a few times before it clicked. If you're serious about designing an event-driven language, there are likely some ideas in that book which will be useful to you, even if you don't decide to go full FRP with your language.</p>

CC BY-SA 4.0
2023-05-18T13:41:22.143Z
2023-05-18T13:53:28.693Z
2023-05-18T13:53:28.693Z
kaya3
CC BY-SA 4.0
2023-05-18T13:44:12.257Z
By "dependencies" do you mean the triggering events?
SectorCorruptor
CC BY-SA 4.0
2023-05-18T13:45:07.523Z
@UndoneStudios I mean the other data that something must be computed from, and it's expected that the objects which own that data will trigger events when that data changes.
kaya3
CC BY-SA 4.0
2023-05-18T13:48:35.203Z
@UndoneStudios let's say we can define some dynamically computed value: `name = (firstName + lastName)` that will update itself whenever either `firstName` or `lastName` changes. However, if you change both, then it may be recomputed *twice*. This might be potentially wasteful, based on the dependencies and how heavy the computation is.
VLAZ
CC BY-SA 4.0
2023-09-29T22:43:22.717Z
@VLAZ: In some cases, such costs may be minimized by having distinct events for the scenario of "something you may depend upon has changed" and "someone is interested in your present value".  If notification that a dependency may have changed causes an object to set a flag and notify objects that may dependent upon it, if its flag hasn't been set yet, a chain of dependencies shouldn't cause recursion.  Trying to evaluate something may yield recursion, but that can be detected if one keeps track of what nodes have been visited while evaluating a value.
supercat
CC BY-SA 4.0
2023-09-29T23:01:37.393Z
@supercat Sure, that's essentially lazy evaluation; but it only works in event-driven programming if there aren't further downstream listeners who want to be notified when the value changes. If the value isn't computed until it's requested, then it has to be requested, it cannot be subscribed to.
kaya3
CC BY-SA 4.0
2023-09-30T14:57:31.597Z
@kaya3: If a system supports a means of enqueueing deferred events (analogous to `SetImmediate` in Javascript), the "value has changed" can propagate to invalidate everything while entities interested in the value set up an event to fire some time after the invalidation pass is complete.
supercat
# What are the pros and cons of focusing a language around events?
Posted by: username_0 on 2023-05-18
So I was considering making a better version of [Scratch](https://scratch.mit.edu "Because I don't have many languages to my name."), because I started my programming hobby using it. However, as it stands, Scratch is unsuitable for usual programming, mainly because it's intended for young kids, but event-based programming has stuck with me. Programming with events in Python is always an adventure, and I found myself going back and forth between the web and my program to figure out how to make Tkinter listen for specific events and respond when one was received.

But I wonder what other programmers think about this. **What are the pros and cons of focusing a language around events?**

Specifically, a language with bitwise operators, ability to write text on the screen rather than saying it, detecting for clicks and basically everything Scratch doesn't have but the programmer and Cueball demands to have.
**Tags:** language-design
> **Comments:**
> **username_1**: For the love of programming, *please* make it have proper functions this time  
> **username_0**: Proper, as in what kind?  
> **username_1**: Scratch functions can’t return values  
> **username_0**: Obviously. I was also planning to allow programmers to import modules and do basic stuff like that  
---
## 1 answers
### Answer by username_2 on 2023-05-18. Score: 5 | Accepted answer
[Event-driven programming](https://en.wikipedia.org/wiki/Event-driven_programming) is a popular paradigm, particularly suited for interactive applications and networked applications, which must do things in response to input from the user or a network socket. It's a built-in part of how the DOM works in web programming, and there are many popular libraries which add or extend event-based functionality to mainstream languages. So yes, events are a perfectly good idea to build a programming language around.

However, like all programming paradigms there are indeed some drawbacks to using events for everything. These drawbacks are well summarised in the book *Functional Reactive Programming* by Stephen Blackheath & Anthony Jones, which I'll paraphrase here:

* Multiple listeners to the same event may be invoked in an unpredictable order. There may be logical dependencies between listeners to the same event, which the event listener can't know about.
* A listener might not get an opportunity to subscribe before the first event is triggered.
* If many listeners update some shared mutable state, the program becomes like a messy state machine that is difficult to reason about.
* Listeners on different threads can cause deadlocks, and an event published on a different thread may be received by a listener after it unsubscribed.
* A listener may forget to unsubscribe when its owning object is no longer needed. This keeps its callback function in memory, and the callback function holds a reference to the object, causing a memory leak and performance degradation as the publisher still invokes the stale callbacks.
* A listener which triggers new events may accidentally cause unbounded recursion.

Blackheath & Jones call these the "six plagues of listeners". To these, I would add another one:

* If some data needs to be recomputed when any data it depends on is updated, then it may be wastefully recomputed several times if multiple dependencies change at the same time, each triggering their own "update" events.

[Functional reactive programming](https://en.wikipedia.org/wiki/Functional_reactive_programming) (FRP) is a paradigm related to event-driven programming which addresses these issues, although it comes with its own downsides ─ particularly its conceptual complexity, difficulty of implementation, enforcement of a rigid programming style, and it can make programs more difficult to debug. That said, I have found it a very pleasant paradigm to write in myself, albeit I had to read the aforementioned book cover-to-cover a few times before it clicked. If you're serious about designing an event-driven language, there are likely some ideas in that book which will be useful to you, even if you don't decide to go full FRP with your language.
> **Comments:**
> **username_0** (2023-05-18): By "dependencies" do you mean the triggering events?  
> **username_2** (2023-05-18): @UndoneStudios I mean the other data that something must be computed from, and it's expected that the objects which own that data will trigger events when that data changes.  
> **username_3** (2023-05-18): @UndoneStudios let's say we can define some dynamically computed value: `name = (firstName + lastName)` that will update itself whenever either `firstName` or `lastName` changes. However, if you change both, then it may be recomputed *twice*. This might be potentially wasteful, based on the dependencies and how heavy the computation is.  
> **username_4** (2023-09-29): @VLAZ: In some cases, such costs may be minimized by having distinct events for the scenario of "something you may depend upon has changed" and "someone is interested in your present value".  If notification that a dependency may have changed causes an object to set a flag and notify objects that may dependent upon it, if its flag hasn't been set yet, a chain of dependencies shouldn't cause recursion.  Trying to evaluate something may yield recursion, but that can be detected if one keeps track of what nodes have been visited while evaluating a value.  
> **username_2** (2023-09-29): @supercat Sure, that's essentially lazy evaluation; but it only works in event-driven programming if there aren't further downstream listeners who want to be notified when the value changes. If the value isn't computed until it's requested, then it has to be requested, it cannot be subscribed to.  
> **username_4** (2023-09-30): @kaya3: If a system supports a means of enqueueing deferred events (analogous to `SetImmediate` in Javascript), the "value has changed" can propagate to invalidate everything while entities interested in the value set up an event to fire some time after the invalidation pass is complete.  
---
