Their point, I believe, is that someone (just about any younger person in 2026) who has never seen indexed color modes, or colors taking less than one byte per pixel to encode, could reasonably be confused by the notion of "two bits per pixel".
Because all this is mere extrapolation of trends seen in the 90s and before. Sagan was no psychic (or alone in predicting these things), he just knew where to look.
It’s worth clarifying that for the most part, this article just discusses plain effects, ie. "reified side effects" or "resumable exceptions". Algebraic effects are about the composition (ie. algebra) of effects, exactly like algebraic data types are about the composition of types. This part is generally not meaningful in an untyped language like Javascript because effects are all YOLO and you never know what’s going to happen, what effects a function might throw, or whether there’s any handler up-stack to catch your effect.
I've never understood what's meant by "algebraic" in that sense, or what this algebra of combining effect is. Could you say more, or maybe share a link to a useful reference?
Here is an article by Andrej Bauer answering the exact question, "What is algebraic about algebraic effects and handlers?": https://arxiv.org/abs/1807.05923v2
Contrary to the claim from the comment you are replying to, according to Andrej Bauer, "algebraic" does not refer to the composition of different algebraic effects via composing their handlers.
When you see "algebra," think "algebraic structure," i.e., a set of operations and a set of equational laws on those operations.
An algebraic effect consists of a set of effectful operations. In that sense, each algebraic effect (reader, state, etc.) defines its own algebraic structure. In theory, the operations of an effect should also be related to each other by laws. Here is an example for the state effect from Andrej Bauer's paper:
Therefore, the state effect has an algebraic structure.
However, monads that cannot be defined in this equational style cannot be translated to algebraic effects. An example is the continuation monad: https://old.reddit.com/r/haskell/comments/44q2xr/is_it_possi... (I think you are involved in the Reddit comment chain that I'm linking to...)
AFAIK, another example is the "exception" monad, because the way that you interact with it is through the handler itself. I once saw a thread on r/Haskell discussing this, but can't find it.
Ah, thanks, maybe this holds a clue! (Clearly I have been interested in getting to the bottom of this for a while.)
So maybe an "algebraic effect" is one that's isomorphic to a free monad of a functor that itself is an algebraic data type. That seems to give an unambiguous specification for what it means to handle an effect (a natural transformation) and to take a "free product" of effects (sum the functors).
On the other hand I think it would mean that things like Future and general IO wouldn't be algebraic effects.
- An algebraic theory consists of a "signature" (specifying a set of operation symbols with their arities) and a set of equations about those operations. An algebraic theory is purely syntactic, and does not give meaning to the operations or equations.
- An interpretation of an algebraic theory maps each operation symbol to a concrete mathematical object. It maps syntax to semantics.
- A model is an interpretation in which the algebraic theory's equations hold.
- A free model of an algebraic theory, generated by a set, is basically a model that can be mapped to any other model of the theory generated by the set.
So, an example of an algebraic theory is a group (as in the algebraic structure itself, not the various instances of a group). Its signature consists of the binary operation of combining, the unary operation of inverse, and the nullary operation of identity. The models of a group are its instances, such as the integers under additions and subtraction, or permutation functions on a set. The integers are the free group (that is, the free model of the group) generated by the set {1}.
Algebraic theories can also describe the effects of a programming language (e.g. reader, writer, or state). The free model of an algebraic effect is given by the syntax trees describing its effectful computations. Effect handlers are maps from syntax trees, transforming computations into other computations within the programming language.
> On the other hand I think it would mean that things like Future and general IO wouldn't be algebraic effects.
For what it's worth, Example 2.3 in the paper states that IO is an algebraic effect, albeit one with no equations. What might be confusing is that the handler of the IO effect cannot have the level of concreteness to actually implement the IO operations. Effect handlers only map computations to computations within the "pure" programming language. From the paper:
> What we still lack is a mathematical model of computational effects at the level of the external environment in which the program runs. There is always a barrier between the program and its external environment, be it a virtual machine, the operating system, or the underlying hardware. The actual computational effects cross the barrier, and cannot be modeled as handlers. A handler gets access to the continuation, but when a real computational effects happens, the continuation is not available. If it were, then after having launched missiles, the program could change its mind, restart the continuation, and establish world peace.
> Example 2.3 in the paper states that IO is an algebraic effect
Oh, I meant what Haskell calls `IO`, which includes the ability to launch threads, use delimited continuation primops, abort the program, communicate with the FFI, and all sorts of other things that I would guess don't have an algebraic presentation.
I show it when I teach Haskell, and it's what usually makes it "click" for students. Probably because motivating examples are in normal imperative pseudocode.
Your linked article hints at the advantages of using Monads and therefor ADTs (Algebraic Data Types), and does it really well.
The wiki entry on effect systems[0] tells me that a focus of an effect system is something different from a focus of monads. "The term algebraic effect follows from the type system", where an effect system is effectively a type and effect system. It links to Monadic encapsulation of effects[1] and mentions the runST monad when it mentions support in Haskell, as that one seem to "simulate a type and effect system".
One thing this page makes clear is that do-syntax could mean all kinds of things, which seems like a disadvantage for readability. Assuming you know the specialized syntax, elvis operators looking different from async code or a nested for loop seems like an advantage? The performance implications are entirely different.
The problem with monads is their composition. Ie. questions like how is the do notation supposed to work if I want to return:
* an Option<Async> or Async<Option>?
* both an Option and an Async (a product, or tuple type)?
* either an Option or an Async (a sum, or tagged union type)?
Monad transformers can be written for wrapping monads into other monads (as a simple example, an Option is equivalent a List with exactly zero or one elements), but they're something of an ad hoc solution and do not generalize well.
This is fundamentally an issue similar to the "function color" problem, or the fact that exceptions in most languages are a limited, ad hoc effect system and do not compose well. Java gave checked exceptions a bad name largely because of their lack of compositionality, but it's more that the particular implementation is poor.
To be fair, that was in 1994 and nobody had worked out these things yet even in the academia. Algebraic effects are the attempt to do just that.
Right, I understand the history (although I'm not sure I'd say that exception don't compose well) and I understand that "algebraic effects" are an attempt at something better. But I don't understand whether they're something that can be precisely defined or just informal terminology for "a better sort thing for dealing with effects".
You can precisely define any particular model, but not all work in the area shares the same model. I think you know about the capability-passing model, which is quite different to the algebraic effects (e.g. row types) models.
The general ideas are:
* effects are handled by handlers (called capabilities in the capability-passing model)
* function signatures describe the effects that are used
* effectful code is written in direct style, not monadic style
OK, and in the general case a handler allows its body to "perform" an action, and when the action is performed it has the ability to "respond" to it in (in some cases) a very flexible way, running it never, or multiple times, or in a modified environment, or possibly even passing it out of the scope of the handler entirely.
> function signatures describe the effects that are used
Would you say this is not possible in an untyped language then?
> effectful code is written in direct style, not monadic style
> OK, and in the general case a handler allows its body to "perform" an action...
Yes, although not all systems allow this, as implementing full continuations is involved and can hurt performance.
> Would you say this is not possible in an untyped language then?
You can definitely implement the ideas of algebraic effects in an untyped language, but you lose one of the benefits.
> I don't understand the distinction here
Monadic code is code where the order of evaluation is specified by bind / flatMap. Direct-style just uses the language's built-in control flow. See https://noelwelsh.com/posts/direct-style/ for more
> Algebraic effects & handlers use a free monad and an interpreter to separate the syntax of effects from their semantics
I'm pretty sure not everybody who works with algebraic effects would say they have to be based on a free monad, so I'm skeptical how definitive this definition is.
That’s exactly what supply and demand is. They didn’t let you work for them because they had a huge pool of candidates to pick from. It doesn’t matter what the cause of the s/d imbalance is.
The natural incentives had already pointed to subscription based games, these companies attempted it, and consumers mostly rejected it. I'm extremely dubious that this regulation would be enough to reverse that. It's a much easier decision for a company to put a small development team on readying the server tools for public release than brute forcing a new business model on a resistant consumer base and all the associated risks that come along with it.
If by subscription you mean World of Warcraft style continuous subscription then yes, it doesn't work for most games. But I'd argue the modern battle pass model is just another flavor of subscription. And according to the article, free to play games with battle passes and micro transactions also get an exemption from the proposed bill, so companies will just move to that instead.
Are we still talking about negative impacts of this regulation? Because I don't follow the argument that games going free-to-play is bad for the consumer. Consumer pressure has pushed most games with battle passes and microtransactions to limit those to optional expansions of the base game, often merely cosmetic. People can and do spend hundreds of hours playing Fortnite without paying a cent and I don't see how that type of outcome is bad for the consumer.
And if the consumer doesn't invest any money into the experience, I have a hard time justifying a requirement for the publisher to provide options to keep the game running in perpetuity, so I'm fine with that exception.
It’s basically going to incentivize gambling and skinners box type implementations to juice revenue.
Sure, people can opt out and some will. However the base human psychology is pretty well documented. If the ability to simply not engage in what amounts to addictive behavior was enough we wouldn’t have the crazy online gambling epidemic. That is at least to me obviously bad for the consumer even if you can simply choose not to engage.
Some ethical game companies will likely draw the line at what you say - but I predict far more will realize they can juice revenue quite easily by simply moving towards incentivizing more lootbox type things.
You are treating multiple related issues as one singular issue. Battle passes and microtransactions aren't inherently a form a gambling. They can be implemented with gambling, but plenty of games aren't setup that way. If we have a problem with a model that specifically relies on gambling, we can regulate it like other jurisdictions have done[1]. But this specific piece of regulation is addressing something else and doesn't do anything to point the market specifically towards gambling.
Battle passes/mtx would IMO definitely fall under monetary considerations, which would make the excemption not apply. But as is written now, there still needs to be a precedent set for that, to really cement that interpretation
Not exactly the same thing, but a few years ago the law changed to require a sesame-allergen notice on foods that had sesame. Some manufacturers starting adding sesame to foods that didn't need it, because they concluded that including the notice was easier than guaranteeing that their product was sesame-free. The intent of the law was to protect people with sesame allergies, but the result was fewer choices for them.
If a manufacturer is unwilling to guarantee/monitor the lack of sesame in their food, and you having a presumably severe sesame allergy… isn’t it correct not to be eating that food?
Like previously you trusted their lack of sesame based on vibes, which you probably shouldn’t have been doing, and now they’re explicitly telling you not to trust them on this; this seems to me strictly better. You’ve lost a choice that never really existed in the first place
An actually unintended consequence would be if they introduced sesame because they were going to have to put the label on it anyways
If people dislike subscription-based games, companies will adapt by making non-subscription games designed with end-of-service in mind. It only creates an incentive as much as people are willing to pay for the subscription.
The market for subscription games is vastly smaller than the market for offline games. The industry learned that when everyone tried to make a wow killer.
The vibe I got from the article was that now that technical work is faster, bosses expect everything else to be proportionally equally accelerated, even though LLMs either don’t help at all at those workloads or actively make things worse.
All right… So, the cost of technical work has gone down, surely leaving more time for things like coordination, leadership, and thinking on a more operational level, right?
> The cost of building has collapsed, but the cost of aligning organisationally has not. If anything, it's gone up.
…Oh.
> What gave way is the human-focused work. Mentoring is the clearest example. I have less time for 1-2-1s than I did three years ago, and that isn't an accident, it's a choice I've made under pressure.
Ohh.
> The other thing that gave way was thinking time. There's very little of it in my working day now.
> A lot of programmers may not know this, but frontend used to be a highly specialized skill, requiring knowledge of semantic HTML, CSS, the differences of various browsers, accessibility, progressive enhancement, network performance, interface design and user testing
As someone who didn’t really know that being a front-end dev putatively doesn’t involve thinking about those things anymore, I think that list conflates a couple of different things.
Things like the differences between browsers and CSS/HTML quirks, needed to wrangle a document markup language into creating user interfaces, are accidental complexity caused by particular path dependencies, and if they can be abstracted out, that’s a great thing.
Accessibility, interface design, performance, and other things related to user experience, on the other hand? Those are mostly orthogonal. A UI framework can raise (or in some cases lower) the bottom in the sense of facilitating reuse of (hopefully well-designed) components, but no framework is going to make your UI accessible or well designed by itself.
In the fabled past, frontend development didn’t require you to be highly qualified in these matters – web UIs were simply terrible, mostly. High skill level was not required because nobody expected anything from web UIs beyond the barest core functionality.
There was UI programming before the web [citation needed]. In a sense it was "deskilled" because you used a "framework" aka the OS windowing and widget libraries rather than drawing rectangles manually (except in some special cases like games where very custom UI is desired – but those custom controls invariably have roughly 0% of the UX affordances provided by standard ones). Back then, Visual Basic and other RAD tools (anyone still remember that acronym?) were front line of "deskilling", but honestly WYSIWYG visual design is still one of the best ways to create UIs, it’s just rarely done these days for various reasons.
reply