
Eve: Programming designed for humans - ibdknox
http://programming.witheve.com/
======
jbclements
I think that Eve is tackling the wrong problem.

Allow me an analogy: "Bronk, the math designed for humans." Instead of dense
algebraic expressions like "3x+49", you get to write "thrice the value of x
plus 49." You may consider this a straw man, but I think that if you look hard
at existing programming languages, you'll see that they are all designed for
humans, and that the challenge in programming is in formulating your thoughts
in a precise fashion. Should languages create higher-level abstractions to
allow humans to reason about programs more efficiently? Yes! But that's not
what this environment is about.

I _do_ see one possible rebuttal to this, which would be an entirely different
form of programming that is to traditional programming what google search is
to the semantic web; that is, rather than specify programs precisely, we give
examples to an approximate system and hope for the best. In many ways, that's
how our biological systems work, and they've gotten us a long way. I don't see
that happening in Eve, though.

~~~
noonespecial
This seems to always happen when people try to make programming "more human".
Programming languages succeed by _walling off ambiguity_. The better and
faster they do it, the stronger the language, even if the syntax looks ugly.

Even your example shows it instantly. We know how to read 3x+49 but would have
to ask of "thrice the value of x plus 49", "did you mean 3 times what you get
from adding 49 and x or 49 more than 3 x's?".

Projects to humanize programming always seem to suffer from "magic genie"
syndrome. When you ask a genie for $1mm you don't expect him to go rob a bank
or kill your dad for his life insurance to get it. Human language makes tons
of implicit assumptions about the recipient. It would take a general (strong)
AI to make that work with a computer.

The ultimate expression of success would have your "program" simply read "I'd
like a game just like _Flappy Bird_ but with my logo instead of the bird".

~~~
cmontella
Actually, we agree completely with this view. We tried going down this path
[1], and ultimately concluded it was the wrong direction, for many of the
reasons you point out here.

But Eve is a full programming language. The "humane" aspects are not about
making the language more ambiguous, but about changing the focus of tooling
from the machine to the human. It's about things as simple as Unicode support
for language localization. Or rendering headers in your code. It's about
making the syntax and semantics very small and easy to understand. It's about
closing the write-compile-test loop, by showing the result of code /in/ the
actual code. It's about debugging tools that work with you to solve a problem.

We're just saying we don't want to compromise. We want a beautiful, concise,
easy to understand language AND we want humane tooling. In order to get that,
we had to abandon the traditional imperative programming model, and that comes
at a cost. But I think in the long term it will be worth it.

[1]:
[http://incidentalcomplexity.com/2016/06/14/nlqp/](http://incidentalcomplexity.com/2016/06/14/nlqp/)

~~~
LoSboccacc
so basically Java?

~~~
JBReefer
Good tooling, easy to understand, unambiguous? Sounds like Java.

Why can't people just use Java?

~~~
LoSboccacc
there's quite a lot of bad practices surrounding the language back from where
the enterprise tooling was a mess and xml was the rage, we're ten years past
that but the language hate has never ceased (see my comment: -1)

I get the hate from the frameworks craze, but if one is in a position of being
forced a crazy bloated framework without recourse that's not Java fault.

apart from that, you can debug servers the other side of the world with ease,
hot replace code as you execute it, walk the heap with a lot of different
views available, it has recently got top notch profiling, a sane injection and
inversion of control framework which you can still debug at runtime, all the
libraries you can dream of and bridges to hardware for the most demanding
tasks.

~~~
strictfp
I have held out since I love the language. I started using Java when it was
new and actually very pragmatic and useful. Hated the enterprise phase, got
bogged down by it but rose from the ashes. Now I'm a strong proponent of
simplicity and libs over frameworks. And Java has great speed and simplicity
for most tasks when memory management isn't a problem. But it's a constant
struggle against old values in the business. And it doesn't take many
conservative and bureucratic people to ruin a creative crowd. So I am looking
to jump ship to what I consider in many ways inferior languages just to be
able to be part of a modern culture.

To be clear, I still work at a company which is extremely forward (in
averyting in beta sort of way). But still these old values hold everyone back
and cause endless discussions of frameworks, processes and control structures
vs creativity and speed.

~~~
tormeh
What do you think of Scala?

------
ibdknox
Hi All!

Many of the folks here have been following us for a long time and we're really
excited to finally pull everything together to show you all where our research
has taken us. Eve is still very early [1], but it shows a lot of promise and I
think this community especially will be interested in the ideas we've put
together. As many of you were also big Light Table supporters, we wanted to
talk about Eve's relationship to it as well [2].

We know that traditionally literate programming has gotten a bad rap and so we
laid out our reasoning for it here. [3]

Beyond that, we expect there will be a lot of questions, so we'll be around
all day to try and answer them. We'll also been doing a bunch of deep dives
over the next several weeks talking about the research that went into what
you're seeing here, how we arrived at these designs, and what the implications
are. There was just way too much to content to try and squeeze it all into
this page.

Also, a neat fact that HN might be interested in:

Eve's language runtime includes a parser, a compiler, an incremental
fixpointer, database indexes, and a full relational query engine with joins,
negation, ordered choices, and aggregates. You might expect such a thing would
amount to 10s or maybe 100s of thousands of lines of code, but our entire
runtime is currently ~6500 lines of code. That's about 10% the size of React's
source folder. :)

