4 ms·

> "A value in Hoon is called a noun" - or you could just call it a value. A "value" sounds like an abstract concept. A noun is one of two things: a natural nu

by pcmonk 9y ago

> "A value in Hoon is called a noun" - or you could just call it a value. A "value" sounds like an abstract concept. A noun is one of two things: a natural number or a pair of nouns. Calling it a "value" makes it sound much more abstract than it is. > "A core has no exact equivalent in conventional languages, but the closest equivalent is an object. An object has methods; a core has functionally computed attributes (arms). An arm that produces a gate is the Hoon equivalent of a conventional method;" - or you could just say that objects in Hoon (the language) can have methods and attributes, and you would never need to invent the core/arm/gate terminology. A core is not an object in any meaningful sense. You can create stuff that looks like objects with them, but they're used for a lot more than that. For example, all gates/functions are cores, but there's no sense in which you'd call those "objects". > They try to give themselves an out by saying stuff like "Hoon has concepts like all these abstractions, but they remain false cognates." When you dig into it, the only unique things are the words. It's like children trying to come up with a code- "instead of door we'll say blorp and instead of close we'll say bleep. Now bleep the blorp before we continue inventing our code. The thing about revolutionary concepts is that their underlying principles are different than what you're used to, so if they look similar on the surface, you're lulled into thinking they're basically the same. But anyone who's put significant effort into programming in Urbit will tell you the system is fundamentally different. Not in the sense of "you could never understand what's going on here"; but rather, "we made these few different design decisions in the beginning, and that permeates everything".

jerkstate 9y ago
> A noun is one of two things: a natural number or a pair of nouns To most of us, a "noun" is a person, place, thing, idea, or feeling. I started replying to the other stuff you were saying, but I started getting this feeling like you're in on the joke and I'm not.
- pcmonk 9y ago
  To most of us an "object" is something you can touch. We overload these terms all the time.
tptacek 9y ago
For example, all gates/functions are cores, but there's no sense in which you'd call those "objects". To me, all you're doing here is describing an object-based language in which functions are first-class. Obviously, Urbit didn't invent this concept. Its predecessors used normal names for these terms. Why does Urbit invent new ones? We could productively stay focused on just this one example, and see if there's a better reason for Urbit to call its objects "cores" and its methods or attached functions or computed attributes "arms".
- pcmonk 9y ago
  > To me, all you're doing here is describing an object-based language in which functions are first-class. Obviously, Urbit didn't invent this concept. Its predecessors used normal names for these terms. Why does Urbit invent new ones? That's a pretty (unintentionally) misleading description of it. What is an object? An Urbit function has basically nothing that an OOP object has. No class, no inheritance, no attributes, and no methods. It's just a way of encapsulating a formula (VM assembly expression) in a way that's convenient to call with formulas. It uses the the "core" pattern because it's convenient. "Arm" is a pretty specific term that refers to the way an "element" of a core is represented in the core. When you want to map a particular use of cores to its underlying representation in the "core" pattern, you want to be able to talk about specific data structures. In general, Urbit errs on the sides of giving names to concepts that could only otherwise be described in multiple sentences. Most projects just don't give names to those concepts. Urbit needs better human descriptions of its concepts, but using traditional names for them would be misleading.
  - tptacek 9y ago
    How are these not problems that every VM for a high-level programming language also addresses?
    - pcmonk 9y ago
      They absolutely do, with their own terms. Isn't an S-expression just a list? Isn't a method just a "member function", which is really just a function, which is really just a subroutine? Every language comes up with its own terms, especially for things that are a little different from previous work. Urbit isn't trying to solve many new problems; it's trying to solve old problems in different ways. They just want to be able to talk about the constructs in their solutions.
aboodman 9y ago
> A core is not an object in any meaningful sense. You can create stuff that looks like objects with them, but they're used for a lot more than that. For example, all gates/functions are cores, but there's no sense in which you'd call those "objects". In many, many languages, a function is also an object.

by pcmonk 9y ago

jerkstate 9y ago

> A noun is one of two things: a natural number or a pair of nouns To most of us, a "noun" is a person, place, thing, idea, or feeling. I started replying to the other stuff you were saying, but I started getting this feeling like you're in on the joke and I'm not.

pcmonk 9y ago
To most of us an "object" is something you can touch. We overload these terms all the time.

tptacek 9y ago

For example, all gates/functions are cores, but there's no sense in which you'd call those "objects". To me, all you're doing here is describing an object-based language in which functions are first-class. Obviously, Urbit didn't invent this concept. Its predecessors used normal names for these terms. Why does Urbit invent new ones? We could productively stay focused on just this one example, and see if there's a better reason for Urbit to call its objects "cores" and its methods or attached functions or computed attributes "arms".

pcmonk 9y ago
> To me, all you're doing here is describing an object-based language in which functions are first-class. Obviously, Urbit didn't invent this concept. Its predecessors used normal names for these terms. Why does Urbit invent new ones? That's a pretty (unintentionally) misleading description of it. What is an object? An Urbit function has basically nothing that an OOP object has. No class, no inheritance, no attributes, and no methods. It's just a way of encapsulating a formula (VM assembly expression) in a way that's convenient to call with formulas. It uses the the "core" pattern because it's convenient. "Arm" is a pretty specific term that refers to the way an "element" of a core is represented in the core. When you want to map a particular use of cores to its underlying representation in the "core" pattern, you want to be able to talk about specific data structures. In general, Urbit errs on the sides of giving names to concepts that could only otherwise be described in multiple sentences. Most projects just don't give names to those concepts. Urbit needs better human descriptions of its concepts, but using traditional names for them would be misleading.
- tptacek 9y ago
  How are these not problems that every VM for a high-level programming language also addresses?
  - pcmonk 9y ago
    They absolutely do, with their own terms. Isn't an S-expression just a list? Isn't a method just a "member function", which is really just a function, which is really just a subroutine? Every language comes up with its own terms, especially for things that are a little different from previous work. Urbit isn't trying to solve many new problems; it's trying to solve old problems in different ways. They just want to be able to talk about the constructs in their solutions.

aboodman 9y ago

> A core is not an object in any meaningful sense. You can create stuff that looks like objects with them, but they're used for a lot more than that. For example, all gates/functions are cores, but there's no sense in which you'd call those "objects". In many, many languages, a function is also an object.