How Eve unifies your entire programming stack
hackernoon.com
hackernoon.com
I mean, you can throw HTML around cobol/io/cl/sql/sed with the same wow-effect?
Also please let me know what you think about Part II (coming later this week). It's all about logic programming and CQRS.
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.
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.
... and synchronous programming. Eve is a synchronous relational (or logic) language.
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.
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?
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."
> 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.
I wonder why people say/think that. The language uses sigils like @ and #. Sigils automatically make a language non-"human readable" since they have no "human meaning". And no, "you just have to learn the meaning of the language constructs and then you can read it" is not "human readable" in a useful sense. From what I gather, in Eve the @ sign refers to databases. That's fine, but "database foo" is human readable in a sense that "@foo" certainly isn't.
Or look at this example from http://play.witheve.com/#/examples/todomvc.eve
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
all-checked = [#todo completed: true]
none-checked = [#todo completed: false]
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".
all_checked = todo.select(&:completed?)
none_checked = todo.reject(&:completed?)
todo_count = todo.count(&:completed?) var allChecked = todos.All(todo -> todo.IsCompleted);
var noneChecked = todos.None(todo -> todo.IsCompleted);
var todoCount = todos.Count(todo -> todo.IsCompleted);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]
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.)
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
Ha! You seem to be right about the Ruby, I missed that too. The C# looks correct to me, though: https://msdn.microsoft.com/en-us/library/bb548541(v=vs.110)....
all-checked = [#todo completed: true]
Personally I think we would be much better off with a dedicated aggregate function instead of using if/else here. And count (which is an aggregate function), should have a default value for when no records match. Then could get rid of the if/else there also, and have something like:
all-checked = all[#todo completed: true]
none-checked = none[#todo completed: true]
todo-count = count[given: [#todo completed: false], default: 0]
all-checked = all[in: [#todo], where: [completed: true] ]
none-checked = none[in: [#todo], where: [completed: true] ]
todo-count = count[in: [#todo], where: [completed: false], default: 0]Edit: found the source: [0] https://news.ycombinator.com/item?id=12819973
Imo, literate programming should be solved by more expressive languages, not prose commentary layered on top.
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.
If it can't, then "your entire programming stack" is excluding the kernel and a lot of existing libraries/code.
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".
</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.
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.
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.
But SQL is very successful so maybe they'll do okay anyway.
search
a = [#singleton]
b = [#singleton]
a != b
commit @error
[#error #description: "Multiple values for singleton!"]
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".
Eve : Markdown :: Eve-based tools for everyone : a WYSIWYG editor
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.
So, I have find that this kind of code make sense:
for i in 1:
print i
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.
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.
Not in my experience.
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
I'm looking forward to compatibility with semantic Web technologies.
I feel sad when I find that web programmers think there are only web stacks and "programming" refers only to web programming.
It is not entirely the case here, but the description of "a core system" as :
- Database layer
- Remote API layer
- Application layer
made me tick.
Never say never.
I mean even most of the mobile people were web devs once...
Native UI isn't a synonym for mobiles.
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).
Web and mobile are driving the bulk of development these days, so development terms are going to reflect the concentration on Web and mobile.
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.
What makes you think that? Most native UI developers I know have never been web devs.
Did you have a specific alternate "core system" you'd prefer I had written about?
That's in the PR pipeline right now, you can track it here: https://github.com/witheve/Eve/pull/571
Although I should mention, Eve is super early Alpha right now, so don't deploy anything you will be depending on!
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? :)
> 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?
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.
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.
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.
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....
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 don't think anyone denies they've brought tremendous value to professionals in need of some ad hoc programs.
- 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.
HTH.
Europeans. Please add a Döner- or Würstel- stand model.
+ 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.
It's non trivial, and the whole program is available in book form as a literate program.
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.
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.
...and then abandoned it after getting me excited about a possible Emacs replacement...
> 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.