[jimbokun]

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

Non-programmer: OK, Eve sounds great, so, I want to search for a Slack message. How would I do that?

Eve-programmer: Obviously, it's just:

    search @slack
       [#message from body]

Non-programmer: Ummm...OK, great. So now if I wanted to, say, send an email.

Eve-programmer: Easy! In the same way, you just:

    commit @email
      [#email to: "[e-mail]"
              subject: "It's party time!"
              body: "Hey Corey, the party starts this Friday."]

Non-programmer: ...

The challenge of programming has always been wrapping your head around very formal abstractions and "thinking like the machine". These Eve snippets still look very much like a programming language to me. I don't think they will mean anything to a non-Eve-programmer without training in the semantics of how Eve programs work and the syntax of how to build the expressions, and the model over which the operate.

Eve very well may be a big productivity advance over current development environments, but I don't see it eliminating programming as a profession anytime soon.

[ibdknox]

This milestone is very much about making a programming environment, so you're right, that's still code. Though to address this strawman, compare that to what you would write in Java or even Python. Some of the best comments we've gotten is when we've shown people eve code and told them to ignore the symbols, just read the words. Their eyes really open up and they tell us pretty exactly what the block is doing. No, it's not all the way there, but that's a big step forward.

In any case, check out our followup on what Eve is and isnt [1] - we're under no delusion that this is the end user story... yet :)

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

[sanderjd]

The "ignore the symbols and just read the words" idea is part of Ruby's promise as well. In practice, I don't personally find it very satisfying, because it's easy to write things that read like they do one thing, but actually do something else. So you have to train yourself to ignore what it says until you figure out what it does.

I think the better metric to optimize for is how easy it is to go from seeing a piece of code for the first time to having a mental model for what its runtime behavior will be. Do you think Eve is strong on this in addition to its "readability"?

[cmontella]

> I think the better metric to optimize for is how easy it is to go from seeing a piece of code for the first time to having a mental model for what its runtime behavior will be

Actually yes, we've seen some evidence of this. In one instance, I was demonstrating the syntax of Eve to someone who really only had experience programming HTML, and he was able to point out a bug in my code without even running the program.

I believe this is because the syntax is very minimal, there are very few core language operations (only 9), and the underlying data model is completely consistent throughout the language (everything is a record). You can only query and update records. When you only have a few consistent tools, you can wield each one with greater confidence.

Also, in Eve if you want to know what a block does you can just ask for the output right next to the block, so there's no guessing. You can look at it as text, a table, a chart, or any number of visualizations you can come up with. When you have the output and the source code right next to each other, updating in real time, and recompiling automatically as your code changes, you can get a better sense for what each individual part does in a block of code. You can even point at a specific element and ask "What draws this". We hope that all of these features will encourage new users to feel the freedom to explore, make mistakes, and build their own mental model of how Eve works, without having to understand set theory.

[sanderjd]

Thanks! I hoped that was the case.

[jimbokun]

Fair enough, but I thought an earlier goal of Eve was to bring programming to non-programmers? Did that change as Eve evolved, or am I just mis-remembering?

[ibdknox]

It is, but it's a multi-step process. :) Checkout the three milestones at the bottom of the post: http://programming.witheve.com/#justataste

[xj9]

If we can eliminate software engineering as a profession our work will be done. There will be nothing left for humans to do, because at that point we will have invented a General AI.

Up until that point, software engineering will be a well paid job. I really don't understand this attitude that everyone should be a programmer or that programming should be easy. It isn't easy. Obviously, we should remove unnecessary friction from the process, but framing your thoughts precisely takes discipline. Building maintainable systems takes practice and understanding. It takes years of study and work to become a good engineer.

I definitely think people should be exposed to programming in school, but we study physics and chemistry there too and nobody expects everyone to be a physicist or chemical engineer. Specialization is a good thing.

That said, I'm down to compete with whatever you people think can replace me. I love a good challenge.

[chongli]

nobody expects everyone to be a physicist or chemical engineer. Specialization is a good thing.

The difference with software engineers is that they have the power to build their own tools; physicists and chemical engineers largely don't, unless they themselves are also software engineers. You aren't going to use knowledge of chemistry to build general software but you can always find a use for software engineering in any domain. This puts it in the same category as literacy and mathematics, rather than strictly being a specialization pursued toward its own end.

[xj9]

Don't quote me out of context

I definitely think people should be exposed to programming in school, but we study physics and chemistry there too and nobody expects everyone to be a physicist or chemical engineer. Specialization is a good thing.

I am saying that people should be taught programming in school, like literacy and mathematics, but that doing so is not going to prepare students to make production-grade software. We need actual engineers for that.

[darkmighty]

It's not unthinkable that a language, by design, facilitates or enforces precise definitions.

As a far-fetched example, think of Lego. You can't "fail to compile" your Lego bricks. You have a finite selection of bricks (all clearly visible and usually available within arm's reach), and your job is to just lay one at a time. Given any brick, it's "obvious" to a human how it fits with other bricks. The worst you can do is essentially create a crappy Lego design. As you noted going from a rough thought of

