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".
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.
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.
Indeed, which is why it's a shame our primary server OSes (Unix-likes) can't incorporate them. Urbit can.
As for what are the approaches different, there have been many words spilled over that, but here's a few examples to wit, most of which exist in one or two other systems, but aren't widely used:
- All events are transactions, down to the VM level. There's no concept of an event that left garbage around because power was cut or the machine was rebooted. You can always crash an event, making it as if it never happened.
- Single-level store. Never worry about ORM because your in-memory state never goes away (because all events are transactions).
- Persistent connections with exactly-once messaging. Disconnection is just seen as long latency.
- Strict, purely functional language with a strong type system but no Hindley-Milner (so you don't need category theory).
- Sane indentation for a functional language, known as "backstep".
- The file system is a typed revision control system, which allows intelligent diffs on types other than plain text.
Most, if not all, of these, have been described in research, but nobody's bothered to build a system with them.
None of these make use of monads or anything rooted in category theory.
https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...
HM is a type system that also gives you an algorithm to infer types without having to do the "List<Integer> foo = new ArrayList<Integer>()" dance from languages without type inference. That's it. It has nothing to do with category theory.
It would appear that my knowledge is out of date: did Rust use something closer to H-M in the past? (Going off of https://github.com/rust-lang/rust/pull/15955 here.)
Rust has done almost everything in the past; I wouldn't be surprised if somewhere back in there it was actually HM. :)
Bullshit.
https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf
Unless you and Yarvin really think there's a valid answer to the 2 Generals problem... Im sure there's a Fields medal in there if you do.
"Every major message queue in existence which provides any guarantees will market itself as at-least-once delivery. If it claims exactly-once, it’s because they are lying to your face in hopes that you will buy it or they themselves do not understand distributed systems. Either way, it’s not a good indicator."
~ http://bravenewgeek.com/you-cannot-have-exactly-once-deliver...
> FLP and the Two Generals Problem are not design complexities, they are impossibility results.
Two generals, in its impossible form, isn't applicable here. For example, this proof[0] depends on the deterministic form being impossible to solve in a finite number of messages. But why would we care about doing it in a finite number of messages? By that measure, at-least-once delivery is impossible too, yet neither you nor the blogger seem to have a problem with that. The solution is easy and common: send a message, ack new messages, retry if you don't receive an ack, never ack an ack, and always ack a dupe. As long as you aren't disconnected forever, this will give you at least once delivery.
FLP only applies in the case of faulty processes. Specifically, FLP arises because the faulty process must either (1) ack the message before handling it, or (2) handle it before acking it. (1) fails if it crashes after acking before handling, causing it to forget it ever received the message (at-most-once). (2) fails if it handles the message, but doesn't persist that fact to disk, so that when the dupe is received it doesn't know it already handled it (at-least-once).
Urbit processes events transactionally (like a database), so you're guaranteed that if you received an ack it's because the other person has persisted that message or its results, and it won't forget about (i.e. they've persisted any state changes related to it). No faulty process, no problem. FLP impossibily doesn't apply.
I suggest actually learning about proposed solutions to problems rather than recalling that someone convinced you they were impossible to solve. Proofs are powerful because they're incontrovertibly true, but they only apply if their conditions are met.
[0] https://en.wikipedia.org/wiki/Two_Generals%27_Problem#Proof
But that doesn't mean we can't provide systems where, for all practical purposes, it is a guarantee.
Another way to think about it: SHA1 cannot provide a unique hash for every possible set of content - there are overlaps. This is the pigeonhole principle.
Yet, we have entire systems designed around assuming SHA1 is and will always be a unique hash for a piece of content (Git), and, for all practical purposes, it is a guarantee good enough to work despite that.
I don't understand why you address me with such a hostile tone. What have I done to deserve this? You accuse me of playing word games, but this is not my intent. I am just trying to have a conversation about the technical aspects of a system.
I can even get behind runes, and I set up abbreviations in Emacs to learn their names. And generally, I like the philosophy of language where short, one syllable, old/middle English words are used in place of the less familiar Latin/Greek derived words. I don't have a problem with revising our existing vocabulary in this way.
But the attitude to type theory strikes me as anti intellectual, precisely because we get nonsense claims about Hindley Milner requiring category theory. This sort of misinformation does no good for anyone.
This is A) not an impressive problem to solve, and B) not actually a problem in Haskell or Elm.
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.
In many, many languages, a function is also an object.
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".