It sounds like Eve will essentially be a visual programming language, similar to the many others that have come across Hacker News.
Chris - is Eve a visual programming language? If so, what makes it better than all the others that have tried and failed?
Most of the designers (outside of web to be sure, since I don't live in silicon valley) I know don't use textual formats, that is for developers. Much of the content is too dynamic to work with textually without substantial programming.
What's the big deal? There is an entire family of conventions and tools that have been built up over the years to support coding in text: editors, version control, diff tools, patches, linters, code generators, naming conventions, meanings of special symbols, etc.
It's definitely technically possible to change the paradigm entirely, but how does one avoid reinventing twelve wheels?
To paraphrase, "I know, you won't write my language in flat text files. And now you have a dozen problems."
What am I missing?
If we were talking about any other coding problem and I suggested you keep all your data in a complicated text serialisation spread across several hundred text files and resolve conflicts by diffing the files line-by-line, I would be laughed out of the room. The vast majority of work in any IDE, including Light Table, is just working around the fact that plain text is a terrible storage mechanism for complex, concurrently edited data.
That's not to say that you shouldn't use text to write or view the program or that we should all be coding by drawing pretty pictures and connecting lines. Just that we should keep the code in a sensible, networked data-store with support for concurrent editing and ACID transactions and then the way you choose to present and edit it can vary from person to person.
> If we were talking about any other coding problem and I suggested you keep all your data in a complicated text serialisation spread across several hundred text files...
Except developing code in a team of size greater than one is a distributed computation problem. Distributed persistence mechanisms are basically a bunch of files spread across a system. And they deal with some of the same problems (availability, versioning, reconciliation, replication, etc.). Speaking of which, these are problems are typically solved through tools (git, etc.) that presume textual languages.
3. To be more concrete:
Q: How do I post code samples to sites like StackOverflow?
Q: How do I create patches from and apply patches to my codebase?
Q: Does git (or some other offline editing mode) work?
...some of the answers may include statements like, "Well, wiring and metadata is all XML (or something) under the hood, so use your existing merge tools." In that case, we're dealing with two things: a language and a configuration spec. We're not really talking about a system that's friendly to coders after all.
...again, these are technically solvable problems. I just think people are vastly underestimating the level of effort needed to get to feature parity with the current way of doing things.
The best way to prove me too skeptical is to develop a decent-sized project across a decent-sized team, which is something non-text development tools (including Excel and Photoshop) haven't been particularly good at. My bet is that this won't happen and that at best Eve will be a successful enterprise tool for domain-specific problems that can be tackled by small teams (again, like Excel, Photoshop, LabView, etc.).
Not that there's anything wrong with that. Adobe is a successful company.
People who worked with that used to love it and I'm fairly certain that Eve's model would (be able to) work quite similarly.
All the stuff I've done here [1] is plain text. I'm sure you have other good reasons for avoiding text, but these aren't that strong; text is mostly orthogonal to the real problems of building live systems.
[1] http://research.microsoft.com/en-us/people/smcdirm/managedti...
Professional programming is about managing complexity. It's about putting thousands of man-hours into one single project with a dozen of different people without anyone's head exploding.
Light-table could have potentially been a huge help in the constant battle with managing complexity.. It's an area that has need some serious development (virtually nothing substantial has been added to IDEs in the past decade). But instead you're going to create a beginner friendly monster.
This is the opposite of progress
The model we have is significantly better than what we ever showed with Light Table. For example, being able to organize "code" by the actual functionality it's related to instead of files is something that happens by default in our world. You can actually create queries to show any view of the rules that exist in our world that you want (show me everything related to this button, that has been changed in the past month..)
Our model is entirely about preventing people's heads from exploding, taming complexity through a very simple set of primitives that seamlessly work together.
I didn't want to believe it, but it looks like HN is highly biased toward anything that has some VC behind it, flocking to it like it's suddenly going to change the world.
Considering who sponsors HN, the biases of the community it draws aren't that surprising.