The sticking point isn't the "visual" part, it's the "not text" part.
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."
Those tools are hard to build. Sure, parsers are easy. Incremental parsers that can deal with half-edited text are hard (that's basically the entire function of Intellij MPS). Running static analysis on half-edited text is hard. Keeping text in sync with runtime state is hard. Even diffing text is hard.
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.
Incremental parsers are actually quite easy: just go recursive descent and memoize. Keeping text in sync with runtime state is harder, but still not that hard, you just need a nice replay model. Going functional or immutable actually doesn't help very much here: it distracts from the dependency tracing needed to make a live system work.
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. OK, you have prima facia case that some problems won't be problems anymore. But the problems you mention are mostly nice-to-haves and not must-haves. For example, I can do static analysis manually or when it's safe (pre-commit, during saves).
> 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.
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?