Thanks, Kacper! Yeah, if you look at urbit.org today, there's a new
version. We ditched "pserver" and fixed a bunch of stuff.
Yes, the names are still scheduled to be replaced but have yet to be.
needs to be split up, both for reading and just for managing it. On the
other hand, it is nice to have in one place...
Post by Kacper CieÅlaBeing gifted with spectacularly bad memory I decided to provide some
feedback to the whitepaper from a complete noob perspective.
Overall it's a nice comprehensive guide that I missed when I've heard
about Urbit the first time. I'll focus on what's wrong and not the things I
like (eg those little metaphors here and there), assuming that this will be
more helpful.
In general, I'm not sure I would made it through it, if not for the fact
that I was already familiar with the thing. I think at some point I could
be overwhelmed with amount of new information and associations that reader
has to make while reading it for the first time.
I think it would be nice to provide some general view of the whole system
(relations between nock, hoon, arvo vanes and more or less how it works),
before talking about cubes and forks. I know it's all connected and the
paper starts from the lowest level and nicely goes up, but it's hard to
get somebody interested in a great swiss watch starting with lecture about
shapes of the gears inside.
IMHO all names that are not used later in the paper could be dropped, new
reader has enough of them to get familiar with.
Quotes below are just search phrases to locate comments, not a context.
There are some comments referring to I0, I1, I2... I vaguely remember
these as hoon source code sections, but I don't think it's stated anywhere
in the paper e.g. "we end up in a main sequence of uniform events (starting
at I5 )"
"no input not input to the pserver itself," - some typo?
"Of course every computer is deterministic at the CPU level" - I'm not
even sure that still holds true nowadays ;)
There was something about OS and dummy me wondered for a good while what
the "OP systems" are. Maybe it will help other dummies if there's some
'(OP)' next to the previous 'orthogonal persistence'.
'we can implement the JS or JVM specifications in Hoon' - that's the first
time Hoon is mentioned, having spend time on JS & JVM maybe it deserves a
few sentences of explicit introduction.
"I is a list of nouns - where a list is either 0 or a cell [item list]" -
so just a noun then?
The concept of [a b c] (even ignoring ~ that got there somewhere in the
paper) as list and being expressed as [a [b c]] was not explicitly stated
outside Nock spec I think. Maybe there could be a bit more talking how it
all runs on nock and about the ball of mud. It's all there in the paper,
but somewhere between the lines. I think it was much more explicit in the
original blog post and I liked it that way. Also I remember an info that
urbit can't call outside world but outside world can call urbit that got me
thinking in the original blog post. It's very easy to infer it from the
paper but reader has enough in his head happening already.
I was wondering if (V I) could be presented in a notation where there
wouldn't be need to reverse order later to [subject formula]
"the Arvo source. The main event sequence begins" - there was no word
about Arvo before this, reader has no idea what Arvo is yet.
"'atom' with text odor" - and no idea what odor is here
"(The syntax %string means a cord" - this %string jumps in here out of
nowhere, it's not within listed types, so it may raise confusion.
Examples of Hoon around here would get me confused. We're jumping right
into guts, perhaps it would be easier on the reader to provide a examples
how different types are getting translated into numbers like it was in some
previous doc, or some ++dec, or something else which shows more how Nock,
Hoon works rather than how it is implemented.
I don't think that telling user that %ta is ASCII and %da is date helps
reader at this point. Maybe it could with some enumerated list of chosen
types and examples of usage. But here it's just yet another confusing
string. At this point in paper she doesn't know yet anything about our
specific naming.
"'Each arm uses the whole core as its subject" - no idea for reader what
an arm is here
"nor a map of names to formulas a vtable" - not sure, but vtable was
supposed to be in parenthesis?
Hoon twigs "autocons." - typo, dot inside quote
"For twigs with a constant number of components" - maybe example with 3
elements would be better, very unsure with my memory
"I4 : Arvo" - starting with sentence what Arvo is could be nice
"++load is fragment 54 of the core battery, producing a gate whose formal
argument at fragment 6" - I'm don't know what these numbers are.
"the request with an action %this" - example of a name that I don't think
is necessary to mention in the paper, at least not while still trying to
describe how things work and not annotating source code
"a duct" - as in other places first occurrence so in italic I think?
I'd love to see more general talking how vanes communicate and how things
go together and less code annotations.
Before I remembered about clay, I thought %c was just a typo after %x and
%y (that is, that these were some examples, because [%foo %bar ~], and that
it should be %z). It could be just me. Definitely some feedback from a
person who actually hears about urbit for the first time will be very
valuable.
"contains the base and desk" - desk italic?
"head of the spur" - spur undefined
"While the Hoon type system works very well, it does not fill the niche
that MIME types fill on the Internets" - but it's still a type, right? It
seems to sound a bit like we use something else instead here.
"There are two ford request modes, %c and %r - cooked and raw."... -
another example of where I think names are not necessary. Even if you want
a whitepaper to be something where he gets back after reading it once and
it helps him understand how Hoon works, it would probably be better to
clearly separate sections describing how it works from those explaining
what is what under the hood.
"When a message fails to validate, the packet is dropped silently", whole
paragraph, there is some pretty much the same explanation earlier in the
paper (boith upgrades and backoff)
"all it sees are messages and subscriptions, just like it would receive
from another Urbit app." - few words about security model would be nice,
there's mention of %gall stopping apps from doing really weird stuff, but
what about how app distinguishes msgs that are local or not if it really
wants to (you may remember me playing with it some time ago)
"Every system needs its" - it?
"secret, it must register to receive an expiration notice." - random
thought, if it just drops packets, A and B are talking, then B subscription
breaks for some reason and B didn't get a chance to receive expiration
notice, but it's ignoring all packets now, how does this get fixed?
I assume that Hoon at this point is something less likely to change than
the communication protocol, but some more stuff about packets flying around
could be nice.
"Google Wave" - sigh, RIP
I like being upgraded from a destroyer to a whole planet. PCC sounds good,
pserver is OK for me too, although my brain won't accept that the P is
silent. Maybe PS.
So there's a lot of good stuff, but I'm not sure if it's organized in the
optimal way. Maybe to keep short attention spans like me reading it would
be better to move phonemic stuff and ships hierarchy before minting stuff.
It surely does great job at describing use case which was not clear in docs
earlier. But hmm.. some very subtle subjective feeling... like JS and JVM
are not really good for this, and IOS is problematic too, so we need
programming language, and OS, and blah.. It's kinda feels like wow, we're
fucked. In the original blog post my mind was more like - you know like
when you're coding and looking for bug, and diving through all these
abstraction layers to finally find it and whole compatibilieties and not
really knowing what inside.. we do BOOM and start from scratch. Nock. In
your face.
Anyway, I gave you pretty much everything that appeared in my head so I'm
sorry if it's pretty raw or chaotic. Really cool to see urbit getting a
solid whitepaper. If you are thinking about some more general introduction
I think all info should be in whitepaper too. Keep up the good work.
cheers,
todsef-nathes
(names stayed, right? I thought they were about to be regenerated or
something)
On Thursday, September 17, 2015 at 10:28:57 PM UTC+2, Galen Wolfe-Pauly
Post by Galen Wolfe-PaulyPsst.
http://happut-fopnys.urbit.org/home/tree/pub/release-0
<http://www.google.com/url?q=http%3A%2F%2Fhapput-fopnys.urbit.org%2Fhome%2Ftree%2Fpub%2Frelease-0&sa=D&sntz=1&usg=AFQjCNGyjlsDvmMibiCa3SMJgb1s3N6hXA>
Weâd love to hear feedback from the list before posting anywhere else.
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.