@@ -1,10 +1,10 @@
11+++
22title = "Precepts: Discussion"
3−date = 2020-03-14
4−description = "Urbit is a principled approach to system design and programming, but it's often not obvious what those technical principles are. This is a list of the technical maxims that define Urbit's approach to engineering."
3+date = 2020-03-18
4+description = "The precepts aren’t arguments. We discuss and justify them here."
55[extra]
66author = "Philip Monk"
7−ship = "~wicdev-wisret"
7+ship = "~wicdev-wisryt"
88image ="https://media.urbit.org/site/posts/essays/discuss-01.jpg"
99+++
1010
@@ -210,22 +210,22 @@ case correctly than to "snap" to the nearest elegant formulation.
210210
211211> A11: Be simple and uncompromising in defining what's correct; go crazy
212212> with optimizations.
213−>
214−> Nock is a great example of this. It contains the character of the
215−> virtual machine, but its asymptotics are bad. Add jets to fix the
216−> asymptotics.
217−>
218−> Another example is the ACID nature of Arvo. Arvo is a pure
219−> function f(logs) of its event log, so formally Arvo is just a
220−> function run against an event log. A naive implementation has
221−> very bad asymptotics; processing each new event is O(n) in the
222−> number of historical events. Choose the function g(state,log)
223−> such that f(logs ++ log) = g(f(logs),log). Then, as long as you
224−> keep the state in memory, processing each new event is constant in
225−> the number of previous events. This still requires O(n) restart
226−> from disk, but you can also periodically (and non-blockingly)
227−> write a checkpoint of the state to disk, so that restart from disk
228−> is only linear in the number of events since the last checkpoint.
213+
214+Nock is a great example of this. It contains the character of the
215+virtual machine, but its asymptotics are bad. Add jets to fix the
216+asymptotics.
217+
218+Another example is the ACID nature of Arvo. Arvo is a pure
219+function f(logs) of its event log, so formally Arvo is just a
220+function run against an event log. A naive implementation has
221+very bad asymptotics; processing each new event is O(n) in the
222+number of historical events. Choose the function g(state,log)
223+such that f(logs ++ log) = g(f(logs),log). Then, as long as you
224+keep the state in memory, processing each new event is constant in
225+the number of previous events. This still requires O(n) restart
226+from disk, but you can also periodically (and non-blockingly)
227+write a checkpoint of the state to disk, so that restart from disk
228+is only linear in the number of events since the last checkpoint.
229229
230230This pretty much says it all. Define what's correct in as simple of
231231terms as possible — this will make it easier to implement and reason
@@ -394,8 +394,7 @@ A perfect static type system can guarantee `T` is a subset of `S` — if it type
394394
395395Dually, a perfect testing suite can guarantee that `S` is a subset of `T` — no correct program fails the tests. This is vacuously true if you have no tests, for then `T = U`. So you want `T` to be as small as possible while still being a superset of `S` — you don't want to reject valid programs if you can help it. But you can't make `T == S` — there will always be some programs that are invalid but pass your typechecks (at least, if your program requires a Turing machine).
396396
397−(It is possible to create a static type system that has `S` subset `T` property described above for a testing suite — see Erlang's Dialyzerand (related
398−work)[http://user.it.uu.se/~tobiasl/publications/contracts.pdf].)
397+(It is possible to create a static type system that has `S` subset `T` property described above for a testing suite — see Erlang's Dialyzerand [related work](http://user.it.uu.se/~tobiasl/publications/contracts.pdf).)
399398
400399A dynamic type system tells you neither of these ahead of time. Instead, you end up with type errors at runtime. Errors at runtime must be handled at runtime, when the programmer is not present. Errors at compile time are handled at compile time, when the programmer is present.
401400
@@ -424,17 +423,17 @@ Better to define rules in a more powerful language. This allows you to follow A6
424423Good code is the result of people approaching the act of engineering with the right attitude.
425424
426425> C1: Code courageously.
427−>
428−> If you avoid changing a section of code for fear of awakening the
429−> demons therein, you are living in fear. If you stay in the
430−> comfortable confines of the small section of the code you wrote or
431−> know well, you will never write legendary code. All code was
432−> written by humans and can be mastered by humans.
433−>
434−> It's natural to feel fear of code; however, you must act as though
435−> you are able to master and change any part of it. To code
436−> courageously is to walk into any abyss, bring light, and make it
437−> right.
426+
427+ If you avoid changing a section of code for fear of awakening the
428+ demons therein, you are living in fear. If you stay in the
429+ comfortable confines of the small section of the code you wrote or
430+ know well, you will never write legendary code. All code was
431+ written by humans and can be mastered by humans.
432+
433+ It's natural to feel fear of code; however, you must act as though
434+ you are able to master and change any part of it. To code
435+ courageously is to walk into any abyss, bring light, and make it
436+ right.
438437
439438The unix/internet stack is a giant ball of mud. It's so big that when you're standing on it, it looks like a bog, and it's not clear that there is a bottom to it. You know there must be, but it doesn't matter because you learned long ago that the best solution is to not dig too deep. Build a strong structure by spreading out your weight and using strong construction materials. If there's something useful deep in the mud, it's probably not worth diving in to pull it out. That's dangerous and prone to failure, and you know many people who have gotten stuck down there.
440439
@@ -445,14 +444,14 @@ Urbit is small enough that, while there's definitely some construction-related d
445444This property is worth fighting for. It's the whole reason Urbit was written. New Urbit programmers are instinctively distrustful of anything below them and code defensively and fearfully. They must learn that it's all drastically simpler and more legible than they're used to. It's still hard, but you can actually make progress. To do so, you have to stand up straight, so you can get a firm footing on the ground. Keep your chin up and your shoulders back, and adopt the posture of a conqueror. When something doesn't work right, don't retreat into your shell of safety and control — fix it. The forces of chaos are always lurking, but their victory isn't inevitable. It's all on the line, so code with abandon.
446445
447446> C2: No time for lazy people.
448−>
449−> If there's clearly a right way to do something and a wrong way, do
450−> it the right way. Coding requires incredible discipline. Always
451−> follow conventions, and fire anyone who won't. Anything that can
452−> be solved by discipline is not a real problem.
453−>
454−> "To him who knows to do good and does not do it, to him it is
455−> sin."
447+
448+If there's clearly a right way to do something and a wrong way, do
449+it the right way. Coding requires incredible discipline. Always
450+follow conventions, and fire anyone who won't. Anything that can
451+be solved by discipline is not a real problem.
452+
453+> "To him who knows to do good and does not do it, to him it is
454+sin."
456455
457456Preserving the property of solid ground requires perpetual discipline. Once lost, it's often impossible to reacquire. Don't compromise your standards.
458457