Follow

It recently occurred to me, relatively unprompted, that many of the state management patterns in "modern" "react-ish" webdev are just re-implementations of dynamic scope – with the same advantages and disadvantages dynamic scope has had for the past ~60 years that it's been in use.

(Of course, after noticing this, I checked, and pointing out how not-new this pattern is… is itself not at all new: spin.atomicobject.com/2020/04/ We sure do love reinventing wheels!)

I might should slightly walk back ^^^ I do think that many of the practices of "modern" web-dev are ignorant re-inventions of previous solutions (we all need more history!), this one seems to have been an *intentional* re-implementation (much better!):

> In React, this is solved by Context. It is essentially like dynamic scoping for components. It’s like a wormhole that lets you put something on the top, and have every child at the bottom be able to read it

overreacted.io/react-as-a-ui-r

@codesections I've never seen a single instance of dynamic scoping where it actually was a good idea, shells included.

@Steinar

> I've never seen a single instance of dynamic scoping where it actually was a good idea

I've seen several (though they're the distinct minority).

Off the top of my head, they're a key part of how emacs can be so extensible, as Stallman described 30 years ago: gnu.org/software/emacs/emacs-p

Raku APIs also make good use of dynamic scoping when wrapping functions without changing their signature (these dynamic variables aren't exposed to the API's user). e.g.: fosdem.org/2021/schedule/event

@codesections, so I suppose this is one of the reasons why Paul Graham recommended Blub programmers to learn Lisp.

Sign in to participate in the conversation
Fosstodon

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.