
E Programming Language - greencore
http://erights.org/
======
kentonv
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](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](http://erights.org/elib/distrib/captp/4tables.html)

[https://github.com/capnproto/capnproto/blob/master/c++/src/c...](https://github.com/capnproto/capnproto/blob/master/c++/src/capnp/rpc.capnp#L116)

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

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

Thanks Mark!

~~~
Twisol
> 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.)

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

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

------
abecedarius
There's an active remake of E with a different syntax and new implementation:
[https://monte.readthedocs.io/en/latest/](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.)

~~~
benatkin
At the bottom of the page, it says "Copyright 2014". Did you mean actively
maintained or active in some other sense?

~~~
abecedarius
I looked at the implementation repo and it has recent commits. I don't think
that's true of E itself (I was a minor contributor 20 years ago).

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

[1] [https://legal-
dictionary.thefreedictionary.com/unconscionabl...](https://legal-
dictionary.thefreedictionary.com/unconscionable)

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

------
infominer
Related resources:

Lambda-the-Ultimate: "A Next Generation Smart Contract and Decentralized
Application Platform", Vitalik Buterin. - [http://lambda-the-
ultimate.org/node/5003#comment-94645](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-...](https://letstalkbitcoin.com/blog/post/epicenter-mark-miller-
agoric-and-the-decadeslong-quest-for-secure-smart-contracts)

[https://agoric.com/](https://agoric.com/)

[https://infominer.id/bitcoin-history/smart-
contracts/](https://infominer.id/bitcoin-history/smart-contracts/)

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

[https://en.m.wikipedia.org/wiki/Confused_deputy_problem](https://en.m.wikipedia.org/wiki/Confused_deputy_problem)

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

~~~
dmitriid
Smart contracts are vaporware.

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.

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

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

------
azhenley
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?

~~~
kvakvs
It doesn't cost that. Probably been approached multiple times and got tired of
replying, so they've set a prohibitive price.

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

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

------
ghosthamlet
The E on Common Lisp Project website is down, code on github:
[https://github.com/kpreid/e-on-cl](https://github.com/kpreid/e-on-cl)

e-on-javascript: [https://github.com/kpreid/e-on-
javascript](https://github.com/kpreid/e-on-javascript)

------
anaphor
If you're interested in E and Object Capabilities (ocaps) in general, I
_highly_ recommend reading this essay:

[https://web.archive.org/web/20190423063056/http://habitatchr...](https://web.archive.org/web/20190423063056/http://habitatchronicles.com/2017/05/what-
are-capabilities/)

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/](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.

~~~
abecedarius
That's a great intro.

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.

------
blackflame7000
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?

~~~
voldacar
By that logic, every programming language is just an assembly framework ;)

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

~~~
boomlinde
_> 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.

------
SergeAx
List of available letters for programming languages: H, U, V, W, Y

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

------
amai
Anyone remembers
[https://en.wikipedia.org/wiki/Amiga_E](https://en.wikipedia.org/wiki/Amiga_E)
?

~~~
ahje
Yeah, I was a bit dissapointed that this wasn't a new modern compiler for it.
:)

------
ineedasername
We got as far as S, then it took a step backwards to R. Now back to E? It
seems like language Z is perpetually ten years away, and always will be.

~~~
macintux
Z has been around for 40 years. Used to have a book on it.

[https://en.wikipedia.org/wiki/Z_notation](https://en.wikipedia.org/wiki/Z_notation)

~~~
ineedasername
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 :)

------
hoseja
So, a general Stacksort? [https://xkcd.com/1185/](https://xkcd.com/1185/)

