Comment by e12e | Hacker News Reader

Comment by e12e | Hacker News Reader

Parent Full thread

Wait, you want to use concept that occurs in modern math, but to keep things simple, you invent new names for these concepts?

I see nothing wrong with crossing symbolic landscapes that have been trodden before, finding new (or rediscovering old) uses, techniques etc. But I think researching existing taxonomy/nomeclature can be very useful. Eg: ref other comments here: a tree is a graph that doesn't have cycles. If you say something is a tree, then that is pretty clear. Sure you can go on to define what a tree is, for those that have no background in basic graph theory -- but stacking somewhat redundant, special-purpose terms strikes me as being mostly confusing.

(Again, wrt. the symbols vs terms/concise vs verbose I'm not entirely sure I think that whole concept is a wise direction, but I'll happily defer judgement on that a decade or so)

[ed: After reading the actual article, not just the comments :-) -- it's not as bad as the comments indicate, by any means. I think the clarification on trees/cells really helped. That said, I think it would benefit from a couple of complete rewrites. It still feels like a rough draft (which is ok. Sharing is caring, share early for feedback, posting now is better than editing forever in secret etc). For me the strongest points are probably the direct contrasts with lisp, the part about trees etc.

Basically, trust in the ideas: they are not revolutionary, they are small changes on old ideas. That's fine. The sum of the system can still be revolutionary. But I think the "soft sell" would end up in a much stronger message here. And more people would grasp at least some parts of what you're trying to say/do ;-) ]

I want to stick to ordinary American high-school math as I remember it. I learned "domain" and "range" in high school. I don't know anyone who defines these terms as something different. When I hear "projection" I actually don't think of set theory, I think of linear algebra, affine transformations, etc. If it would confuse me, I can hardly confuse others.

The distinction between a tree and a DAG is always a matter of interpretation. From the programmer's perspective, a noun is a tree. From the machine's perspective it's a DAG, because we share pointers and use reference counts. Either perspective can be misleading if you're expecting to think in terms of the other. If I saw the three-sentence definition of a noun, I'd assume it was acyclic, but others as we've seen above would assume it was cyclic. This stuff is hard.

The probable future of this text is that we release all the chapters pretty much as they're written, then edit it and turn it into a book.

First, apologies if my earlier comments came off as negative and harsh (along with others in this thread). I think what you're working on with Urbit looks very exciting!

> I want to stick to ordinary American high-school math as I remember it.

I can see how that would make sense, but it strikes me, personally, as an odd choice. IMNHO there are two levels of "useful" math - primary school and college. Most of what I associate with (senior) high school math ends up in the middle, mudding the waters. FWIW I agree with you on the concrete example of "projection" -- I'm not sure I agree that it's not a good term to use after some more reflection - but it's not something that I would readily reach for.

In the more general sense, it appears to me that what you're covering is basic CS, some stuff related to data types - and some basic graph theory and discrete mathematics. It strikes me as odd to invent parallel terms for things that aren't all that different, rather than just try to explain in terms of well-established nomenclature (introducing that as needed). Nothing wrong with building from basic "traditional" high-school math, but at the same time one shouldn't go to great lengths to avoid basic graph concepts.

> If I saw the three-sentence definition of a noun, I'd assume it was acyclic, but others as we've seen above would assume it was cyclic. This stuff is hard.

I suppose I'm not entirely convinced this noun concept is all that aptly named. Sure, I can see having two different texts, one that invokes ordered pairs, structs and pointers etc - and one that tries to avoid such details -- it just feels that you sometimes go overboard in re-naming things, rather than naming them.

I do agree a balance needs to be found - Haskell texts for example - tends to build from a solid cloud, on which a ladder is erected onto a branch of a tree standing on the back of turtles, and then said ladder is pulled up as the enlightened author concludes the simple tour of simple concepts.

I do think the sidebar on ordered pairs, lists and lisp is very apt. Obviously that'd make absolutely no sense to the average high-schooler?

> The probable future of this text is that we release all the chapters pretty much as they're written, then edit it and turn it into a book.

This sounds like an excellent plan. As mentioned, releasing early is good.

I'm afraid I've come off as more negative than intended again -- I do think that there are new concepts, or mixes of concepts within urbit -- but for now it is kind of hard to see what is "new", what is "tweaked" and what is merely "renamed" (or re-invented, or independently re-discovered).

A directed acyclic graph is a graph without cycles.

An acyclic graph is a graph without cycles, yes.

Reply on news.ycombinator.com