"Uhm I want to build a Dragon of about this size..."

to a finished build requires a powerful AI. But we don't need to go that far to be better than

"Place $brick1 in p=(32,17) at orientation o=(0,pi); place $brick2 in p=(38,15) at o=(-pi,0); ..."

The rigidity of the bricks inherently prevent you from overlapping them, but not the above declaration :)

[xj9]

Not at all. Good tools are very important, and we shouldn't stop working to make them better. What I disagree with is the idea that good enough tools can replace engineers without them becoming General AIs. Until we get to that point, there will be systems that need to be built that only professionals are qualified to work on. I'm not saying that we need licensing boards or any of that nonsense, just that nobody is going to merge poorly constructed code into an important project.

[darkmighty]

I don't think it was implied good enough tools can replace qualified engineers. But I feel sometimes engineers don't realize that tools can not only be valuable for beginners (itself worthwhile, imo) but actually make experienced professionals more reliable (less error-prone) and work faster.

Taking the Lego analogy further, even if I, an experienced Lego builder, can construct a set entirely in my head, and write a correct assembly script, building it physically is likely faster and certainly less error-prone.

Those kinds of goals are hard to achieve with software (especially considering what we have is already pretty good!), but I think they're a worthy pursuit.

Examples of language/interface design that seem strictly beneficial: (regardless of experience or project)

- Showing the result of [valid] code changes as soon as possible (a feedback problem);

- Disallowing invalid expressions (a consistency problem);

- Displaying relevant components (functions, libraries, APIs, variables, etc) (a visibility problem);

- Bringing documentation closer to code (making functionality obvious)

Eve tries to tackle some of those challenges, especially the documentation problem and the visibility problem.

Solving those issues can both improve productivity and bring more people into programming.

[xj9]

Okay, but who is your customer, the engineer or the layperson? At a certain point, our needs are going to pull in separate directions. Simple is good, but certain problems have a baseline of complexity that can't be eliminated. Who are you planning to side with?

[taeric]

You would be surprised how non obvious Legos actually are to people not familiar with them already.

This is akin to thinking doors are intrinsically intuitive. There is actually a ton of training that kids go through for that "intuition."

[j2kun]

I don't understand your example. If you abstract away the hard part of searching a database and sending an email (as most programming languages do), then every language is as easy as the snippets you posted. In python:

    messages = slack.search()
    email.send(to='[e-mail]', subject='hi', body='yo')

Are you saying that Eve removes the difficulty of interfacing with external programming systems? If so, I haven't seen that in their documentation... For one, you still need to know HTML to do anything useful.

[rads]

On my first admittedly unfair impression I feel the same way, but I'd love to be proved wrong. Chris Granger is a serious programmer whose work deserves careful consideration.

[tigershark]

This is just a dsl, you can write easily something equivalent or even better in other languages, but doesn't really tell you anything about the underlying language. What is the difference with:

    let messages = search slack_message body

to me this version seems more readable without the square brackets, hash and @ distractions. Why as a non programmer I would ever want to know when to use @ instead of # and when to put square brackets? I think that the F# version that I posted it's easier to read and to write for a non programmer.

[zubairq]

No, it's more than just saying let messages = search, as in eve this is being run whenever search changes, whereas in other languages it is run when you explicitly call it

[PeterisP]

Now this sounds very dangerous - one of big problems of declarative style is that it's too easy to accidentally build a system that does much more than you intended, totally killing performance.

There is a very, very big difference between running a search once and re-running it whenever search changes; if you want it one way then you definitely don't want it the other way and that would be a serious problem.

That's not a "in this language" issue, you can do both ways in any language, but this choice you made should be (a) explicit and (b) obvious, which it doesn't seem to be in this case; where a reader can reasonably expect the search to be run once.

[zubairq]

Actually in Eve it is explicit, there is bind and then there is commit:

http://docs.witheve.com/handbook/bind/