[tptacek]

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]

> 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]

How are these not problems that every VM for a high-level programming language also addresses?

[pcmonk]

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.

[tptacek]

Right, I get that. So I guess my question is: in what ways justifying new terminology are the approaches taken by Urbit different? And whether or not they're different enough from prior art to merit obscure new terms, are those differences worthwhile, or are they different for the sake of being different? Because not all of the last 30 odd years of systems and programming research was pointless.

[pcmonk]

> not all of the last 30 odd years of systems and programming research was pointless.

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.

[mrkgnao]

Rust uses Hindley-Milner type inference. OCaml uses Hindley-Milner. Swift apparently uses a variant of the system with more features.

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.

[occultist_throw]

> Persistent connections with exactly-once messaging. Disconnection is just seen as long latency.

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...

[Munksgaard]

I'm curious: What's the advantage of ditching Hindley-Milner?

[vmchale]

>Sane indentation for a functional language, known as "backstep"

This is A) not an impressive problem to solve, and B) not actually a problem in Haskell or Elm.