It depends on how you use the term "visual programming language", which unfortunately has a lot of baggage around it. It is not sticking lego blocks together like Scratch or LEGO Mindstorms, nor is it the boxes with arrows pointing at eachother like Max MSP/Lab View/Blueprint/noflo, but it's also not strictly textual. The closest analog really is Excel or Access, but with the ability to describe how you translate one sheet/table to another one. Your main interface is a grid of data and a list of output tables. On top of that sits a set of domain editors though, to make drawing UI, for example, not an exercise in writing a bunch of rows out into a table. Instead you use a photoshop-like tool to just draw your UI. Same with doing math or string operations or flying drones or working with music and so on. We of course can't cover every domain, but what's interesting is that the editor is itself kind of like an editor of editors and it'll make it fairly trivial for you to build your own manipulable representations.
Trying to reduce UI design to something like Photoshop seems quite problematic to me. It encourages the designer to think that what you see is all there is. What about the things that aren't immediately evident in a WYSIWYG environment, like accessibility for users with disabilities (I'm thinking especially of blind users)? And if the WYSIWYG environment uses absolute positioning, as Photoshop does, then how will the UI adjust itself to different screen sizes? An advantage of representing a UI in a human-editable format like HTML, XAML, or Android's XML layout system is that all the properties of the UI elements are equally visible and editable, not just the things that are visible in the on-screen rendering. Also, I think that reading and editing the UI definition in a textual format forces the designer to think of the UI at a more abstract level than just dragging and dropping elements onto the screen and tweaking the things that are visible in that environment. And for the UI definition to actually be human editable, one is forced to leave absolute layout to the computer, making it more flexible.
Photoshop isn't even used much for visual design these days: it's all pretty much Illustrator. Vectors make dealing with resolution much easier, but redlining is still needed when rasterizing to lower resolutions.
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.
We're doing some clever stuff between constraint layout and relative layout that will make a lot of that concern disappear. We also intend to present this as almost a statemachine, or a storyboard where you see the various states of your UI laid out, which gives us an opportunity to surface a lot of the "unseen" aspects of UI.
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.
That sounds very similar to LabView (aka. G)... Have you ever tried programming something complicated in LabView? I'd almost rather write assembly.
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.
I was suggesting that it's actually not like labview at all :p
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 don't know, I've only used Labview a couple of times, it had really nice interfaces to temperature sensors and some other physical things, you were able to throw together a quick ui monitoring a number of sensors, had a start and stop button and tools for data export. We were able to pick it up in a few hours. Programming the experiment took a couple of hours too, obviously it was rather trivial but I doubt we would have had much luck interfacing with all those different sensors in a C program without major headache.
