can we have our "app db" cake & eat it too?

0 views
Skip to first unread message

Raoul Duke

unread,
Aug 9, 2025, 3:12:14 AMAug 9
to pi...@googlegroups.com

David Barbour

unread,
Aug 11, 2025, 11:11:24 AMAug 11
to pi...@googlegroups.com
That article is arguably about fighting Javascript for performance of a global store.

If a language is designed to favor a global store for app state, it is feasible to compute paths at compile-time, and even link paths to the final layout of state.

It would be useful to model state as a set of second-class implicit parameters, subject to structured translations for hierarchical components, instead of first-class values.

We might express fine-grained state notifications in terms of coroutines that yield via 'await Condition', or alternatively via incremental computation of repetitive transactions. In any case, a compiler could play a role here, too.

Anyhow, performance problems cannot be blamed solely on a software architecture, especially not when implementation involves working around the language instead of with it.

On Sat, Aug 9, 2025, 2:12 AM Raoul Duke <rao...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "PiLuD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pilud/CAJ7XQb7LNsdcBHAjyLHsXjrYsHTSi1hsz4JLGJamC2FVoT0eLg%40mail.gmail.com.

Raoul Duke

unread,
Aug 11, 2025, 11:31:35 AMAug 11
to pi...@googlegroups.com
Thank you for the thoughts. Even though the JS ecosystem apparently supports lots (too much, probably) advanced experimentation and has produced neat ideas & implementations, I do wonder how much of programming history has been deoptimized just because we are saddled with the mainstream language(s) of the time. 
Reply all
Reply to author
Forward
0 new messages