[1]:
[http://programming.witheve.com/deepdives/whateveis.html](http://programming.witheve.com/deepdives/whateveis.html)

[2]:
[http://programming.witheve.com/deepdives/lighttable.html](http://programming.witheve.com/deepdives/lighttable.html)

[3]:
[http://programming.witheve.com/deepdives/literate.html](http://programming.witheve.com/deepdives/literate.html)

~~~
mkozlows
So your defense of literate program gives, as a defense, what I would think of
as an attack on literate programming:

    
    
      Take this strawman for instance, how could you find the bug in 
      the following code without the accompanying comment?
    
      // Print every other line of the array to the console
      for (var i = 0; i < myStringArray.length; i++) {
          console.log(myStringArray[i]);
      }
    
      This shows how important intent is to a program. Yes, the  
      example is trivial, but without that comment, how would we know
      that it's wrong?
    

Because the problem with that is that now you have two competing sources of
authority -- the comment, and the code. One of them is right and one of them
is wrong. But which is the right one?

In the real world, the answer is almost always "the code that's actually been
executing, rather than the comment that hasn't," which is why it's a good idea
to minimize commentry of that type, to prevent confusion on the part of the
reader.

So if you're doubling-down on literate programming, how do you address that
problem? That article says, "Inconsistencies between the code and the prose
are themselves errors in the program and they should be treated as seriously
as a buffer overflow," but does Eve actually do that? It's hard for me to see
how it could, in the examples given.

(If the idea is simply that this is extra work for the programmer to do --
that they need to describe every implementation twice, once in code and once
in English -- I submit that it's not very human-focused at all, if those
humans are programmers.)

~~~
pjc50
This is why comments that specify what the code does are a "code smell".

Comments should explain things that are not obvious from the code. Comments
should be things like

// Note: PCI-DSS requirements apply below

// Must check status register and FIFO to determine completion due to flaky
hardware

// Algorithm below is modified Knuth-Morris-Pratt

// This is O(scary), but seems quick enough in practice.

(Now, if someone lets me put _images_ in comments, that would be amazing. Good
for state transition diagrams and random scribbles)

~~~
brianwawok
You didn't solve the OPs problem, you just moved it around.

In his case, his algo said X, and his code did Y.. very easy to see the
mistake.

In your case, lets add a comment

// Note: PCI-DSS requirements apply below

Now 3 years later, the law changes and the requirements do not apply. So you
are at the same situation. Code does X, comments say Y. Which is right?

Not a very easy to keep comments and code in sync

~~~
pjc50
That comment I'd interpret as the requirements must be considered in this
region; so if the law changes, the requirements still _apply_ , it's just that
the code needs to be updated.

Requirements are usually exogenous to the code.

~~~
prodigal_erik
"PCI-DSS requirements apply" isn't adequate in a literate program for the same
reason that "must work correctly" isn't adequate. Explaining the relevant
requirements in detail is a crucial goal.

------
grzm
I think there's potentially a lot of ways we can improve our programming
environments. I like moon shots, people willing to explore new ways that are
unconventional, approaching problems in different ways. I've followed Light
Table and have been looking forward to seeing what Chris and friends come up
with for Eve.

That said, this is feeling very grandiose. I'd like to understand more clearly
where they see Eve being useful — and where Eve would _not_ be useful. For
example:

\- how does one implement new algorithms? A simple example, how do I write
Quicksort?

\- can Eve be written in Eve?

Admittedly, I haven't thought about this nearly as much as the Eve team has.
And perhaps I'm just lacking the required imagination at this point. That
said, I'd like to see these types of questions addressed. There's nothing
wrong with a tool that's useful in a particular set of circumstances. I'd like
to know what the Eve team thinks those circumstances are.

~~~
ibdknox
Check out our followup on that :
[http://programming.witheve.com/deepdives/whateveis.html](http://programming.witheve.com/deepdives/whateveis.html)

1) Eve is amazing at graph algorithms, not so much at writing quicksort. At
the same time, you don't need to write quicksort in Eve - it has all of the
things you'd get from something like a SQL database. In general, anything
requiring strict sequential order will be just ok right now, but it turns out
actually very few things do.

2) sure and we have written some of it in Eve, check some of my other comments
for links :)

~~~
evincarofautumn
Is there a more precise description of the runtime semantics anywhere? “A
variant of Datalog” is helpful but doesn’t say much.

For instance, it looks like every “commit” is essentially a sequence point
that produces a step in the “fixpointer”—and from that terminology I guess Eve
is Turing-complete, unlike Datalog? Do you test all patterns at every commit,
or only those whose dependencies have changed? And if the latter, then how do
you track such dependencies? Are they fully specified declaratively by
queries? And what is the granularity—per term, per database?

~~~
anewhnaccount
The semantics are similar to Dedalus, which is compared to Datalog here:
[https://www.youtube.com/watch?v=R2Aa4PivG0g](https://www.youtube.com/watch?v=R2Aa4PivG0g)

~~~
evincarofautumn
That was an excellent talk, thanks. It cleared up a lot of details about the
paradigm for me. That said, now I’m more interested in Dedalus/bloom than Eve.
:P

------
rafaelferreira
Seeing Eve's development out in the open is inspiring. Many of the commenters
are coming from positions of extreme skepticism towards new approaches to
programming, probably justified by the history of the field, but I'd recommend
to spend some more time looking into the research idbknox and his team have
been conducting (see
[https://www.youtube.com/watch?v=VZQoAKJPbh8](https://www.youtube.com/watch?v=VZQoAKJPbh8),
for instance) and how much they have iterated based on user experimentation.

A few questions come to mind now: 1 - This new demo, with the messaging app
sample, and references to "my pm wants this or that" seems to point a change
in positioning, from targeting non-programmers to professional programmers. Is
this accurate?

2 - Is there a plan to integrate the grid-style or the adlibs style UI into
this new iteration?

3 - If non-programmers are still a target, it seems to me that the ease of
importing data from external sources would important to reach broad usage. Any
research here?

4 - Html and css might be a hurdles for new users, any way Eve will help on
this front?

(edited for formatting)

~~~
joshuafcole
Solid questions!

1\. We could be more clear about this, but expanding to suit the needs of non-
programmers is still very much in the cards. It falls under the umbrella of
milestone 3 [1].

2\. We're very interested in improving the process of generating UI. To start
with, that will mean expanding our library of views (essentially Eve's version
of web components) to cover a wider range of common use cases. Beyond that
though, HTML is pretty crufty with layers upon layers of of additions and
legacy support, it would be very interesting to explore alternative markup
models.

3\. It certainly is very important. Our model for interacting with the
external world is pretty simple. For the most part You can use our first party
modules (like `@http` for web requests) to pull the requisite data into Eve
where you can transform it into whatever shape is appropriate. For cases where
you need entirely new transport systems (like connecting Eve to USB devices),
you can create a new module just like the first party ones and side load it
in. Since the runtime is currently written in Typescript, that's the language
of choice for these extensions. We may support others in the future.

4\. For users unfamiliar with HTML and CSS, the best we can do is insulate
them from it, as in #2. If it's a subject that personally interests you, I'd
love to strike up a conversation on the mailing list about how we can improve
the markup process [2].

[1]
[http://programming.witheve.com/#justataste](http://programming.witheve.com/#justataste)
[2] [https://groups.google.com/forum/#!forum/eve-
talk](https://groups.google.com/forum/#!forum/eve-talk)

------
king_magic
How is this significantly different from something like Light Table? (edit:
didn't realize it was build by the people who built Light Table). It feels
like a rehash of that + Python notebooks, with a bit of Xcode's playground
thrown in.

Problem is that despite those tools being available, I literally never use
them. Ever. Nor do I have a need for them.

I kind of like the idea of being able to find bits of code in a larger
codebase in a document-like format. That's actually a pretty neat innovation
here.

But beyond that, I don't think I'd use this (edit: per comment thread
conversation below, I'm upgrading this to not being sure if I'd used this, but
it's a maybe). I need an IDE that will help me through the Battle of
Stalingrad, not a basic case like a police offer pulling someone over for a
speeding ticket, which is what many of these kinds of next-gen UIs always seem
to show.

Basic stuff is easy enough to accomplish right now. I don't need a new IDE to
help me add a button to each row in a list any quicker than I currently can
with existing tools, and I feel like a core problem with these types of
efforts are that they start with basic cases and never really progress from
there - many engineering problems simply do not reduce down to adding a button
to a screen.

That all said - I think if you pivoted and built a wiki-like overlay that
could be dropped over an arbitrary codebase (e.g. extrapolate out the
document-like overlay over code to document and organize a codebase), holy
crap, I would instantly pay money for that, especially if it was distributed
team-friendly.

~~~
ghotli
Honestly I think this looks excellent for exposing children to programming.

~~~
ifdefdebug
I humbly disagree. My kid is going to get something totally straight forward
imperative and easy to begin with, something in the realm of «one print "I am
the best", two goto one». I strongly believe these are the basic building
blocks which make everything else easy to understand, and they give you a good
feeling about how the things work at the bare metal.

~~~
douche
I think it's a shame that QBasic isn't bundled with Windows anymore. That was
how I got started, on some old 486s in my chemistry/programming teacher's
classroom, and it was really a fantastic integrated programming experience,
very simple, but with room to do some really cool things. I remember that by
the end of a year, a friend and I made a really terrible, but mostly working,
version of Slime Volleyball, with graphics and even some basic MIDI sound
effects.

~~~
curioussavage
Doesn't come with windows but here is Microsoft small basic

------
highCs
I think this is awesome and I encourage this extraordinaire effort.

Here are my reasons:

1\. I've actually coded something similar a long time ago (I think Eve is even
better than my solution) and it worked. My team and I were able to make entire
apps in a heartbeat.

2\. The reason it works is because, as pg famously wrote, programmers think in
the language they use. Our cognitive load and power are function of the
language we think in. The key to Eve on this purpose is that you can program
not only your app, but the development organisation that goes with it. Also,
it is beginner friendly.

3\. With 1. and 2., you get that Eve is related to reflectivity and
homoiconicity. Maybe it is what's behind homoiconicity: your code and your
organisation share the same language.

I wish the Eve team the best.

------
DonaldFisk
First impressions: I like the look of this language/IDE. It's not general
purpose but it seems to be good at what it does. I think live programming -
where you make changes to your code and immediately see the effect without
having to recompile and restart your system - is the way forward. The adoption
of literate programming is interesting - I think commenting code is
unsatisfactory for a variety of reasons and am looking for an alternative, and
Knuth's idea might be worth building on. The other idea I like is the ability
to point at a widget and find out the code that draws it - that makes
debugging a lot easier.

------
zerker2000

      Instead of thousands of debugger options, let's have a magic tool where you click on the thing that's going wrong.
    

There are reasons for the thousands of options though! Like, "debug this
specific object" or "breakpoint when this condition is satisfied" exist as
primitives already; there's more complexity there than just "what is the data
backing this UI element". If Eve has indeed managed to get away from needing
them, that is laudable, but it would be achieved by the full set of things you
might want to do being blindingly obvious, not "magic" special-cases for "I
was expecting something here and I don't see it"

------
qwertyuiop924
This is a neat idea. But I'm wary of the pitch, at least a little. I like to
know what my code is doing, at least in general. So when they said
"programming designed for humans," that worried me: I don't like magic, that
that's usually what "programming for humans" entails.

------
nercht12
Seems to me it will have some good uses. The promo of it being "more human" is
a stretch, yes, esp. given the actual programming language didn't look any
friendlier than any other language imo (e.g. world<-[#div style: [user-select:
"none" -webkit-user-select: "none" -moz-user-select: "none" children ...) But
it's nice of them to make a valiant effort at trying to create a new method of
doing things. Reading the "What Eve Is" page is helpful:

[http://programming.witheve.com/deepdives/whateveis.html](http://programming.witheve.com/deepdives/whateveis.html)
"Being explicitly designed for data transformation, there are somethings that
Eve will particularly excel at..." (after beta stage, of course)

That said, it'll be interesting to see what software people decide to create
with it and where this system excels.

~~~
joshuafcole
Heh, as another commenter said below, "i see the first problem is that you're
generating HTML". The nice thing is, that is in no way intrinsic to Eve. The
@browser DB is a regular DB like any other that we happen to sync to the
client, and the client has a bit of code (which users will be able to extend
in the future with other functionality) that takes HTML-shaped records and
turns them into actual DOM on the screen.

Since we are targeting programmers first right now, it seemed better to focus
on other aspects of the editing experience than to try and re-invent document
markup to start with. That said, we're not opposed to exploring that
possibility down the road. If you have any thoughts on the subject I'd love to
strike up a conversation on the mailing list [1].

[1] [https://groups.google.com/forum/#!forum/eve-
talk](https://groups.google.com/forum/#!forum/eve-talk)

------
loeber
I like the look of this project, and it's in many ways inspiring, but here's
my cynical take:

I think that Eve won't be conducive to creating applications beyond a few
hundred lines of code -- after that, the "human-friendly" programming paradigm
becomes an obstacle to production. Once people actually understand how the
code works, the document style becomes superfluous.

I suspect that Eve will be a great learning tool and pique the interest of
those who would otherwise never program, but Eve will be an introductory tool
that users will inevitably graduate from to other languages that are perhaps
more powerful, concise, and scale better.

~~~
alkonaut
A ton of programming is done in Access and Excel. Perhaps _most_ business
calculation and presentation formulas are done in those "integrated"
environments, and not in languages as we "programmers" know them.

I can see this fitting a niche between Excel and "normal" programming. That
niche might be a lot bigger than we think.

I think we may be a bit blinded as regular programmers to who is actually a
programmer, and where programming happens.

------
lahardy
It seems like you are aiming for two main things at once, 1) to create a
"literate programming" environment (document structure, real-time
visualization, etc) and (in service of that?) to use this "world as data"
model. As a non-expert programmer, I have to say I don't quite understand the
implications of the search/bind/commit approach, specifically whether it was
necessary in order to implement the features of the environment that make it
human-friendly, or whether you consider it to be, in itself, a human-friendly
approach.

My feeling is that the language itself is not really any more human-friendly
than any other. You say in the "what Eve isn't" section that it's not for non-
programmers-- but if the environment and language were both truly human-
friendly, one benchmark of that would likely be a lower barrier to entry for
non-programmers.

That said, again as a non-expert programmer, I see massive value particularly
in the "document" approach-- though I see it less as human-friendly, and more
as human(s)-friendly. Most of my programming experience has been as a graduate
student, either scientific programming or (small) app and website development,
and it is often the case that code is passed down in time from person to
person. Each time you get someone else's project you initially have to rely on
code organization conventions, file names and comments to figure out how the
program really fits together, before you can even start working with it (and
the tendency, for small-ish projects, is to want to avoid this work and just
rewrite it yourself). The code-as-document approach seems wildly better for
these particular use cases. I want to echo king_magic's comment, that if a
wiki-like overlay could be used on top of an arbitrary codebase, it would go a
long way toward human(s)-friendly programming, and I'd use the heck out of it.

~~~
anotheryou
> wiki-like overlay

so just a nice rendering of comment? sounds like it might be possible with
syntax highlighting and markdown-enabled comments

------
jhomedall
I've just started following along with the quick-start tutorial, and I have to
say that the presentation is quite fantastic.

Combining the source, tutorial documentation and program output along with the
ability to selectively enable blocks of code makes for a unique experience
that I haven't seen elsewhere (Jupyter Notebook comes quite close, however). I
recommend anyone reading this to give it a shot:
[http://play.witheve.com/#/examples/quickstart.eve](http://play.witheve.com/#/examples/quickstart.eve)

It's a shame the majority of the posters here seem to be preoccupied with the
tagline, rather than the actual project.

------
afhammad
I was just listening to DHH's interview [0] on Tim Ferriss's podcast. On the
question of beautiful code DHH said among other things "I open up any piece of
code in Basecamp and it kind of reads like a great table of contents..." That
immediately made me think of the work being done with Eve based on recent
screenshots. Can't wait to try it out.

[0] [http://fourhourworkweek.com/2016/10/27/david-heinemeier-
hans...](http://fourhourworkweek.com/2016/10/27/david-heinemeier-hansson/)

------
hacker_9
So my immediate thoughts are this looks very nice for designing websites with.
It does look like the ideas all rely on a static webpage though (not many
moving parts). As I understand it, your page is built with a set of tagged
content in a DB, and then further queries can access data via those tags.
You've fit together a DB + real time feedback + visualisations in an appealing
way that actual makes creating webpages look fun. Something that is otherwise
a terribly monotonous task in the current JavaScript climate.

I wonder how well these ideas work as you ramp up to complex algorithms
though. For example 5 nested for loops with 10 000 records of data would
likely choke your visualisation to death. Also often the decision of choosing
your data structures (list vs hash table vs concurrent queue vs ...) are
paramount to the performance of the application. A single DB I can't imagine
always being the best approach, but one idea could be to measure the data
frequency passing though and optimise for the best structure perhaps? Similar
to how SQL operates at the moment.

The idea of splitting functionality up into blocks is interesting, though I
think you are focusing too much on the literate side of things. I think I
would just keep the English text to a minimum, only explaining the 'why' and
let the code explain the 'what/how'. But forgetting that, the block separation
idea is nice enough on it's own, especially with the table of contents.

I've not looked very in-depth at the language, but what you did in the video
did seem a bit like magic at times, and the simplicity seemed to hint at a lot
of code hidden away behind simple looking APIs. Meaning doing anything out of
the norm would find yourself having to roll a lot of your own code, but I
could be assuming wrongly here so won't dwell on it.

I did notice that there was no autocomplete popups in the video. Does this
mean you've forgone a type system of any sort? I would hope not as TypeScript
has shown the productivity hike adding a few simple type annotations can give.
Fully 'dynamic' code bases tend to be nightmares after a certain LOC
threshold.

All in all congrats for giving a new outlook on programming by combining a set
of old ideas in a new streamlined way, and giving HN something else to grumble
about for a while!

------
xaduha
In all honesty I'm more impressed by this [1], but I will take a look.

[1] [http://www.red-lang.org/2016/07/eve-style-clock-demo-in-
red-...](http://www.red-lang.org/2016/07/eve-style-clock-demo-in-red-
livecoded.html)

------
agumonkey
Pretty neat (understatement). From a quick glance, blend of notebook/literate
with smalltalkish introspection.

Kudos for keeping at the idea for long (I remember when you left LT and talked
about possible ideas a while back) and delivering something that simple yet
inspiring.

ps: the team bug fixing interactions reminds me of IBM Jazz days, it seemed so
heavy, and here it seems so light.

------
cocktailpeanuts
"An IDE like Medium, not Vim"

What's wrong with Vim? I think they're trying to cater to "the non-programmer
crowd" with this, but by trying so hard it's alienating real programmers. I
love vim, and I hate Medium with passion. I'm sure there are a lot of other HN
people who are not so much a fan of the types of people who just write meta
posts, rant posts, listicle posts, self help posts, growth hacking posts on
Medium and call themselves a "maker" without actually building anything
meaningful. So, you've lost me there Eve. Anyway, that aside, looking more
into how this tool really works, this is NOT something an everyday Joe will
use like they speak English. This is an actual programming language. The
language itself is no easier than python or ruby (actually subjectively
speaking the syntax is less intuitive than python for example).

Also I think they're imagining that Excel users will just eat this up, since
it's kind of like how people run pseudo-programs on excel documents. But
people used those because Excel was the most popular app that lets them work
with numbers back then. Now there are many ways to achieve what Eve is trying
to do, plus Excel. Why would any lay person jump on an obscure technology
doesn't do anything significantly new?

Overall I think there's a problem with assuming that this is for "humans" just
because it's "literate programming". "Humans" don't want all this literate
programming stuff exposed. They just want to push a button and take care of
things. On the other hand, programmers (I guess we should call them "non-
humans") don't need all this literate programming stuff. They are trained to
understand how programming languages work. They may think this is neat at
first, but very soon will start to think all these comments are getting in the
way.

I have personally never seen any programming related technology titled "...
for humans" actually work for "humans". Perhaps because these tend to be built
by extremely talented programmers who are too talented that they are out of
touch with how their grandma uses computers, they probably think their
creations are easy enough for "humans".

Sorry if this sounded too negative. I am willing to discuss and correct my
comments if I am wrong about anything.

~~~
greenshackle2
That's what I was thinking. I'm a human, I like my Vim and C.

The main limitation of a language like that is that, if you care about
performance at all, you have to program for the machine first, not for humans.

You're always writing for both to some extent. For me this is the main
challenge of programming; writing code that executes efficiently and
correctly, and that is legible to humans.

I love Python and other high concept languages but if I want to code for
performance I need to understand what the machine is doing. The tower of
abstraction is so high with these languages, at the end of the day it's easier
to go, eff it, I'll do it in C, than to try to understand exactly how this
code will be executed down at the bottom of the tower.

~~~
cocktailpeanuts
Yup, and even if you don't care much about performance, you still have higher
level languages which are good enough.

That's why I wonder where Eve fits in. Most people don't want to program. And
this is NOT because they're stupid. It's because they have tons of other
important things to worry about. Most people don't want to build their own TV
set. They buy it because their expertise is in other things. Maybe they're a
doctor. Maybe they're a fields medal winning mathematician. Heck, I'm a
programmer and deal with all kinds of programming languages but don't want to
know what's going on inside my TV set.

~~~
lfowles
I haven't looked in depth at Eve, but it sounds like it's a bridge for the
people that _do_ want to program but don't want (or even need) to understand
the underlying complexity. As a close to home example, I've had several game
ideas I've wanted to program for a while. Simple things, I've had notebooks
describing behaviors and what should happen when in the game for years. My day
job is software development, but I haven't been able to grok a game engine
enough to implement playable versions of these games.

In other words, I don't want to build my own TV set but I do want the favorite
channels menu on my TV set to behave slightly differently.... perhaps it has
profiles for each family member. Conceptually simple but hard as hell to
execute from scratch.

------
zenobit256
Sorry, but what about this is "designed for humans"?

What do the keywords mean? What's the language paradigm? Why do I want this
when it's essentially coalescing a lot of APIs into a language that you've
provided no spec for?

Why would I want my language to work with slack?!

I'm not impressed. It just looks like another functional language with a bunch
of addons tacked on to make things "easier" or "for humans".

Drop the buzzwords and get to the meat please.

~~~
thefalcon
As a counterpoint: the example of the document containing blocks of code
inside what looked more like a word document, to me, exactly explains visually
what "designed for humans" means in this context, and I think it's well put.

~~~
mkozlows
That's not revolutionary at all. You can do that already with tons of
environments. Here's one for Javascript, based on Markdown:
[https://github.com/jostylr/litpro](https://github.com/jostylr/litpro)

~~~
oldmanjay
Did someone make a rule that everything needs to be a revolution?

~~~
tempodox
Yes, it's called advertising.

------
delegate
Fantastic work.

The 'story-like' literate programming is the direction in which programming
will (should) move in the future imho.

Visually, you could explore the idea of 'literal-visual' programming (just
invented), something like:

commit [#imageFor #student "student-icon.jpg"]

Then have a button to toggle between rendering records as text and 'visual'
records, in which "[#student ] is replaced with a pictogram. Now you have a
more 'abstract' look at the algorithm - could be interesting.

Similarly, an entire block of code could be switched to 'visual view', which
displays the block as an image, which could be, for example, the screenshot of
the last output it produced.

\---

The Core language is interesting - declarative, functional and dynamically
typed (right?) query language. Some Prolog scent there.

My only concern is that it might be a bit too 'limited' for larger scale
applications ?

But for exploratory data mining, it looks like a great tool.

It seems to be well suited for queries in large scale distributed databases
(like a p2p network) - is my intuition correct ?

If true, then I can see interesting ways in which Eve could be integrated with
ipfs for example and used as a data mining tool...

I enjoy things that create sparks of ideas in my mind, Eve has done that for
me today ;).

~~~
mbrock
"The 'story-like' literate programming is the direction in which programming
will (should) move in the future imho."

Check out Inform 7, too.

~~~
douche
I've tried to get into Inform 7, but I spend more time trying to finesse the
natural-ish language around to get it to do what I want it to do, compared to
the more archaic, C-like Inform 6.

~~~
mbrock
The idea is basically to make the code easy to read despite being hard to
write, which might not be what you want.

I find it a really beautiful system that's super fun to work with. And showing
ordinary people the code is great!

These days I'm working on a kind of interactive documentary about the
collective house where I live and the environment around it. Mini games for
the renovations and firewood gathering and stuff, mazes for the nearby central
market and the home improvement department store, and various random stories
that happened here. It's really fun!

------
andreyk
Very exciting. Feels predictable that there is some push-back from all us
programmers used to 'normal' languages (and the wording on some of this does
not help), but when you think about the language itself and not the 'Medium-
like' IDE I find it genuinely very interesting. The whole threading and
records concepts here are neat...

As always the question is whether it will scale - being so distributed code-
wise seems to imply it will also be hard to trace errors or perhaps at some
point increase confusion. Would this work for giant complicated apps/websites?
Would be nice to see examples/attempts at that.

------
sebastianconcpt
I celebrate trying this. The last time that there was serious attempt at this
was Smalltalk and it had a great impact on the industry. Itself a great
balance of friendly instant feedback and great control. There is also Apple's
Playgrounds now with Swift trying more or less on this. Definitively the
instant feedback is a key component in having the right introduction to
computing. If we extend this idea we'll find that we need this in the debugger
too. It works because is the best way to replace imagination and assumptions
with perceptions.

~~~
zubairq
Actually Apple Playgrounds and SWIFT were inspired by the Eve team's previous
project, Light Table. Chris Lattner, the creator of SWIFT even publicly
acklowledges Light Table as inspiration on his blog:

[http://www.nondot.org/sabre/](http://www.nondot.org/sabre/)

------
alkonaut
This looks a lot excel or Access, but better. Excel is also just a database of
state and a global update "tick". Anyone who is a programmer has probably at
one time or other taken that spreadsheet or Access utility used for task X at
a company and tried to make a "real" application out of it - only to realize
that it takes an enormous amount of time.

This would help with those scenarios. Its perhaps not the best tool for
general programming but it looks promising for creating maintainable data
centric utilities. Instead of all those spreadsheets.

------
SCdF
This looks cool! Always like seeing what idbknox comes up with.

I'm still reading stuff, so apologies if this is answered elsewhere, but what
is the plan / workflow / constraints to handle prose getting out of line with
code? In current software I read / write it's already an issue, I feel like
the more you take out of code and put into prose the more this could become a
challenge.

I'll keep digging and reading, awesome work!

~~~
cmontella
We really take two approaches to this. The first is we're trying to build
tooling to convince you that this is a good idea. For instance, something as
simple as a table of contents generated from headings in your code. It's a
great overview of your program, a convenient form of navigation, and it takes
hardly any time write. I mean, I've seen tons of programmers do this anyway,
with fancy ascii headings. Let's just make stuff like that easy for
programmers, and I think that our propensities to keep things organized and
logical will work in our favor. So in terms of keeping code in sync, we're
hoping these tools will convince you that you want to do it. There is value in
doing it. Not just feel-good value of well documented code, but tangible value
in easily and logically navigable code, for instance.

So the tooling is the first part. The second part is the actual design of the
language. Eve programs are written as a series of code blocks, each one with a
very specific purpose of querying data, and then doing a transformation on
that data. You create computations just by chaining together these
interconnected blocks, each data from another and reshaping it in some way.
It's this design that leads to writing very short, single purpose blocks of
code. In Eve, you don't reference blocks of code, you only reference the data
they create. So blocks don't have names. If you write an Eve program without
writing any prose at all, it will be kind of confusing. We find that our users
so far tend to write a simple declarative sentence before each block,
explaining its purpose. They treat it kind of like an extended function name.

If this becomes convention, you could imagine tooling that actually attempts
to keep code and prose in check, by noting changes in code and a lack of
change in the associated description. Even further down the line, I'm
imagining integrating some of our previous NLP research [1] into the editor.
Imagine if the editor itself could tell you that your code isn't doing what
you think it is.

Anyway, I think the bottom line for me is this: if we're going to get more
people to code, we need to treat programming as a more human-centric endeavor.
What if a programmer and an accountant could write accounting software
together. Not just with the accountant advising the program, but actually
participating in the design and development of the program. Sure, he might not
be able to understand all of your code, but he can read the paragraph you
wrote and see the output of the code underneath, and with his domain expertise
he can understand that the output isn't quite right.

[1]:
[http://incidentalcomplexity.com/2016/06/14/nlqp/](http://incidentalcomplexity.com/2016/06/14/nlqp/)

~~~
SlySherZ
This is interesting. I have one follow up question: If Eve gets smart enough
to understand that the code and the prose diverge from each other, shouldn't
it also be able to generate the correct code from the prose? That way you'd
eliminate the duplication that is happening. It also should allow you to
modify the generated code by modifying either the prose or the code, whatever
the programmer prefers.

------
stungeye
As a programming instructor the Eve demo video gave me goosebumps. The
emphasis on prose+code, world=data, and the discoverability afforded by the
inspector are of particular interest to me.

Our current learning stack for folks with zero coding experience is Scratch
([https://scratch.mit.edu](https://scratch.mit.edu)) to Processing
([https://processing.org](https://processing.org)) to Java.* I'll be watching
the Eve project carefully to see how it might fit into our intro to
programming path.

*If these intro students continue to our full program they learn C#, SQL, PHP & JS/HTML too.

~~~
stevekrouse
Your curricular path sounds similar to the one we use at The Coding Space
([https://thecodingspace.com](https://thecodingspace.com)). Might I suggest
Woof ([http://woofjs.com](http://woofjs.com)) as alternative JavaScript
graphics framework to transition students from Scratch to text based
programming?

------
grok2
Underwhelming so far. Literate programming sounds good, but sometimes it's too
much text and you want to quickly scan a few lines of code and guess what's
going on without reading that wall of text. I wonder if this is for regular
programming or for occasional programmers (non-programmers really) to try
"stuff" out.

~~~
jcheng
Personally I find literate programming helpful not for simple programming
tasks, but for really hard ones; if you can quickly scan a few lines of code
and figure out what's going on, then you probably don't need it. But if it's
the kind of code where I know even future-me is going to have a hard time
understanding what I've implemented without copious comments, then I really
like literate programming.

And it's more than just a different notation for comments. I find it
psychologically elevates the narrative in a way that makes it feel like at
least equal to the code in importance, therefore I end up being a lot more
thoughtful and deliberate in writing the narrative.

~~~
grok2
For code maintenance I've long since given up on assuming the comments are
correct and simply read code and try to understand what is going on (and maybe
read the comments later to see if they correlate to my understanding of the
code). Many times I see that when fixing code, people don't update comments
and a few times I've seen the comment indicates good intentions, but the code
doesn't live up to the intentions :-).

But I do see your point about it for more complex programs and maybe more
complex programs of your own (that a future you will have to maintain).

------
AtroxDev
Wow, I enjoyed the first video in the post way more than expected. Looks very
promising.

------
ar-jan
I've occasionally checked on Eve's progress since I first saw it mentioned
here on Hacker News about two years ago - nice to see all the progress you've
made!

A question regarding the centrality of data: when I first read about this, I
thought an important part would be a kind of user interface for building
relational databases - perhaps something like fieldbook. You mention Eve
already includes a relational query engine - is a UI for modelling tables and
for data entry also on the roadmap?

~~~
cmontella
Yes, this incarnation of Eve isn't what you would take to an end user and
expect them to use it. We have a lot of ideas on this front, mentioned in
milestone 3 of the roadmap on the post. If you take at look at some of our
blog posts on incidentalcomplexity.com, you'll see some of our thinking.

The reason that we are releasing an Eve focused on developers is that we want
something more immediately useful while we research what the right direction
is for the UI.

But before we get there, we could definitely see some tooling for the current
version. You could imagine a grid block that is embedded in the document, for
instance.

------
CGamesPlay
How do you use Eve programs? Are they constrained to a sidebar in the IDE, or
do they compile to something that can be distributed?

~~~
joshuafcole
The application renderer and editor are wholly separate, though for this
release we don't yet provide an end-user way to access the former separately.
With respect to distribution (in the rolling out to users sense), we plan to
start working on that story over the next few months. To get there, we need to
finalize our policy system (which lets you secure your program against
malicious users), improve performance, and get the basis of our horizontal
scaling story in place. If you're interested, keep an eye out for posts about
the world scale computer milestone on our blog!

------
webmaven
A lot of interesting ideas are implemented in this version of Eve, but there
are two goals (both implied and made explicit in various places) for
"programming designed for humans":

\- Make it easier for non-programmers to program

\- Make it easier for programmers to program

While I can see that the current roadmap advances toward both those goals, I
don't see what the Eve team plans to do when those two goals start pulling in
opposite directions.

Will Eve be kept simple and a second UI be created for programmers? Or will
Eve continue to be the programmers' tool, and a second UI be created for non-
programmers in mind?

The alternative of keeping a single tool for both audiences makes me shudder,
as it will literally end up being "code in Word". It is precisely because Word
tries to be all things to all people writing prose that it is such a bloated
mess (granted, it isn't the _only_ reason, but it is a major one).

I'm not even certain whether a UX for non-programmers would just a subset of
the one for programmers, or if there are likely to be features specific to
non-programmers.

------
turingbook
@ibdknox 's blog "Two years of Eve" is useful to understand why of Eve:
[http://www.chris-granger.com/](http://www.chris-granger.com/)

------
dragonwriter
I don't know if it's more or less "for humans" than any other programming
environment, but I think the search/bind/commit model is an important
interesting approach. Given a good enough way to connect new external
resources as Eve databases, I can see that model making Eve incredibly
productive as a high-level glue language.

------
yk
Well, I think this sounds quite good, in fact it sounds so good that it is
probably not true. And reading to the page, I stumble over the sentence

> An IDE like Medium, not Vim

Thing is, vim is not complicated because of some misplaced elitism, vim is
complicated because it helps with complicated problems. (I am a zealot for the
church of Emacs, when I say something "nice" about vim, it is because honesty
or pointy objects force me.)

Unfortunately it goes downhill from there, it is nice that there is a way to
visualize memory in five lines of code, but what about the memory of the
following three processes (and the one thread in red and the others in some
other color?) In my experience, there is a trade off between the power of a
language and the impressiveness of the examples. (A better example would
probably be the twitter api, does that mean I need to beg the core developers
to talk to the next "slack for dogs" api?)

Then there is the "zoom" feature, I have not the slightest idea what that is
supposed to mean. (Actually I have, I just don't think that this side of a
strong AI coworker it is possible to hide information in any useful way.
(Hiding information is just the inverse of zoom.)

And to top it of, there is a link to the demo and the first thing I notice is,
scrolling is broken. (Arch, Firefox, NoScript with in this case all JS sources
allowed) Well, the first thing a IDE should allow me to do is to display text
in the most reliable way possible, even if that means more than one page.
(Plus it is in a browser, which may or may not be only for demonstration
purposes, but at the very least the browser uses the right mouse button to
display browsery options not IDE options.)

After having fired up chromium, there the IDE works and it actually works kind
of well. To keep with the overall negative tone of the comment, almost as good
as Jupyter. The first thing I notice, is that one can switch code blocks on
and off, but the output depends non linearly on the set of switched on code
blocks. For this one would likely need some kind of toggles for sets of code
blocks if it should be usable at all. (So to switch on extra test cases, or to
test only one part of the program, etc.)

In conclusion, it is a nice project and I wish the devs all the best.
Hopefully one of these days someone manages to get literate programming to
work. But I think that there are quite a few things which make me doupt that
this is, what makes literate programming work in the end.

------
famerr
I'm sorry guys, I see you made a great work. But until it goes to visual
programming kind of things it will look like SQL-like language, which I like
btw. But visual would be a really next step keep on with those things. And
world-like document is really a great idea. Thank you.

------
leke
The syntax reminds me of a language I played with many years ago called REBOL.
Even some of the terminology is the same, like a "block".

------
psiclops
Reminds me of luna language [0], a functional language that allows you to
write code with text or a UI. I saw two of the creators present this at a GDG
event in SF

[0] [http://www.luna-lang.org/](http://www.luna-lang.org/)

------
hinkley
The first question I always ask, and often the most deadly:

How do you handle version control, and merge conflicts?

If you don't have that figured out, none of the rest of this matters. Because
a programming language designed for one developer isn't designed for building
software.

~~~
hacker_9
What exactly is going to be the problem when all version control systems do is
merge based on text differences? Also the block separation here could actually
be used semantically and provide _better_ merging than for existing languages.

~~~
hinkley
I said handling merge conflicts, not handling merges.

The ergonomic presentation of a three way merges is not a solved problem in
text-based programming languages, but you have to have something if you want
more than one developer working on a single project.

------
oelmekki
I love the radical shift around documentation that is played on, here. I won't
switch from my usual languages to use Eve, obviously, but there are super
interesting ideas in it, I will watch it closely.

Did you consider any niche market where it could actually become the main
tool? Education come in mind first, but I'm not sure it would be a good
"introduction to programming", given how different it's from, well, all other
languages. Maybe it could be good in art classes, though, helping kids to
build digital and interactive creations, and even write a story around need,
through the documentation centric approach.

------
petermcd
Some great approaches here!

I like the medium-like bar on the left to browse blocks. Checking the boxes
next to the blocks you want to show is a neat way to make a view of just the
functions you want to look at. Putting it in a browser, like iPython/Jupyter
improves accessibility for people whose main job is not developing software
(the Eve demo makes a good example of being able to pass an analytics view to
a teammate in marketing).

I do find myself wondering how a literate programming system like this would
scale for a large project (I expect the Eve team have thought about this more
than I can imagine).

Great polish on the demo, too :)

------
dancek
While this is a very early version, something like it will eventually put most
programmers out of work. Probably it'll be another language/tool and it won't
be very soon, but at some point writing trivial software will actually be
trivial.

It's ironic, being a programmer that automates things that people used to do
manually, and kind of doing good but leaving someone unemployed. How fitting
it will be to suddenly become mostly obsolete as a profession, due to
programming being very easy or even done by AI. Dogfooding, anyone?

~~~
hacker_9
If we create an AI that can write software, no one in _any_ profession will
ever need to work again. So far all this has shown is it can places buttons on
a form. Try building a path finding algorithm with it, that is actually
performant enough to run inside a 60fps game engine across open terrain, and I
think you'll find C++ isn't going anywhere yet.

~~~
wruza
Probably except the world's oldest profession

------
d--b
A few comments.

1\. Black box

By hiding away the complexities of schema design and information indexing, Eve
cannot be accepted as a proper framework for any professional project. As soon
as performance starts to be a problem, there is nothing one can do to help. In
the same vein, not having local variables means there is a whole lot of small
things you can't do. Doing flappy bird is one thing, I doubt you can make a
fast Tetris with this. Rotating pieces will be a nightmare. I mean, even in
Eve, you HAD to add "functions" like cosine and sine, just for your demos. If
you can't define these functions, you kind of proved that Eve was
incomplete...

2\. For humans?

I personally don't think that eve makes it particularly easier for human to
program. I mean, this is a type of programming that is not new. You can do
eve-like programs in any language easily. In c#, you can do an Eve engine with
1 big list of dynamically typed records and Linq queries on it. Yet, it's not
the way people like to program. The only real world example that I can think
of is D3, which in many ways shares the eve search / apply / bind model. And
D3 is pretty great, but many people have found it hard to grasp, and it is
likely that the limitation of the approach are ok when dealing with graphics,
and much less so when deal with general purpose programming language.

------
cperkins
This is very exciting. The growth from Eve 0 to Eve 0.2 is remarkable - it's
clear you have not been afraid of starting over as you've made realizations.

------
kybernetikos
I absolutely loved the semantic wiki stuff that was shown towards the end of
the "In search of tomorrow" video. This seems fairly different to that system.
Is there a write up/talk about why you changed? Is there anything like that
semantic wiki thing available for me to use?

[https://youtu.be/VZQoAKJPbh8?t=46m20s](https://youtu.be/VZQoAKJPbh8?t=46m20s)

~~~
erikpukinskis
Yeah, in all of the demos they've put out, that's the one I think they could
slap a domain name on and end up with something as big and useful as
wikipedia. Just the documents and the query language and the "cards" or
whatever.

I guess Eve is their prototype of the back end for that?

------
partycoder
I think the best way to introduce a new concept to someone is to do it in
terms of something the person is already familiar with.

You can introduce programming by making an analogy with a cooking recipe,
where you have ingredients (input), and a desired output (whatever the recipe
is for). The recipe would process the input and through a sequence of defined
steps, turn it into the output.

The average human is familiar with the concept of cooking to some extent so we
can say that analogy would work "for humans".

This, in contrast, fast-forwards directly into some concepts like functions,
how to evaluate functions, etc... and that's where I stopped reading. This is
not "for humans". Might be a viable language, sure. But let's be objective,
leave superlatives and weird claims aside.

------
clintons
From first look, looks like rubyish types of languages. Maybe it strikes a
cord with someone else.

After 15 years I've learned to hate languages like these for building anything
slightly complex.

However...

The great thing about all these languages is there's choice for everyone.
There are as many pet peeves and ways of thinking as there are developers.
There is a language for (almost) every type of case needed.

So use whatever the hell makes you love programming the most (or hate it the
least), gets the job done right and makes your business(or employer) money or
does something helpful for your users.

I might like like the flavor you like but, you might not like mine either. And
guess what, we might both be totally right about the requirements met by the
languages we use for our own work.

~~~
continuational
There's no connection to Ruby here, it's based on logic programming.

------
empath75
How would you interact with a rest api with this?

~~~
zubairq
yes this is something I'd like to know too. Maybe check here:

[http://play.witheve.com/#/examples/http.eve](http://play.witheve.com/#/examples/http.eve)

------
OOPMan
Looking at the examples, it seems like Eve is really just a DSL for performing
a number of common preset interactions within the web browser.

Maybe I missed something but it doesn't seem like this is really designed for
usage outside the browser environment?

As such it seems like this is really just a very high-level layer on top of JS
rather than a general-purpose programming language, a lot like Jupyter
Notebook and friends.

I guess the biggest challenge Eve faces is the same one faced by all those
other 5GL "languages" that are now rotting at the bottom of a dumpster: How do
you become relevant beyond a tiny niche problem space?

~~~
_halgari
Exactly my thoughts. Every DSL needs an escape hatch at some point. What do I
do when EVE isn't fast enough or lacks some feature I need.

------
smaddox
Any attempt to re-imagine programming is refreshing, but it's unclear to me if
this is more than a domain specific language (DSL). Is it possible to
implement, for example, the bar graph from lower primitives?

~~~
cmontella
Yes, you can actually see where the bar graph is implemented here:
[http://play.witheve.com/#/examples/view.eve](http://play.witheve.com/#/examples/view.eve)

You can build charts like this in svg or html right now. Basically, in Eve we
are just generating the records necessary to render these views. We have a
separate process that's tied to the browser that takes these records and turns
them into something the browser can understand. So Eve isn't tied to html; if
you write your own translation layer (and we will have many more by default in
the future) then Eve can generate whatever you want.

------
thallukrish
I feel to make programming easier, we need a assistant (intelligent in
whatever sense you call it :-) that can figure out the 'intent' of the code by
reading it and be able to point out bugs by learning from millions of source
code in Github.

I wrote in this article

[https://medium.com/@thallukrish/debug-
assistant-2aa37ac13ca5...](https://medium.com/@thallukrish/debug-
assistant-2aa37ac13ca5#.qzgchnsw0)

------
zwischenzug
I'm pretty sure 'effect' in the first doc is grammatically incorrect. Either
way, the ambiguity confused me. Not a great sign for such a language.

------
gnud
This looks interesting! But it terrifies me how you seem to be programming
against the production app/database in the video.

I get that this is the early days of the project, but I would love to see some
information about how your program is actually stored/compiled, how you can
version control and deploy it, and how you can interact with files/databases
outside the 'eve' universe.

------
squar1sm
Anything that increases feedback and visualization is great. It's not about
the storage of the code it's about the communication paths between the
programmer and the computer and making that higher bandwidth and quick turn-
around. I love what I see with saving the session (lisp state) and replaying
it.

If not this, then this idea. Or this idea with more time and features.
Impressive already.

------
tehwalrus
This reminds me a lot of the ipython notebook.

I still think Python is a programming language well suited to humans: I'm not
sure I want to try to understand (and hold in my head while debugging) how
seventeen disjoint blocks of code interact in an event driven UI like in the
messaging app example, clever highlighting/jumping or no.

------
onetwotree
> From a technical standpoint, Eve is a variant of Datalog

This is what I needed to understand what you're up to here, oddly enough.

From
[http://programming.witheve.com/deepdives/whateveis.html](http://programming.witheve.com/deepdives/whateveis.html)
(which might not be up to date?).

------
eternalban
Reminded me of Wolfram's Mathematica.

------
zubairq
Here is the link to play with Eve in case you can't find the link:

[http://play.witheve.com/#/examples/quickstart.eve](http://play.witheve.com/#/examples/quickstart.eve)

------
FraserGreenlee
If this takes of it will create an awesome dataset for a description to code
ai!

------
theideasmith
I saw this a while ago too: [http://unisonweb.org/2015-05-07/about.html#post-
start](http://unisonweb.org/2015-05-07/about.html#post-start)

------
aikah
Meh, looks like Redlang, Rebol and co. In practice these kind of languages
lead to easy to write/hard to read codebases due to the lack of visual cues
and structure. But the IDE is nice though.

------
Thomasdah
I really like this project. It is based on principles i can get behind.

Since this is a web based programming language - i really would like to know
how to interop with JavaScript.

In my case i need to use the pixi.js renderer

------
zindlerb
Looks really cool! I'm excited to test out a few programs.

------
n_mca
This looks cool, but can somebody point me towards the details? As in, I'm a
semantics / pl-theory person and want to know wtf is going on...

~~~
cmontella
We will be publishing more docs about the inner workings of the language in
the coming weeks... There was just so much to do here and we wanted to get
things out the door. The short explanation is Eve is a datalog variant. If you
are really interested, you can read some of our blog posts to get more of an
idea: Www.incidentalcomplexity.com

------
taneq
This smells like a game maker app, in the sense that it's hiding "all that
messy coding stuff" behind "a simple friendly interface."

Programming isn't about syntax. It's about telling the computer _exactly_ what
you want it to do, in every possible situation. The hard part isn't the
language you use to tell the computer what to do. The hard part is making sure
the instructions you're giving match what you want to happen.

I'm not saying it's impossible, but every time I've encountered something
that's meant to 'make programming easier', once you get beyond 'hello world'
all it does is get in the way. You still have to communicate the same amount
of information to the computer, but now you're doing it with duplo blocks
instead of a milling machine.

~~~
joshuafcole
Hey Taneq, The fear of over-simplification is totally reasonable. Programs
like Game Maker certainly gain their shallow learning curves at the expense of
overall power, precision, and depth. We don’t think that tradeoff is
acceptable either. Luckily, there is a difference between architectural
simplicity and “kid-friendliness”. That’s a big part of why we had to start
from scratch and build a new language -- we needed something that was simple
from its core if we wanted to make it simple to use without losing
expressibility. Rather than rehash the specifics of our architectural
decisions (though I encourage you to check out the blog and the upcoming deep
dives if you’re interested!) let me describe briefly some problems I don’t
have to deal with anymore when I use Eve.

\- Asynchrony is pain-free (no imposed cost, no alternative syntaxes, no
callback hell).

\- Programs are live by default -- there’s no need manually listen for changes
all over the place, and no falling out of sync.

\- Programs are easily extensible -- because of the above, anything that
conforms to the pattern for a block will get picked up by that block.

\- Mocks, shims, and other injection patterns are free -- making testing and
experimenting very easy.

\- Refactoring is trivial -- If a block changes, I only ever need to change
its immediate downstream users to get back to a working state. Eve can find
those for me.

\- _Everything_ is data, so state sharing is trivial. When a coworker finds a
bug in my code they can save their exact state and send it to me with a single
command.

\- The number of classes of bug are drastically reduced. This doesn’t mean
they aren’t occasionally perplexing, but because there are so few ways for a
program to fail, I can literally run through a checklist of possibilities
while debugging. This is the premise that powers the inspector.

This certainly isn’t a complete list, but it’s a few of my favorite quality of
life improvements that I think sets this project apart. If you do get the
chance to use it, I’d love to hear your thoughts on what works and what
doesn’t for you.

------
pmontra
A suggestion to the designer of the language: do whatever it takes to get rid
of those square brackets. They don't belong to a language for humans, not in
that quantity. As a bonus, remove also @ and #.

All the rest looks good. Hopefully it will influence other languages to
display their inner workings in a more visual way, maybe even the mainstream
ones.

------
edem
LightTable was not updated for a year now. I actually backed it and now the
IDE seems abandoned never to reach 1.0. I've lost trust in the developers and
I won't recommend Eve to anyone because of the fear that they will abandon it
as well and start chasing the next big dream.

~~~
pluma
Just for context: 0.8.0 and 0.7.0 were both release near the end of the year
with one year between them[0] (2015 and 2014 respectively). If there is a
0.9.0 coming up I'd expect it in late November or December this year,
accordingly.

However there has been barely any progress[1] on the GitHub repo since
February (compared to the previous years), the last commit was 20 days ago and
even before that there were typically several days in between commits. So it's
fair to say the IDE _seems_ abandoned.

However, the LightTable devs have stated that they see Eve as the logical
continuation of the idea behind LightTable[2]. While the promise that
"LightTable will continue to go on strong" seems to be the typical startup
pivot lie I don't think their behaviour is quite as erratic as you make it
seem.

By the way, I'm also a Kickstarter backer and I have the shirt to prove it. I
was hoping for a nicer JavaScript IDE and would have been very satisfied with
their original promise but I can see the appeal of going a step further. The
move from LT to Eve feels a lot like a bait and switch to those who just
wanted a better IDE for the languages they currently get to work with.

[0]: [http://lighttable.com/blog/](http://lighttable.com/blog/)

[1]:
[https://github.com/LightTable/LightTable/graphs/contributors...](https://github.com/LightTable/LightTable/graphs/contributors?from=2016-01-31&to=2016-10-29&type=c)

[2]: [http://www.chris-granger.com/2014/10/01/beyond-light-
table/](http://www.chris-granger.com/2014/10/01/beyond-light-table/)

------
Edmond
Love it.

------
jlebrech
can this be adapted for touch?

------
jlebrech
i see the first problem is that you're generating HTML

------
superninja234
If I copy and paste ruby code in to a word doc, can I program like a human
too?

~~~
sctb
Please comment civilly and substantively on HN or not at all.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

------
miloshadzic
This "for humans" shit has to stop.

------
dboreham
Someone needs to be given a lollipop?

------
soared
>Target market is not programs

>Only place to try it out is on github

Github is the most terrifying place on the internet for 90% of users (non-
developers). I cannot stand when a project is trying to market to regular
users but hosts any content on github. I get that this is an early alpha, but
come on..

------
tomc1985
Replace "for humans" with "for stupid humans" and you get to the truth

How selfish is it that everything has to be "for humans" anyway? Why can't it
just be? Let's not further complicate already-complicated abstractions.

