
How Eve unifies your entire programming stack - tbatchelli
https://hackernoon.com/how-eve-unifies-your-entire-programming-stack-900ca80c58a7
======
dicedog
I'm excited for Eve and next-gen programming languages but as details emerge,
it seems like it could easily have been a few libraries and an architecture
pattern in most other functional programming languages. When I first learn
about things like the continuation monad or CQRS, I have similar reinvent-the-
world fantasies but it's often sufficient to expand my toolkit and change my
style (in full disclojure ;-), my default language is clojure/script)

~~~
Liron
I think your point is valid in general, but Eve's semantics are deeply rooted
in Logic Programming. IMO that's a more fundamental change than what we can
hope to get from layering a pattern/library/architecture on top of an existing
database or programming language.

~~~
wruza
Just seems like it sells poor man's Prolog as a "fundamental change". Anyone
to dismiss my confusion?

I mean, you can throw HTML around cobol/io/cl/sql/sed with the same wow-
effect?

~~~
Liron
Check out this 2009 research paper that Eve is based on; it's an important new
extension to logic programming:
[https://databeta.wordpress.com/2010/01/05/introducing-
dedalu...](https://databeta.wordpress.com/2010/01/05/introducing-dedalus/)

Also please let me know what you think about Part II (coming later this week).
It's all about logic programming and CQRS.

~~~
tom_mellior
I only skimmed this _very_ quickly, but the difficult issues in that tech
report seem to concern issues in distributed systems. Does Eve have a
distributed "story"?

My impression was that it was mostly a synchronous rule language that, at each
time step, does vaguely Datalog-like stratified evaluation and then updates
its state. That's a very nice model and indeed rooted in logic programming,
but I have the impression that referring to the Dedalus tech report is
overselling it.

~~~
Skinney
Distributed systems is the goal for the next milestone of Eve. Remember that
Eve is still in early alpha.

------
0x01
I was keeping a close eye on Eve until it changed direction from _programming
for everyone_ to _yet another lisp_. Is there any writeup/discussion on why
this happened?

I do like learning about mind-expanding languages, and something resonated
with me when the CardWiki interface was revealed. I get that this language is
very 'human readable' but at the end of the day if I want to read or write it
I will actually have to put a lot of time into learning it.

I'm already suffering decision paralysis with my current language shortlist
and this language doesn't make the cut. The card wiki was innovative, like
LightTable. To me, this is 'just a language'. I realised you moved away from
the wiki idea for a reason but is putting a GUI on the language still on the
roadmap?

~~~
tom_mellior
> I get that this language is very 'human readable'

I wonder why people say/think that. The language uses sigils like @ and #.
Sigils _automatically_ make a language non-"human readable" since they have no
"human meaning". And no, "you just have to learn the meaning of the language
constructs and then you can read it" is not "human readable" in a useful
sense. From what I gather, in Eve the @ sign refers to databases. That's fine,
but "database foo" is human readable in a sense that "@foo" certainly isn't.

Or look at this example from
[http://play.witheve.com/#/examples/todomvc.eve](http://play.witheve.com/#/examples/todomvc.eve)

    
    
        search
          [#app filter]
        
          all-checked = if not([#todo completed: false]) then true
                        else false
        
          none-checked = if [#todo completed: true] then false
                          else true
        
          todo-count = if c = count[given: [#todo completed: false]] then c
                        else 0
    

Why aren't these just

    
    
        all-checked = [#todo completed: true]
        none-checked = [#todo completed: false]
    

? Is the triple negation relevant? What is #todo? Is there some sort of
implicit iteration over the database where #todo is bound to successive
entries? If so, how are the individual flags combined to really arrive at an
"all checked" or "none checked" value?

I know plenty of languages that are more "human readable" than this.

It might still be a nice language once you learned it. But this, too, won't be
the holy grail of "programming for non-programmers".

~~~
jononor
Eve is based on pattern-matching and is set-oriented. So

    
    
      all-checked = [#todo completed: true]
    

would match _each of_ the records with both topic: 'todo' and completed: true.
And the following commit block would once per matching record. But what is
desired here is one value for all the matching records (an "aggregate" in Eve
lingo).

Personally I think we would be much better off with a dedicated aggregate
function instead of using if/else here. And count (which is an aggregate
function), should have a default value for when no records match. Then could
get rid of the if/else there also, and have something like:

    
    
      all-checked = all[#todo completed: true]
      none-checked = none[#todo completed: true]
      todo-count = count[given: [#todo completed: false], default: 0]
    

Disclaimer: I'm just an Eve user/contributor

~~~
jononor
Thinking about it, it is possible that this proposal would not work, because
in the nothing-matches cases then the function would not be executed at all...
But maybe this could work, by widening the matching pattern.

    
    
      all-checked = all[in: [#todo], where: [completed: true] ]
      none-checked = none[in: [#todo], where: [completed: true] ]
      todo-count = count[in: [#todo], where: [completed: false], default: 0]

------
erichocean
Can Eve call into C without any overhead?

If it can't, then "your entire programming stack" is excluding the kernel and
a lot of existing libraries/code.

~~~
GavinMcG
Why does it need to be without overhead in order to be accurate that it
unifies the entire stack?

~~~
erichocean
Because to qualify as "the entire stack", you need to be able to talk to the
kernel efficiently, which in practice means: call into C without overhead.

I have no problem with what Eve is doing, but it's not "the entire stack" and
with Eve's paradigm, never will be. And that's okay—just stop calling it "the
entire stack".

~~~
jholman
Can Eve modify CPU microcode without any overhead? If it can't, then "your
entire programming stack" is excluding a lot of stuff I can't be bothered to
enumerate.

</satire>

Also relevant: "To bake an apple pie from scratch, first one must blah blah
universe blah" \-- Sagan

"Entire stack" is relative to the interests of the audience, not a description
of the entire dependency chain. If you're claiming that YOU go around
modifying the kernel, then yes, a language that doesn't do that won't replace
YOUR entire stack. (And, conversely, some people have, as their "entire
stack", less layers than in this post (for example, maybe their web-app uses
no dynamic server-side routes/state/etc, and so it's just static assets plus
super-heavy frontend JS). For such a webapp, there's less unifying possible to
do, because there were less layers to start with.)

But the stack they describe in TFA is a very common "entire stack" for a team
to have to deal with. It's very common to just take all the C/C++ bits
(kernel, libs, rdbms, probably some webserver, and so on) as given-and-
immutable, and to work at the layers above that: DB-contents, backend, web-
API, frontend, etc.

I have no claim about whether or not Eve solves these problems. I do think
that their linguistic use of "unifies your entire programming stack" is
entirely justified, in context.

~~~
cmontella
> I do think that their linguistic use of "unifies your entire programming
> stack" is entirely justified, in context.

To be clear, the author of this story isn't affiliated with Eve in an official
capacity, just one of our early users :)

Although we would like Eve to replace all sorts of stacks, we'll leave it to
our users to implement Eve where it's appropriate. What's nice about Eve is
that you can use it for as much or as little as your project requires. Eve
could strictly be the datastore layer or the frontend layer or the glue layer.
Or all three. We want Eve to be flexible, that way it can fit into a project
where it makes sense.

------
dansingerman
Not convinced either way whether having the same interface for all of the
stack is a good idea or not, but it did remind me of Joel Spolsky's blog post
on leaky abstractions
[http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...](http://www.joelonsoftware.com/articles/LeakyAbstractions.html)

~~~
Liron
Man, if Joel were blogging today he'd be dominating the HN front page...

The thing is, Eve isn't an abstraction layer over your existing layers, it's a
set of choices you can make layer-by-layer to swap out the old "unique" way of
doing things with Eve's more uniform way of doing things. The unique way was
arbitrary anyway.

Like, if the whole world all decided to start speaking Esperanto, that
wouldn't create too much of a leaky-abstraction issue.

The one issue I can see is how to scale when you use it as your database layer
and make fancy queries. But every database's query engine has its own
implementation challenges and I don't think Eve is special in that sense.

------
skybrian
The part I'm most skeptical of is Eve's universal use of set-based semantics,
whether it's needed or not. It seems like making sets and single values look
different in the code would be more understandable than making everything look
the same. Treating them as different types might be a good way to catch
errors, too.

But SQL is very successful so maybe they'll do okay anyway.

~~~
velox_io
My startup Velox.io ([https://velox.io](https://velox.io), which is looking to
go live in the next couple of months) is working on the same issue. Right now
writing code is overly verbose (and often brittle). The author does make some
good points around unifying API, Database and Application code. Most code is
centred about moving data from A-B, with some logic applied to it.

Eve done some interesting stuff, as has Linq from .net, AWS's Lambda's, even
Kx's Q in the way it handles temporal data.

My hypothesis that writing software can be greatly improved; There is a lack
of programmers, yet most people are capable of creating spreadsheets (and
writing formulas). Using spreadsheet is similar to programming, what makes
programming much more complex is the different systems involved and lack of
rapid feedback.

People have been trying to make programming easier/ accessible since the days
of Hypercard, but no one has really cracked yet.

Edit: Downvote if you will (I've spent years on this), at least write a
comment to say why.

~~~
sly010
> People have been trying to make programming easier/ accessible since the
> days of Hypercard, but no one has really cracked yet.

There is no shortage of good programming languages and useful paradigms. The
problem is how to interface with existing systems written in a different
language with a very different mindset (e.g. your operating system). Someone
has to write code to bridge those abstractions, and that only happens if
enough resources are concentrated at the right place.

------
miguelrochefort
I've been looking for the holy-grail for years (TodoMVC being my benchmark),
and Eve takes the cake.

I'm looking forward to compatibility with semantic Web technologies.

------
sua_3000
I feel like reconciling the divide between the client/server relationship is
the next major opportunity for abstraction

~~~
Liron
Eve helps do that - not in the current version (0.2), but soon your
application will be able to interface with a remote server the same way it
interfaces with its in-memory data and functions.

------
tonyjstark
After all these promising presentations and blog entries about what thoughts
went into Eve, I'm a bit dissapointed by the result. Or I'm ignorant and don't
get it (yet?). Sure, it utilizes literate programming and it abstracts a lot
away but it does not seem as revolutionary as the communication around it
suggested. Maybe the next articles in this series will enlighten me.

~~~
miguelrochefort
The big takeaway is not literal programming but logic programming and pattern
matching.

------
z3t4
I'm glad there are people rethinking how we develop programs. But as a web
developer, the examples in Eve looks more complex then a naive implementation
using vanilla CSS, HTML and JavaScript would look like, for example, how do
you make something 10 pixels wider in Eve ?

~~~
jononor
Click the inspector wand on the UI element you want to change, this will move
the editor to the Eve block which created it. In TodoMVC the styling is
handled with a CSS file, so you go to change it there. Or you add an inline
override. The @browser database is a very thin wrapper around DOM/HTML, ala
React/JSX.

------
quantumpotato_
I'm impressed with the abstractions! What are recommended "Learn Eve"
tutorials?

~~~
zubairq
[https://github.com/zubairq/Eve/tree/master/tutorial](https://github.com/zubairq/Eve/tree/master/tutorial)

------
tharibo
Title : "your entire programming stack".

I feel sad when I find that web programmers think there are only web stacks
and "programming" refers only to web programming.

It is not entirely the case here, but the description of "a core system" as :

\- Database layer

\- Remote API layer

\- Application layer

made me tick.

~~~
pjmlp
Same here when they refer to front-end as a synonym for Web UIs, as if there
wasn't quite a few of us doing 100% native UIs.

~~~
k__
how much percent of front-end devs do 'only' native UIs?

I mean even most of the mobile people were web devs once...

~~~
pjmlp
Everyone that does applications that require OS APIs, interaction with
external devices, factories, embedded, air gaped desktops, care about the
UI/UX of the user.

Native UI isn't a synonym for mobiles.

~~~
jononor
The phrasing/example in article is very web-oriented. But can you imagine
interacting with your native UI toolkit as an Eve database, similar to how
@browser works? Or your external devices over a protocol, similar to how @http
or @mqtt works?

~~~
pjmlp
Yes, it was called Lisp Machines,Mesa/Cedar and Smalltalk.

------
dkarapetyan
How does one package and deploy an Eve application to some cloud
infrastructure for example?

~~~
cmontella
[Eve member]

That's in the PR pipeline right now, you can track it here:
[https://github.com/witheve/Eve/pull/571](https://github.com/witheve/Eve/pull/571)

Although I should mention, Eve is super early Alpha right now, so don't deploy
anything you will be depending on!

~~~
dkarapetyan
Cool. Good to know it is in the pipeline.

------
tedajax
Yeah until I really see some practical applications written in Eve I don't
think I'm ever going to really get it. It's nothing against Eve, it might be
great, but nothing I've seen about it so far as really captured my imagination
and I'm wondering if I'm just missing something.

~~~
ibdknox
[Eve member]

Out of curiosity, what would you classify as a practical application? We're
looking for some interesting examples to build to help show Eve to folks.

EDIT:

For instance, one of the examples we're throwing together now is an app that a
food truck owner could use to put up their menu, manage a queue of orders (in
person and online), alert people when their order is ready, accept payments,
and post to social media. We picked this because it's an app trucks could
actually use and it has lots of "real" functionality in it - from stripe
integration to social media posting. Also, who doesn't love food trucks? :)

~~~
ilostmykeys
Why don't you just make that app for iOS/Android and let food truck owners
download it? I know that is a useless thing to suggest given your intent but I
think it's equally useless for food truck owners to want to build their own
app. There must be a better range of use cases.

~~~
erikpukinskis
You were flagged but this is a great question.

I think the more useful ability for the food truck operator is the ability to
_modify_ the software their business runs on, not the ability to build it from
scratch.

Imagine everything on everyone's desk was bolted to it, and you could only
choose between a few desk packages. Someone comes along and says "people
should be able to put together their own desk packages!" But everyone wonders:
"huh? I'm not a furniture engineer. What would I do with a custom desk that I
can't do with an off-the-shelf one?"

But as we know people come up with all kinds of uses for desks when they are
allowed to reconfigure them freely.

That's what we're losing out on by not making software reconfigurable, at
least a little bit at the top layer.

What we have right now is a series of buttons that add or remove bolted down
components from your desk. Eve is trying to imagine what it might look like to
actually be able to move things around freely, add duct tape etc.

I know it's a weak argument, because no one really knows what people would
exactly do with the ability to modify their software. It just seems to me like
the kind of thing that would pay off.

~~~
fsloth
"no one really knows what people would exactly do with the ability to modify
their software."

I think we do. Excel, and the various systems implemented on top of it. To my
understanding systems built on top of Excel are used to run all sorts of
things, even live hardware, because it's so approachable and easy to modify.

Perhaps Eve can be 'sold' to the industries that rely on Excel. First the
project can just add @excel database....

------
dajohnson89
Seems cool

------
Cozumel
Another 'solution' to non-existent problems.

------
klibertp
> Eve is the culmination of years of research and development by the visionary
> team who previously founded Light Table.

...and then abandoned it after getting me excited about a possible Emacs
replacement...

~~~
buovjaga
Still being developed, though:
[https://github.com/LightTable/LightTable](https://github.com/LightTable/LightTable)

~~~
klibertp
They had 2 Pull Requests last month, closed 6 tickets and created 4 new
tickets. To quote the "Pulse" section:

> Excluding merges, 2 authors have pushed 2 commits to master and 2 commits to
> all branches. On master, 4 files have changed and there have been 64
> additions and 15 deletions.

This is not the kind of activity I'd expect in the project under active
development. Compare to Emacs[1]:

> Excluding merges, 39 authors have pushed 227 commits to master and 260
> commits to all branches. On master, 352 files have changed and there have
> been 6,143 additions and 3,732 deletions.

...and that's Emacs main repo, excluding all the development happening in
plugins.

But well, that's actually not that important; what matters is that LightTable
badly needs a serious refactoring, because reportedly there is just one person
who actually understands the codebase (and it's Chris). Such refactoring is
not going to happen, though, because people who actually could do it abandoned
the project.

Perhaps it's not even a refactoring that's needed, but a rewrite. Even if
using the same language - ClojureScript - the project would be supposedly
written in a totally different way due to the changes in the ecosystem.
Switching languages would require an immense amount of careful weighing of
pros and cons, but it may be worth considering.

Still, this is not going to happen, the code and effort that went into LT are
essentially wasted now, possibly with the exception of the learning experience
for the authors.

I'm writing this much about it because I really hoped LT to be a modern
incarnation of Emacs, as the latter was starting to show its age. Instead,
however, LT is dead. On the other hand Emacs got embeddable xwidgets in the
last release - which means that (in time, it's not very usable as-is) we will
get the in-buffer, full web browser.

[1] [https://github.com/emacs-
mirror/emacs/pulse/monthly](https://github.com/emacs-
mirror/emacs/pulse/monthly)

