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)
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.
Eve is a nicely engineered environment and has basic relational semantics that many streaming query frammeworks and dataflow frameworks have in mind (select with aggregation, update)
But the site doesn't have any discussion of the language's semantics. I know they have mentioned Bloom (bloom-lang.org) as one of their influences. I would like to know how the Eve evaluator handles negation (and what negation means in an Eve context), whether there is a guarantee that a single tick's evaluation will terminate, whether the evaluation is incremental, and whether in doing so, the results are equivalent to a simple evaluator that does not work incrementally (looks at the entire database every time).
etc.
Prolog itself has many issues, many of them rooted in its somewhat unrestricted use of terms. The nice thing about datalog is that it has very nice strong normalization as a natural property of term evaluation. While it's true that it doesn't do everything, this combined with controlled dataflow has long been an interesting area of PL research.
Eve is definitely not the first to have realized this but it's attention to making it fit in with modernized ideas around interactive computing are noteworthy. The translation of a lot of these ideas into this context requires a lot of careful thought so I wouldn't trivialize it as a lesser version of something.
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.
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?
> 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.
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
? 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".
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:
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.
Did you guys notice that both of your examples use sigils?
Try Avail[1]:
allChecked = select element from todos list where [element is completed]
allNotChecked = select element from todos list where [element is not completed]
todoCount = count of element in todos list where [element is completed]
I'm cheating a tiny little bit: `todos list` would probably need to be defined above as a method (I don't remember if one can have variable names with a space inside the name in Avail) and `_is completed`/`_is not completed` would also need to be defined.
Rebol or Red could be also interesting in this regard, also Forth and Factor. Still, Avail goes the farthest in terms of allowing you to write a truly human-readable code (EDIT: however, they support all of Unicode for names and such, so you can go nuts with sigils too, if you want).
(Possibly also Inform 7[2], but I don't know it, so can't really say much.)
> Did you guys notice that both of your examples use sigils?
As the person that initially mentioned sigils, I did not say that they are always evil. I just said that you cannot use them and at the same time claim that you have a human-centered fully intuitive programming language.
I'm very fine with using -> symbols for anonymous functions... In fact, I'm fine with other sigils as well, if they are explained properly.
> allChecked = select element from todos list where [element is completed]
To me, knowing nothing about this language, this reads like collecting the subset of the completed elements out of all the elements. But the original task was to compute whether all elements are completed, i.e., whether this subset is equal to the whole. So you're doing something else, or your language is misleading me.
Of course not; but they are not human-readable. I thought that the posters above me used Ruby and C# examples to say that they (Ruby and C#) may be human-readable. I'm not sure if that was the intention, so I just noted that -> and &: are also sigils.
> So you're doing something else, or your language is misleading me.
It's the former! However, it's what the two posters before me did in Ruby and C#. The fact that all three of us misinterpreted the Eve code is interesting in the context of this discussion...
Correct Avail code would look like this:
areAllEntriesChecked ::= (count of element in todos where [element is checked])→boolean
Anyway, that's not "my language" at all, I just happen to know quite a bit of strange languages and wanted to share info on one with an interesting take on readability. They call it "articulate programming", which seems to be an evolution of Knuth's literate programming.
maybe I should have said supposed to be human readable. I share your sentiment. I saw a comment on here once justifying that claim by saying something along the lines of "but if you look at the text and ignore the symbols you get the gist", which is not the original promise of Eve in my opinion [0]
I just wanted to respond to your comment, even though I see you posted later in this thread that you re-read Chris' post in a different light.
In developing Eve, we faced a problem of getting involved in too many research projects. How do you make a new language and a new interface to that language at the same time? It was very hard, and in the end we realized it was a mistake to take this route. For instance, how do you version control and make unit tests for a card wiki UI?
Instead, we are developing the language first, getting that to a point where it's stable, well defined, and actually used by people. In order to do this, we needed an interface that was also well understood and defined, and the only choice there really is a textual syntax. This has several benefits:
1: we know how to make a textual interface. We've made many, and there really aren't too many questions there.
2: people know how to use textual interfaces and there are tons of tools out there to work with them
3: developers in particular, the people who will be using our language first, are comfortable with textual interfaces
4: we can still provide some innovation here, and make Eve exciting to work with for the people who want to use it this way.
The obvious drawback is that we're not making a huge leap in programming interfaces this way. But that's okay, since we're making progress in another direction that really is a prerequisite to bringing computation to everyone. When Eve the platform is better understood, we'll tackle the even bigger hurdle of an interface that appeals to more than just developers.
Its less the direction changing than the plan for how to get there. The major pieces to the roadmap is now:
1. Eve: Programming designed for humans (current)
2. Eve: Computation for all
3. Eve: The world scale computer
http://www.chris-granger.com/2016/07/21/two-years-of-eve/
has some information on why. Selected quotes:
"We learned with Light Table that we can't just slap a UI onto Javascript and expect it to work; the platform has to allow for the representation."
"Another reason the platform is necessary is really counterintuitive: we need developers to like it before end users will. Technology diffuses from technical people to non-technical people over time."
Thanks for this. I've read that post before, and back then I just took the explanation to mean we're dropping the UI. I can see now that was not the meaning.
> we need developers to like it before end users will
While I can see how there is some separation of concerns as mentioned in that post, I think the above quote doesn't have to be true in order for Eve to succeed. It has the potential to contradict the whole programming designed for humans line. Developers can be quite happy with some pretty funky syntax/abstractions which won't seem remotely obvious/intuitive to non-programmers. If developers' considerations are put before non-programmers, Eve might end up a language for developers, as opposed to the intended audience. Personally I think that means that you can't drop the UI even for now. It has to be the only interface. Otherwise you won't get the interest from non-programmers. What developers might like and grok, non-developers might not.
Just one data point from somebody interested in this sort of thing.
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".
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.
> 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.
Fine, but why without overhead? You're not addressing that. Why can't it unify the stack while making things slightly less efficient? It's not as though all of the things we need to do as programmers are constrained by computation resources.
It depends what is meant by "unify" and what is the "stack". What I just read that a language is meant to "unify the full stack", I think I'll be able to rewrite with it any piece of the stack used, including my graphic driver, the network stack, etc.
I believe most modern application are relying on underlying elements of "the stack" that need to be fast/low latency enough when interacting with each other. Unfortunately the C ABI is still king there...
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.
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.
My startup 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.
> 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.
Is that true though? To me, the difference between a simple spreadsheet and say, a floppy bird, is that the spreadsheet requires one to know about rows and columns, and basic math (sum, average). It's a pretty simple abstraction that matches, say, a sheet of paper with a list scribbled on it.
Whereas, say, flappy bird, requires you to think about a lot of other abstractions one is less familiar with, and juggle those. User input, graphics. I think it's the complexity of abstraction and the difficulty of reasoning about it and juggling all the bits in your head, that makes it hard. I think that's a skill you really have to have or learn. Just because some people van add two cells doesn't mean they can easily create their own abstractions f.ex
search
a = [#singleton]
b = [#singleton]
a != b
commit @error
[#error #description: "Multiple values for singleton!"]
I'm sure that's not the actual pattern you'll be using. My point is only that Eve provides a solid low-level foundation to implement higher-level patterns like a single-value type.
"My point is only that Eve provides a solid low-level foundation to implement higher-level patterns like a single-value type."
That's the problem. As long as single-value type is a higher level abstraction you are going in the opposite direction from "programming for everyone".
You're always working with an abstract/fuzzy value that represents all possible values given some constraints, and only have to resolve a concrete instance when you absolutely need to. More often than not, were working with ordered sets, not single elements.
Yes. I'm with the idea of a relational language, and I "discover" the same idea. In most languages,the scalar is the default and the collection is the special case. However, more often than not, you want to operate in collections than scalar.
So, I have find that this kind of code make sense:
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.
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.
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 ?
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.
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.
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?
My point wasn't that it is a synonym for mobile. I just think there are much more web devs than regular ones AND that most of the mobile devs do (or did) web-dev (before).
And for web, not every business out there is sold to it, thankfully.
There are tons of companies on this planet that only use the web for putting their contact details and that's it, many of which actually use FB for it. All their internal software is desktop based.
Eve aims to be a general purpose language [1] to really replace your "entire programming stack" except for high performance, real-time applications. So, don't be sad :)
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.
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? :)
Example apps are great. But what those example apps are, and what they mean, can vary a lot. Some things that would help, for me:
- Exhaustive inline documentation. Like, consider literate-programming as a model. I want to see thoughts, observations, etc. as I read through the code. I want to know how you think somebody should be thinking. I want notes around "well, because of the way the stdlib works this is O(n^3) when it could be O(n^2), but it's okay for our values of n, we can come back to this." Show me not just what's good, but what kinda isn't but is made up for by other stuff being awesome. Show me where the bodies are buried. Because otherwise, sticking to stacks where I already know and can risk-assess against is a better use of my time.
- Deployment advice. This doesn't mean "throw it in a Docker container", because that's not showing a grasp of the tools around you, but rather, say, open-ended integration with AWS, or Google, or whatever. Show me best practices for configuring it, as I already can see with Rails. And, as above, explain the thinking, explain the value of it, discuss alternatives and why you didn't go that route.
Ultimately, I want to see that whatever tools that I would move to next (I use Ruby for devops-type tasks and Dropwizard for the web) to demonstrate that the developers are intensely thoughtful about the people using their systems, rather than just technology.
I would be interested in any application that crosses many layers. If you create an IoT device you need:
+ bootloader
+ radio stack
+ HAL
+ custom code layer, say Arduino
+ communication layer
+ mesh hub (+ mesh communication layer)
+ sink code on mobile (bridge, no access to encrypted data)
+ local communication on mobile (low latency)
+ cloud
+ remote access
+ interfaces, mobile/dashboards
It has also a lot of crosscutting concerns: latency, scalability (keep it local stupid), bandwidth, security, safety. Till out in the field: how to remotely define if it is hardware or software to reduce number of devices that gets returned.
That's a good example that shows the capability, but complete apps like that have been built with scheme, haskell, lisp, prolog, smalltalk, etc. I think what the original poster is asking tho they most likely won't admit it, is for a runaway profitable app. Once you have an app built with this that get's popular with millions of users or makes tons of money then people take it serious. The app you plan on throwing together is more than enough. If this works as has been written, it would become the secret weapon of the smart programmers.
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.
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.
"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....
> 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.
Yes, I agree with this 100%, and this is one of the main goals for Eve, much further down the line (see some of our experiments with graphical interfaces to Eve: https://github.com/witheve/eve-experiments)
But even today we're focused on making programs easier to read and modify. Let's say a food truck owner (with a little technical experience) does download our app written in Eve, and wants to modify a button.
When he opens the program, he can see a table of contents, and code written in a literate programming style. So immediately there's a place to start.
The user could read through the document and try to find the place where the button is drawn, but the program is running right there. The user can inspect the button in question, and the editor will point right to the code that draws it.
The user can modify the code right there, and see changes to the app immediately. This workflow is similar to what we demoed in this video: https://www.youtube.com/watch?v=TWAMr72VaaU
Obviously given the current form of Eve, this scenario requires a food truck owner who is also a developer. But supporting simple workflows that make using a computer easier is central to what we're trying to do with this language.
Not sure why I was flagged. Any ideas? Seems excessively narrow minded on the part of those who did the flagging.
Anyways... I see there is a tier missing between the consumer of such model and Eve. That tier is of the Assemblers (a light version of the traditional "Developer") who will take requirements to modify an Eve app to the liking of the given consumer. They (the Assembler)( could also put out different versions of the app that fit the most requested use cases.
I think the thing that the Eve developers are missing (from their mental model) is that the "essential complexity" of a given task is irreducible and is often more than someone who is not an algorithmic thinker can handle. This is different than the "incidental complexity" which Eve might reduce greatly.
Do you think that, generally, if someone needs an app to do something they've just thought of, that there should exist some way for them to build it themselves? If not, why not?
We will know the age of "personal computing" has truly arrived when such things are possible. At the moment, our hypothetical food truck owner (and many, many more people I know personally) are at the mercy of others, frustrated and unable to achieve their computing goals unaided.
I probably did a poor job explaining, but that's what the example is: an app that a food truck owner could use to run their food truck. :)
> There must be a better range of use cases.
There are lots of businesses I'm sure we could build, but that's not really our goal. This one happens to be straightforward and real, so it seemed decent. Do you have any suggestions that you think would make for a better demonstration?
Analyzing logs seems like a great demo, since the app largely needs to give people the ability to work with data - so the data oriented parts of Eve should have an excellent opportunity to stand out.
Author here. I certainly understand that seeing progressively more sophisticated practical applications will help people "get" Eve. I look forward to that myself.
In the meantime, I hope I can show a "plausibility argument" for Eve's potential by pointing to areas where the status quo of mainstream programming is visibly less than ideal. Uniformity of data formats and operations across the programming stack is one such area.
This article got me curious about eve. Now i think you need to find your "killer use case".
Ror had none, because it was doing what everything else was doing, just faster. But a successful business used it so people got interested.
Node.js first demonstrated chat server
Angular.js showed two way binding of dom to data using declarative syntax
React had those crazy dom update benchmark.
Golang showed various pattern for synchronizing using channels. The "hello world" of go was a chat server.
Etc.. now all those tech had many other great feature. But you need to find one single killer concrete example for the tech, that it performs an order of magnitude better / simpler / faster / safer than any other.
Also, never ever forget runtime speed benchmark. You don't need to be the best, just not catastrophicaly bad.
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.
