An interesting solution for a big problem.

[alcast...@gmail.com]

Hi all,

I just wanted to say I think this is a very interesting solution for a big problem in technology right now. 

I hope this isn't completely dead, at least it would nice if it could be open sourced so people could use and improve on it.

I think the idea of and IDE is not too far off either. I think it is a nice solution for the complexity of many modern programming languages.

Also, if anyone ever wants to talk about how to better utilize programming as a form of communication, let me know. :)

Cheers,

Amanda

[Anton Dyudin]

It is fully open source afaict? https://github.com/witheve/Eve

[magicmo...@gmail.com]

i am very interested in programming as a form of communication. to me it is like poetry, just few people can see the beauty in code.you  can reach me at e-dejong.com

[dcoo...@gmail.com]

I have created a place for such collaboration, which has drawn in people working on (or exploring) similar projects and ideas:

https://github.com/d-cook/SomethingNew

Also, anyone looking to reinvent software/programming would be SORELY amiss to not have a look at a few videos/articles of Bret Victor (a successor of Alan Kay):

http://worrydream.com

I have actually been on my own quest to do so, and I have come up with some theory and a project that is quite inline with the goals of Eve.

My project: https://github.com/d-cook/Objects

Best (as yet) explanation/theory behind it: https://www.cemetech.net/forum/viewtopic.php?p=270092#270092

[magicmo...@gmail.com]

As a member of the informally organized next gen language developer's association, i suggest you take one of the basic program specifications, and focus on making the simple series of programs such as the analog clock, the wristwatch simulation, snake, tic-tac-toe, and culminate in a chess playing program. These kinds of programs which have very tight specifications focus the mind, and keep things very real. The Eve project got to the point of flappy bird, but could not easily achieve a chess program, because without a variable construct in the Eve language, you eventually hit a wall where you need some mutable state and that is what variables are good at. You can hide state in a database, but that is an awkward and indirect method. 

Bret Victor's demonstrations are inspiring to be sure, however, the belief that immediate feedback will somehow make programming easy is an unproven assertion. As prof. Wirth wrote in his excellent book "Programs = Algorithms + Data Structures", the key unexplored area in my opinion is data structures. If JSON is the end of our evolution of data structures, we are indeed stuck in a bad place. Quick feedback makes the task more pleasant and certainly faster, but is a large program or website that easy to understand today? I think not. Big JavaScript programs are a nightmare to understand. We have a long way to go! The Eve project may have stopped, but the Red project is going strong, and the Luna team is working hard, plus other efforts that are not publicly published.

[Simon Hughes]

It sounds like you are basically saying that their main issue was that some programs are much easier to write in an imperative style than a functional declarative style, which makes total sense. Reasoning about state seems to be the hardest problem in dealing with the complexity of writing software, although obviously that is a gross simplification of the broader issues. Excel has global state and that seems true of Eve too, but like SQL it seems to struggle with iterative computation.

[magicmo...@gmail.com]

The Eve project was done using a very unusual methodology. The typical software project starts out with a goal, then you do a napkin sketch of how it might be constructed, then you make a more careful blueprint, and in the case of a new language you typically specify an EBNF encoded grammar, then imagine programs in that language, hypothesize a runtime that can be mapped to, and a set of library functions that might be offered. Building a compiler for a new language thus requires you to operate in 3 domains at once:  the new language space, the intermediate form space (AST, the abstract syntax tree), and the its output space (maybe LLVM or a translation into another language). Lots of jockeying happens between the 3 spaces; you can easily invent a language feature that cannot be easily mapped into code; and there are always quirks and limitations of the platforms (Browsers cannot send UDP sockets for example). The Eve project approached the task not syntactically, but strove to follow Bret Victor's design methodology where you play around with user interfaces, hoping to find a fluid and flexible way that people could interact with the computer to build software. There was a time when the Eve project, during its "Four Square" clone phase was building a practical tool, but they pivoted away from that approach. 

The truth is that the underlying computer has not changed in 50 years; it isn't easy to make big improvements. When i look at the landscape of computer languages, what is see is as an industry there is an enormous lie being repeated; that the initial typing in of the program is somehow the big problem; so we have enormously complex real time intelligent editors with auto-completion and hinting, etc., when what i see in reality is that people stare into the abyss and wonder why their program did what it just did the majority of the time; and that since programs last for decades, and pass through many hands, one of the biggest problems in the industry is maintenance. If someone hands you a big program, how are you supposed to learn how it works if you aren't the original author? I see the same mistakes repeated over and over, where people adopt powerful but cryptic languages and claim they have solved something. I see LISP and its derivatives resurface over and over, yet all the insiders know that self-modifying programs are almost impossible to read, and the tiniest change in a LISP program can have devastating effects on the execution. Haskell and the other functional languages are not solving the maintenance problem. Remember that inventor of Functional Programming was John Backus, the inventor of FORTRAN, and that he did not finish his work, so all the functional languages are really half-baked because the concept from which they sprang was not finished. Backus was trying to usher in the era of interchangeable parts, and this is the "big problem" awaiting a breakthrough.