8
$\begingroup$

So I was considering making a better version of Scratch, 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.

$\endgroup$
4
  • $\begingroup$ For the love of programming, please make it have proper functions this time $\endgroup$ Commented May 18, 2023 at 13:32
  • $\begingroup$ Proper, as in what kind? $\endgroup$ Commented May 18, 2023 at 13:32
  • $\begingroup$ Scratch functions can’t return values $\endgroup$ Commented May 18, 2023 at 13:33
  • $\begingroup$ Obviously. I was also planning to allow programmers to import modules and do basic stuff like that $\endgroup$ Commented May 18, 2023 at 13:34

1 Answer 1

Reset to default
5
$\begingroup$

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 (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.

$\endgroup$
6
  • $\begingroup$ By "dependencies" do you mean the triggering events? $\endgroup$ Commented May 18, 2023 at 13:44
  • $\begingroup$ @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. $\endgroup$ Commented May 18, 2023 at 13:45
  • 5
    $\begingroup$ @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. $\endgroup$ Commented May 18, 2023 at 13:48
  • $\begingroup$ @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. $\endgroup$ Commented Sep 29, 2023 at 22:43
  • 1
    $\begingroup$ @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. $\endgroup$ Commented Sep 29, 2023 at 23:01

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.