The E Programming Language
erights.org
erights.org
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.
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.
Thanks Mark!
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.)
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.
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.
[1] https://legal-dictionary.thefreedictionary.com/unconscionabl...
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.
Lambda-the-Ultimate: "A Next Generation Smart Contract and Decentralized Application Platform", Vitalik Buterin. - http://lambda-the-ultimate.org/node/5003#comment-94645
Mark Miller: Agoric and the Decades-Long Quest for Secure Smart Contracts. https://letstalkbitcoin.com/blog/post/epicenter-mark-miller-...
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.
>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.
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.
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.
I would imagine at that price point that any domain is at least negotiable, so why list it?
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.
I don't suspect anyone has ever actually been interested in buying the domain, to be perfectly honest.
e-on-javascript: https://github.com/kpreid/e-on-javascript
https://web.archive.org/web/20190423063056/http://habitatchr...
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.
[1] https://www.infoq.com/interviews/johnson-armstrong-oop/
Salient quote from above
> 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.
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.
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).
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)
Or here: https://en.wikipedia.org/wiki/HotSpot "Written in C++, Assembly"
Or here: https://blogs.oracle.com/sundararajan/so-you-want-to-read-ho...
I should have said Perl to really bring out the pedants.
Also OpenJDK is just one implementation among several.
OpenJDK is a mix of Java and C++, with long term roadmap to replace more and more with Java, also known as Project Metropolis.
IBM J9 is a mix of C++ and Java.
JikesRVM is bootstraped in Java.
Then there are PTC, Aicas, Websphere RealTime, J/Rockit, Azul (with LLVM integration), GraalVM (mostly Java), Ricoh JVM, Cisco JVM, Gemalto,...
After that the JVM was the first target platform but the language design was not meant to depend on it.
Tenatively available: G - because of G-code and Go, I - because of Io, L - because of LLL, N - because of Nu, O - because of Oz
edit: formatting