3 ms·

I don't see the benefits of jamming the square peg of language builtins into such a narrow use case. > the runtime translates WASI args_get and args_sizes_get

I don't see the benefits of jamming the square peg of language builtins into such a narrow use case. > the runtime translates WASI args_get and args_sizes_get > for the zeroth arg to the blockchain address() function. There is nothing intuitive about that for me. In most languages, exposing the blockchain interface as a module feels like it would be a significantly cleaner implementation. If I want to compile against different targets I'd prefer to wrap that module as a library behind my own interface. I can then swap out the implementation at compile time.

_nhynes 7y ago
> > 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.

_nhynes 7y ago

> > 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.