The Timeless Toolchain is part of a vision to create more reliable and predictable computers. This also translates directly to computers that are more secure, more knowable, and thus more hackable.
At the most broad, making computers more knowable makes our whole digital society grow faster and do a better job of empowering us all.
Lesson 1: communication is intentional and takes energy -- from both sides.
Lesson 5: sometimes the action is "think about it".
Actionable information is great. However, one of our goals is to think better as a group than any one of us can as an individual. Doing this requires sharing partial thoughts. "Brainstorming", in other words. (This concept is emphatically Not New!)
One thing that can make both these kinds of communication (actionable and brainstormish) better is identifying which one you're attempting to engage in. Never skip this. Both can be constructive, but if your counterparty in communication mis-guesses which one you're performing, they'll allocate the wrong kind of attention themselves for responding to it, and it's very likely to result in suboptimal outcomes (if not outright negative ones, e.g. when one party only has brainspace for actionables and the other party volunteers not those, which can result in impatience and negative evaluation on one side and simultaneou
Preface: there are many (many (MANY)) different ways to do codegen. The effects are far-reaching, so they need to be considered carefully; and the cost to support variations is also sky-high, so please be judicious in suggesting "flags" and options.
This is some exploration of the ways we can do builders and constructors for values in the golang code.
| so where we're at right now is: | |
| IPFS is clearly the right primitives for a bunch of stuff. | |
| (E.g., content-addressing is just... clearly the way to go, for all sorts of stuff. Everybody knows that, at this point. | |
| Contentious a few years ago; but approaching "duh" as we come into 2020.) | |
| When we started making IPFS, "Step One" was get it to ship files... worldwide, peer-to-peer. | |
| We did that. It does that. It's pretty cool. | |
| We also did that without a particularly clear focus on performance, etc. Step One was "make it work!" |
| package main | |
| /* | |
| This is all explicitly designed to be compatible with BurntSushi's sumtype checker: | |
| https://github.com/BurntSushi/go-sumtype | |
| Concretely, that means we 1) generate an interface and 2) use the unexported method | |
| trick to make it 'sealed'. | |
| All enum values get their own (empty) struct type. |
Naming is a fundamentally opinionated operation. The exact mechanism and intensity of opinion may vary by application, but opinionated it certainly is. Opinions require curation. Curation implies either distributed reputation networks (which frankly, I don't think are Possible) or some degree of centralization. QED, it follows that decentralization (as opposed to distributed) is in fact the best we can do.
We can push that a little farther with a tiny bit of separation: it's the assignment of names that's opinionated, and thus requires curation, and thus confined to being decentralized at best. We can still of course make lookup of names completely distributed. And that's pretty good!
Let's talk about some user-stories that come to my mind right now (spoiler, for almost all of them, decentralized&&!distributed is either acceptable or outright desired):
Table of Contents:
Kyss -- "Keep Your Serialization Simple" is a serialization format designed for simplicity, unambiguity, and a pleasant experience for human reading and writing.
Kyss was designed with these criteria in mind: