General Design principles from https://urbit.org/blog/precepts/ pic.twitter.com/dei9rkmW4z
You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
6) Represent your data as closely as possible to the essential structure of the problem.
7) A client's representation of data should be as close as possible to that of the server. This blurs the distinction between client and server. It allows offline-mode, reduces communication to syncing, and decentralizes.
8) When mating different paradigms, build one cleanly on top of the other.
Never try to make them work on some of the same primitives. Never abuse one to make the other work. For example, ducts in themselves are very general - if you want to do pubsub, that can easily be built on top of ducts, but don't pretend that pubsub is a part of the duct system.
9) Never misuse an abstraction. An abstraction provides a certain set of tools; use them and only them.
11) Be simple and uncompromising in defining what's correct; go crazy with optimizations.
Nock is a great example of this. It contains the character of the virtual machine, but its asymptotics are bad. Add jets to fix the asymptotics.
Another example is the ACID nature of Arvo. Arvo is a pure function f(logs) of its event log, so formally Arvo is just a function run against an event log. A naive implementation has very bad asymptotics; processing each new event is O(n) in the number of historical events.
13) If you don't completely understand your code and the semantics of all the code it depends on, your code is wrong.
14) Deterministic beats heuristic. Heuristics are evil and should only be used where determinism is infeasible, such as in cache reclamation.
17) Referential transparency is honesty and stability. Lack of referential transparency and other forms of disingenuousness are some of the world's big problems. Only deviate from referential transparency if absolutely necessary.
18) Responsibilities should be clearly separated. This applies from kernel modules through network citizens.
19) Dualities must be faced head-on and analyzed differently at different layers. Statically typed vs. dynamically typed, imperative vs. functional, code vs. data, and effectful vs. pure can all be a matter of perspective, and all relevant perspectives must have coherent answers
20) One hundred lines of simplicity is better than twenty lines of complexity. It's not enough for an abstraction to reduce code duplication; it must actually make the code simpler.
21) Prefer mechanical simplicity to mathematical simplicity. Often mechanical simplicity and mathematical simplicity go together.
22) The Law of Leaky Abstractions is a lie; abstract airtightly. If your abstractions are leaking, it's not due to some law of the universe; you just suck at abstracting. Usually, you didn't specify the abstraction narrowly enough.
23) Some cliches are repeated because they are true; others must be repeated because they are not.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.