I'm always astounded by the depth to which Mark has explored this space. On more than a few occasions, I've come up with an interesting idea for a new protocol or programming language feature or piece of distributed systems infrastructure and told Mark about it, only to find he had already thought of that problem and discovered and solved several issues I hadn't even thought about yet.
Cap'n Proto RPC (https://capnproto.org/rpc.html) is based on E's network protocol, CapTP, e.g. utilizing The Four Tables:
(You can think of this design as an extension of the file descriptor table concept in Unix, except that both sides may export descriptors to the other side (so that calls can flow either way), and either side can be responsible for assigning the numeric descriptor value for any particular description (which makes it easier to compensate for a high-latency transport).)
When I first told Mark I was working on an object-oriented RPC protocol, he insisted I visit him and listen while he explained all this to me, and boy am I glad he did... would have taken a lot longer for me to figure it out myself.
It's crazy that most of the content of erights.org was written over 10 years ago -- I think some of it goes back to the 90's, even.
Back in the mid 2000s at IMVU, I went deep on reading about E, EROS, Polyphonic C#, and Comega, which lined directly up with the problems we were having with asynchronous programming on the client.
Thus, I can point directly to E and friends as leading us to make such a successful, _correct_, asynchronous task engine.
It's funny to think about now. Promises and coroutines and promise pipelining and async are now well-explored, but at the time there wasn't much prior art to draw from, and everyone was figuring it out as they went. Do you synchronously block on futures? Should .then calls run on the calling thread if data was already available? How does cancellation work?
Once you have answers to those questions, you reach the higher-level ones: how do you structure your program so that asynchronous components can communicate? How do you unit test these interactions? What abstractions avoid needing to unit test every possible sequence of events?
We did a pretty good job and I feel blessed that we stumbled upon the E papers, leading us to create abstractions that stood the test of time.
> Should .then calls run on the calling thread if data was already available?
This one hits close to home -- I remember being involved in a PR discussion for a JavaScript promises library where this was hotly (iirc?) debated. What conclusion did you reach? (I was on the side of consistency -- .then should not run synchronously even if it could.)
That's one where we got lucky. We made the wrong decision, but it didn't matter because the distinction was invisible when using the higher-level abstractions (like coroutines) and combinators.
My opinion now is that JavaScript does it right: `.then` should _always_ defer the callback. BUT, it does come at a real performance cost. And for code that is performance-sensitive and can handle the callback running immediately, the API should support a `.thenImmediate` or something that will run immediately if possible.
Yes, JS got it right. It is very often the case that you need to consider different edge cases for synchronous vs. asynchronous execution, and it's very hard to cover both cases in tests, leading to code that randomly breaks in production based on timing differences, which is pretty much the worst.
There's an active remake of E with a different syntax and new implementation: https://monte.readthedocs.io/en/latest/ (I guess it'll have other language changes too -- that was just what I took away from my read over the docs.)
"A smart contract is written in program code, in which the logic of the program's execution enforce the terms of the contract. Smart contracts reduce costs by orders of magnitude, leading to a more cooperative world."
A. Most written and oral contracts aren't terrible expensive, especially when there is no disagreement between parties. I want to rent a property, I sign a lease and obey its terms. There's no extra cost unless there's some disagreement.
B. The situation where there is disagreement between parties is where things can get sticky. But with "smart contracts" being just automatically executing contracts, I can't see any way they really solve the problem. A smart contract can't by itself verify that goods are delivered, that the landlord has maintained a habitable space or that I am not destroying the property - except with third parties, who may be reliable but aren't automatically reliable and are something an ordinary contract can employ.
C. The legal system now actually takes into account the degree of sophistication of the parties involved in a contract. Contracts that tend to effect legally naive, average people generally don't allow unconsciable terms[1]. On the other hand, in most sophisticated markets nearly everything can be up for grabs. Which is to say the legal system provides a significant umbrella of protection for most people. Contracts that automatically execute would rip that away - except they wouldn't, because the legal system isn't going away any time soon. A person's ability to create and enforce a "smart contract", an automatically executing financial effect, is limited to what is ... legal. However automatic your effect is, you will find lawyers involved if your effect also isn't legal.
Smart contracts are orders of magnitude HARDER to write, due to the fact that you have to get them exactly right in every respect, since no interpretation of the intent of the contract can happen, it will just execute as literally written.
And we know very well that writing bug-free code, on the first try, is a ridiculous pipe dream.
Ethereum and its countless hacks and failed contracts has been a very real demonstration of the problem, especially for those who lost large sums of money due to a small mistake in a smart contract.
Modern smart contract systems should learn a lesson or five from it, most importantly, (object) capability security.
Why? Because it lets programs handle permissions like other objects, keeping them apart and thus reducing the attack surface and preventing Confused Deputy [0] attacks.
Not being too familiar with Smart Contracts, it was nice to see the simple summary included.
>A contract is a mutually agreeable arrangement of rules among mutually suspicious parties so they may cooperate with limited risks to each other's mischief. It is a game both are willing to play because both expect to win.
>
>A conventional contract is passive paper interpreted at great expense by lawyers and courts.
>
>A smart contract is written in program code, in which the logic of the program's execution enforce the terms of the contract. Smart contracts reduce costs by orders of magnitude, leading to a more cooperative world.
Can anyone recommend a good link to start learning more about smart contacts and how they are used in specific real-world examples? Most of what I'm finding reads as very general/theoretical.
If you are not a programmer, you will require a “great expense” of a programmer to write it for you (with no way for you to verify it).
After you have your “smart contract” you have no way to enforce it if the other party doesn’t abide by it.
The “great expense” of lawyers and courts provide a host of features smart contracts can never even imagine providing:
- identity validation (that the signatories are who they say they are)
- actual validation of terms (that they are not mutually exclusive, that they are reasonable, that they benefit the parties etc.)
- enforcement of the contract
There are many other things: like verifying that a party can actually pay for goods/services, that co-signatories are notified and/or agree to the contract, that goods/services are as described in the contract etc. etc. etc.
The point would be that smart contract make sense if and only if they can be meaningfully deployed inside a single platform. I agree that they make little sense for physical systems.
But something along the lines "I will pay you X bags if you send me a signed pdf with a specific hash" makes total sense.
They strongly should not be used for anything that would need a lawyer. That would just be a ticking bomb.
> But something along the lines "I will pay you X bags if you send me a signed pdf with a specific hash" makes total sense.
How would it make any sense? Who is there to enforce that I will actually send you _X_ bags? That I will send you X _bags_? Who is there to verify that contract for a non-programmer?
There are literally no use cases for smart contracts because they will always need either a complete trust between the parties or a third-party arbiter for all the things that lawyers and notaries and banks already exist.
Their domain name is listed for sale for $1,000,000 according to the link at the bottom of the page. Does that mean this project is dead or are they just amenable to changing the project's domain?
I would imagine at that price point that any domain is at least negotiable, so why list it?
Speaking of buying and selling domain names I heard something interesting on a podcast a few days ago about buying a parked domain from someone else.
What they said was, if you are starting a business and the domain name that you want is already taken, you could approach the domain owner with the following suggestion:
You will rent the domain from them for a period of time, say two years, with a contract that gives you the option to buy the domain from them after that time has passed, at some price you both agree upon now.
This agreement could be beneficial to both parties.
- You avoid shelling out a lot of money for a domain name now for a business you don’t know whether will work out or not. The money you don’t spend on that domain name now you can use on engineering, marketing etc.
- They get money from renting the domain name to you, instead of just having it parked and earning them some meager amount of money from the ads they might have on the parked domain. On top of that, if your business works out then they get a good deal of money selling the domain to you in the future.
Of course you will have to be certain that the people you make this agreement with are trustworthy and that they will uphold their end of the contract.
Off topic here, but on a different comment there was a discussion about smart contracts. While they are often over hyped this would be a practical example where they would make sense.
I suspect Mark found it to be an interesting thought experiment to decide at what price he'd actually be willing to sell the domain (that hosts much of his life work!), and then he listed it just in case someone would actually pay that.
I don't suspect anyone has ever actually been interested in buying the domain, to be perfectly honest.
I found it really enlightening, and it isn't an exaggeration to say that learning about ocaps kind of changed the entire way I look at building or using software.
To my knowledge, E (and similar languages like Monte and Pony), are basically the embodiment of what Object-Oriented Programming was supposed to be.
You may have heard about how the actor model is really OOP in its purest form, because it's really all about passing messages between isolated objects or processes. The creator of Erlang (Joe Armstrong) even said something about how Erlang was at its heart really object-oriented[1].
This is what languages like E, Monte, and Pony are trying to encapsulate and design the entire language around. This idea of isolating everything, and controlling access purely by controlling how references to other pieces of data are shared amongst said isolated processes.
Why is this so important?
Because we're building programs more and more to be distributed. Users expect that they will be able to easily and securely share things with each other, and be able to collaborate in a distributed way. This is exactly what tools like google drive, slack, twitter, and so on are all trying to do, and most of them do it badly in my humble opinion. Nobody wants to spend hours managing permissions and access roles on a whole suite of services.
The model that languages like E are built on solves that problem and makes it trivial to manage access and permissions at a ridiculously fine-grained level.
> Then, my thesis supervisor said "But you're wrong, Erlang is extremely object oriented". He said object oriented languages aren't object oriented. I might think, though I'm not quite sure if I believe this or not, but Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism.
I also blame E for teaching me to appreciate objects. (Or rather, from hanging out in the cluster of related mailing lists back when it was in development.) I'd long held the opinion that OO programming had its uses but was kind of ugly and arbitrary and overhyped, especially compared to functional programming -- on opinion that's more popular nowadays. There's still a need for a really good accessible book on these ideas; Mark Miller's PhD thesis is not going to be it, worthwhile as it is.
Could someone explain the difference between a programming language and a framework? I’m confused how a programming language can be implemented in java or lisp. Doesn’t that just make it a java/lisp framework?
A framework is usually just a library for language L. Often it's extensive and serves a single broadly-defined purpose.
A programming language implementation for a language P, written in language L, usually denotes a function in L which maps strings representing programs in P to effects (interpreters) or to programs in yet another language (compilers).
E was never meant to be tied to Java (after the very early period in both languages when the E people tried to get Sun interested in incorporating their ideas). http://erights.org/history/original-e/index.html
After that the JVM was the first target platform but the language design was not meant to depend on it.
Programming languages have to be implemented in something.
It is traditional to implement the language in something quick, and then start compiling/interpreting the language in itself as soon as possible (Now you have a very big test suite for free)
Not necessarily, I would consider an interpreter as something entirely different because there is no requirement that it abide to the syntax of the language. I feel that syntax defines the language just like spoken language. It doesn’t make sense to me to say this language english is implemented in Spanish and German.
> Not necessarily, I would consider an interpreter as something entirely different because there is no requirement that it abide to the syntax of the language.
What does this mean? A language interpreter naturally abides to the syntax of the language it implements.
> It doesn’t make sense to me to say this language english is implemented in Spanish and German.
Maybe because natural languages are a useless analogy for this in the first place.
Well, that's a system of notation, not a programming language. And it's name isn't properly "Z", it's "Z notation". I'll admit Z++ is a candidate here, but I'm excluding it for it's overly eager "++". So, we may have VR, but until there's a properly compiled ( or even interpreted) Z language, I'm still waiting for the future to arrive :)
Cap'n Proto RPC (https://capnproto.org/rpc.html) is based on E's network protocol, CapTP, e.g. utilizing The Four Tables:
http://erights.org/elib/distrib/captp/4tables.html
https://github.com/capnproto/capnproto/blob/master/c++/src/c...
(You can think of this design as an extension of the file descriptor table concept in Unix, except that both sides may export descriptors to the other side (so that calls can flow either way), and either side can be responsible for assigning the numeric descriptor value for any particular description (which makes it easier to compensate for a high-latency transport).)
When I first told Mark I was working on an object-oriented RPC protocol, he insisted I visit him and listen while he explained all this to me, and boy am I glad he did... would have taken a lot longer for me to figure it out myself.
It's crazy that most of the content of erights.org was written over 10 years ago -- I think some of it goes back to the 90's, even.