
The Universal Design - xena
https://christine.website/blog/the-universal-design-2015-10-17
======
yarvin9
Xena is right to note that this simple state-transformation function, f(event
old-state) -> [actions new-state], is the obvious and eternal way to build a
server. It's also worth noting that it's basically Haskell's State monad.

Whatever you call it, it's a design pattern, not a system service. Urbit on
the outside, as an "operating function," is defined by the "universal design."
But since it's a pattern rather than a service, it will tend to reappear at
each layer of a layered system. Urbit on the outside uses this pattern and so
do Urbit applications, but these are very different layers of Urbit.

At the application layer, a command to an IRC daemon is a great example. There
still seems to be a good deal of boilerplate in the Lua code presented here.
The attraction of the "universal design" is the goal of eliminating all, or
almost all, boilerplate code in a network server daemon.

How would one go about that? First, be a single-level store, so the daemon is
automatically a database. Second, make application messages are transactions
with end-to-end acknowledgment, no return value, and exactly-once delivery.
The message is automatically deserialized and validated, and passed to the
application as a simple typed argument. If there's a problem with the
operation, just crash; the result is delivered as a transaction failure with
an annotated stack trace. Also, messages should be sent over an encrypted P2P
network and authenticated by scarce, memorable identities...

On the other hand, I'm sure the Lua daemon is a lot faster!

~~~
jwatte
(Event, State) -> (Actions, NewState) is indeed how Erlang/OTP applications
and components have been structured for the last 20 years! Concrete existence
proof.

------
aji
>This design will also scale to running across multiple servers, and in
general to any kind of computer, business or industry problem.

If I understand what you're getting at, you're saying that locking is the
solution to all concurrency problems? This section is the most interesting to
me, as I've been researching concurrency at a high level lately. I'm a little
confused by your conclusion. It seems naïve to claim that multiple hosts can
agree on what action to take "just" by using locks. What if a peer is holding
a lock and becomes unreachable? What if the peer isn't dead and thinks it
still has the lock? What if the core that is issuing the locks becomes
unreachable?

~~~
AkariTakai
I didn't see anything really interesting in there about concurrency or
consensus beyond the naive. What she does talk about is almost a microservices
pattern though, and that can be an awesome tool for solving certain kinds of
problems. I don't think I agree that it's more useful than other tools across
all problems though.

------
unoti
Beware a typo in this code: search for "mepliles". Unsurprisingly, the error
is in an error handler, so it was assuredly never hit. This kind of thing has
started making me yearn for type safety and static compilation.

