Why would you write a whole programming language interpreter just to validate transactions.
No, I already know the other answer, because of extensibility, but this is silly. It’s not that hard to make new source code and then compile it, what’s this solving a problem that doesn’t exist???
It also introduces unnecessary extra data in transactions, and we don’t really want to be extending the needs of our databases before we even start.
We already are familiar with the types of transactions. These silly transaction languages assume a static software base. This is not entirely invalid as regards to blockchain’s tendency as all distributed permissionless things, to change the protocol slowly, but this doesn’t also have to apply to the code that makes this protocol.
So, why not just have a simple transaction type register and 4 bytes and you can have all the different kinds of transactions you want, with only their parameters and none of the parts that give semantics that are not implicit anyway.
Causality can be proven beyond equivocation between a group of nodes engaging in a race to be proven the first to do some particular thing. It isn’t possible to guess what things you haven’t heard of, even if your neighbour just heard it, so when the neighbour reports some other event then he knows something you don’t.
Given enough such reports of most recently seen events circulating around the gossip network, one can establish positively the relative sequence of events that have a causal constraint (like a payment, you have to first receive one before you can make one, with the exception of a keybase, which you mine).
The transaction centric nature of DJCP is a good match with hard coded identifiable transaction types with simple parsing (just parameters!). Validating transactions is expensive in the replay process and will present a bottleneck in the maximum transaction throughput capacity of the network.