4 ms·

> > zeroth arg > There is nothing intuitive about that for me. It looks a lot like how a command-line program has the program name as the zeroth argument. The

> > zeroth arg > There is nothing intuitive about that for me. It looks a lot like how a command-line program has the program name as the zeroth argument. The address just happens to be the name of the program in a blockchain context. > exposing the blockchain interface as a module feels like it would be a significantly cleaner implementation I'm not so sure. I think that the goal here is to allow developers to program "DApps" using their normal toolchain and abstract over the semantics of the blockchain platform. IMHO even the ideas of "block" and "chain" are implementation details in the same way as the journal of a traditional database is an implementation detail. Exposing these details as a library means that the program is tied to not only the blockchain, but a particular blockchain runtime. > wrap that module as a library behind my own interface That's always a good idea, but not incompatible with having a lower-level interface (in this case WASI and Rust/C++/AsmScript `std`).

reggieband 7y ago
> IMHO even the ideas of "block" and "chain" are implementation details in the same way as the journal of a traditional database is an implementation detail. The internals of a database are one thing, but the semantics of the language builtins seem like another. It almost feels akin to someone suggesting we change the underlying implementation of "println" (or whatever language builtin outputs to stdout) to automatically write to a new row in a database. I mean, I could adjust to such a weird idea but my initial impression would be we are forcing an existing abstraction onto a problem rather than choosing a truly suitable abstraction. > Exposing these details as a library means that the program is tied to not only the blockchain, but a particular blockchain runtime. Not necessarily, I'm considering something more like Go's cloud API: https://github.com/google/go-cloud https://github.com/google/go-cloud You could easily have a "blockchain" API with any number of runtime backends. I understand what the proposer was suggesting: a single semantic meaning for "print" across all programming languages that will map onto blockchain. I just don't agree that it is a good idea.

reggieband 7y ago

> IMHO even the ideas of "block" and "chain" are implementation details in the same way as the journal of a traditional database is an implementation detail. The internals of a database are one thing, but the semantics of the language builtins seem like another. It almost feels akin to someone suggesting we change the underlying implementation of "println" (or whatever language builtin outputs to stdout) to automatically write to a new row in a database. I mean, I could adjust to such a weird idea but my initial impression would be we are forcing an existing abstraction onto a problem rather than choosing a truly suitable abstraction. > Exposing these details as a library means that the program is tied to not only the blockchain, but a particular blockchain runtime. Not necessarily, I'm considering something more like Go's cloud API: https://github.com/google/go-cloud https://github.com/google/go-cloud You could easily have a "blockchain" API with any number of runtime backends. I understand what the proposer was suggesting: a single semantic meaning for "print" across all programming languages that will map onto blockchain. I just don't agree that it is a good idea.