Ethereum is/was pretty interesting; but as with all blockchains, it's solving a globally-distributed byzantine/trustless problem, at the expense of being massively inefficient.
It's a good idea for that domain, but such constraints don't apply to the majority of computing problems. For example, Web app A might want its events to appear in the same order to all of its clients, and Web app B might want the same for its events, but there's no reason to enforce that all clients of all apps see all events of all apps in the same interleaved order, in an open world where new apps can be created without any central authority, and where no app or client trusts any other app or client.
Regarding a practical language, I think something like Morte/Annah/Dhall would be nice as a way to:
- Use pure functional computation as a powerful 'sandbox' against causing nasty effects or having results affected by outside interference
- Use IPFS URLs as function names
- Use Church (et al) encoding and strong normalisation as a form of statically-checkable duck-typing (i.e. if it encodes to a duck, then it's a duck)
Ethereum is/was pretty interesting; but as with all blockchains, it's solving a globally-distributed byzantine/trustless problem, at the expense of being massively inefficient.
It's a good idea for that domain, but such constraints don't apply to the majority of computing problems. For example, Web app A might want its events to appear in the same order to all of its clients, and Web app B might want the same for its events, but there's no reason to enforce that all clients of all apps see all events of all apps in the same interleaved order, in an open world where new apps can be created without any central authority, and where no app or client trusts any other app or client.
Regarding a practical language, I think something like Morte/Annah/Dhall would be nice as a way to:
- Use pure functional computation as a powerful 'sandbox' against causing nasty effects or having results affected by outside interference
- Use IPFS URLs as function names
- Use Church (et al) encoding and strong normalisation as a form of statically-checkable duck-typing (i.e. if it encodes to a duck, then it's a duck)