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/

I was initially confused by the "human" line too, but once I looked at the video and the examples I understood what you guys are trying to do.

There are a lot of really interesting approaches there. I really like the ideas!

I think a lot of service devs (read: stateless) won't get it. But people who code front end and deal with business logic daily might find something to love in here.

Worth discussing if nothing else! You got my star!

>changing the focus of tooling from the machine to the human

>It's about debugging tools that work with you to solve a problem.

>we want humane tooling

I know how hard it is to explain what exactly your product does. I myself constantly struggle with this. Eve is an interesting concept that is worth a closer look and discussion. But you guys need to learn how to explain its benefits using a less ambiguous language.

Well the linked page and videos explain the benefits of the current release pretty well. They should take less than 30 minutes to view. I think part of the reason they use ambiguous language is they see this programming language as the first step in achieving a series of more ambitious goals. They've also been writing specific prototypes which they also believe work toward these goals for the last two years.

...So, literate Smalltalk. Or literate Lisp.

so basically Java?

No, basically COBOL, which supposedly was a pogramming language so easy to use that managers could code the problems themselves without those pesky programmers that slow everything down all the time.

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

Why can't people just use Java?

Must be a server-side dev. Java client-side trainwrecks include: struts, tempest, Java Server Faces, AWT, Swing.

True it's unfair to blame Java alone for these, because client side is more difficult-- we've been searching for solutions for decades in a variety of languages.

Modern front-end is a mush of dozens of tools/contexts, etc. Way more complex than TeX, and way less reliable and with minimal debugging context. But as the Eve guys have said, we're using the same layering of precompilers and interpreters we've always done. It's a mess because it's not just Java (or Python or Ruby) it's CSS HTML JS XML JSON, and the whole rest of the alphabet soup.

It's about time we reconsider platform as a whole again rather than merely a sum of fragments. That's why I find Eve interesting.

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.

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.

What do you think of Scala?

Java? What a horrible language.

How so? (Just genuinely curious as I always here this) I have asked the Java developers at my job if they have this common mindset and they don't seem to agree. I don't work with Java that much so I'm just honestly curious.

Java is a great virtual machine, a good collection of open source libraries, an ok language, and a nightmare collection of best practices and people who enforce them.

I don't have a beef with the language, it is the developers who have never programmed in another language and still think that FactoryBuilderImpls are a good idea. They have never ventured outside of an IDE, but insist that Python isn't a real programming language. I can program Java but I never want to program with "Java developers" if I can help it.

That in a nutshell is why I said Java is a horrible language.

That said, people with a strong preference for a particular language are comparable to religious fanatics. A good engineer doesn't let language preference and emotional attachment to something get in the way of building something better.

If learning something else is too uncomfortable or seems unecessary to you then you are no better than a religious person.

btw, before I get downvoted the "religious person" analogy was what a senior developer said of me when I was a .NET guy a long time ago.

note: the same applies to the religious sects who worship libraries and frameworks (Mostly front-end Javscript web developers)

Your message could still be effective (or even more effective) without putting down "religious people".

He said religious fanatics who are also people but a niche inside a religion. What is wrong with that as it rings through? Both defend something mostly without bases with extreme vigor and energy.

Yes! I program PHP because I feel it fills a spiritual void for me.

I'm a Zend-Buddhist.

Cannot edit the post for some reason, but sleepy this morning and not native English ; rings true of course.

There's certainly no shortage of crummy developers layering on useless abstractions for no reason other than dogma. Don't worry, soon all those young and thoughtless developers will be coding in nothing but JavaScript, and the crufty Java die-hards will be pumping prime contracts to migrate old Java business engines well into retirement.

Java is incredibly verbose and does not support many modern paradigms very well (see Rx and streams). For that sort of OOP language, C# is far better. The JVM is excellent, however.

> Or rendering headers in your code

Sorry, you lost me right there. If you need headers, you've already run off the rails (no pun intended) IMHO.

Headers as in document headlines and literate programming not as in header files.

Thanks for pointing that out. I was wondering why I was getting so many downvotes.

You seem to conflate "allowing ambiguity" with "not requiring specification of extraneous detail."

It is not a new mistake. Many people thought that programming with GC, or with high-level languages, or with generics, was just a kind of magic that couldn't lead to understandable programs. But these things succeed because, while they allow you to stop worrying about certain details, they do so while still remaining perfectly well-defined and unambiguous.

The fact that you no longer can know how the low-level details will be handled can be very uncomfortable. If there is most of what you have spent your programming career doing, it seems like it must produce ambiguity and inefficiency. But this isn't generally the case. Optimizing OCaml compilers can often produce code faster than C simply because the higher level of expression expected from the programmer leaves more room for the implementation to generate the right low-level code.

I won't say that I know Eve will be successful, but it certainly is possible. It produces unambiguous behavior which just happens to no longer specify lots of details most programming environments make you think about. When I think about the work I do, most of which involves providing live representations of data, and executing certain rules when it changes, I would guess that most of the details I worry about are extraneous and could be dealt with by a sufficiently-smart environment that encompassed both the database and the program.

I would say that GC, generics, and maybe even HLLs are useful because they are tools to constrain the set of possible states the program can possibly enter.

When your language and runtime provide good tooling for constraining the state space, then that allows you to elide specification of those extraneous details.

E.g., some form of GC is a basic runtime requirement for most of the HLLs today. They could almost not exist without it.

Absolutely agree. Similarly, I think we are finding that if you want to program reasonably on distributed hardware or over state spaces too large to hold in memory, you need a programming environment that constrains your ability to specify that things happen in sequential order, or to specify details about how you listen for events or get access to data directly.

Eve may not turn out to be the right abstraction away from details. But the parent comment complaining about the details it takes away from the programmer is probably on the wrong side of history.

I'd say that the details still exist but they've been handled with a very powerful idea which is sane defaults triumphing over endless required specification. In most cases you still can reach the minutia, you just usually don't need to.

There's a difference between producing unambiguous behavior given a specific input and making it easy to create that input in the first place.

I'm with you along the lines of embedding defaults to reduce the boilerplate code needed to get a minimum working app, but there comes a point where this may end up requiring advanced coders to learn how to go deeper in order to override those defaults to get novel results. This could result in a language thats easy for a beginner to get started in but difficult for the intermediate to progress any further.

That sounds like a good description of operating systems, programming languages, databases, or any of dozens of other abstractions that work great, enable people to use them as black boxes without worrying about the details, and also are rewarding to customize or hack on internally for the small subset so inclined.

If that's what this is, a new field outside "programming" that allows an order of magnitude more people to author behavior for simple systems, that'd be amazing.

There are improvements that can be made though - I think one of the best articles I've read about this was here: http://worrydream.com/#!/LearnableProgramming.

Lots of things that show tools and ideas that would make learning programming a lot easier.

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

Well, maybe not the first time. But players in my campaigns tend to learn quickly.