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!
>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.
Why can't people just use Java?
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.
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.
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.
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 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)
I'm a Zend-Buddhist.
Sorry, you lost me right there. If you need headers, you've already run off the rails (no pun intended) IMHO.
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/