Hacker News new | ask | show | jobs
by 0x01 3499 days ago
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?

4 comments

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

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

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

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

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

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

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

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

  all-checked = [#todo completed: true]
would match each of the records with both topic: 'todo' and completed: true. And the following commit block would once per matching record. But what is desired here is one value for all the matching records (an "aggregate" in Eve lingo).

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

  all-checked = all[#todo completed: true]
  none-checked = none[#todo completed: true]
  todo-count = count[given: [#todo completed: false], default: 0]
Disclaimer: I'm just an Eve user/contributor
Thinking about it, it is possible that this proposal would not work, because in the nothing-matches cases then the function would not be executed at all... But maybe this could work, by widening the matching pattern.

  all-checked = all[in: [#todo], where: [completed: true] ]
  none-checked = none[in: [#todo], where: [completed: true] ]
  todo-count = count[in: [#todo], where: [completed: false], default: 0]
Yeah that's awful. In Ruby it'd be like:

  all_checked = todo.select(&:completed?)
  none_checked = todo.reject(&:completed?)
  todo_count = todo.count(&:completed?)
In C#

  var allChecked = todos.All(todo -> todo.IsCompleted);
  var noneChecked = todos.None(todo -> todo.IsCompleted);
  var todoCount = todos.Count(todo -> todo.IsCompleted);
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.)

[1] http://www.availlang.org/ [2] http://inform7.com/

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

> I did not say that they are always evil.

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.
Yeah, this is my big complaint. It almost seems like it's less understandable to make the whole literate programming bit relevant.

Imo, literate programming should be solved by more expressive languages, not prose commentary layered on top.

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]

Edit: found the source: [0] https://news.ycombinator.com/item?id=12819973

#todo is shorthand for [ tag: 'todo' ]. A record can have multiple tags. Agreed that there should be a full-form for database, not just @.
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.

It should not take you more than 1h to learn Eve...