Blows my mind how so much really is text manipulation. Not every thing though!
I think there's an opportunity for a big player in the dev tools space to create a mainstream visual programming language and associated tooling. Many are trying, like Luna (https://github.com/luna/luna-studio) and Dark (https://darklang.com/) but I'm worried they're not established enough to gain traction.
Unfortunately programming with a text editor has become so mainstream that investing time in learning potentially better tools nets a lot of friction and not to much gain.
Everybody thinks they want that until they try it on a real non-toy problem.
While on text based languages, lack of modularity is kind of hidden and only jumps at you when you try to actually change anything, on visual languages it jumps right at you when you open a project.
Ideally, anything that requires panning or zooming, should be packed into their own little reusable building block, instead many try to package as much as they can into a single screen.
I've worked on some projects using Node RED (https://nodered.org/) and have found this to be very true. It's painfully obvious that you're in for a fun ride when the code is literally spaghetti.
I think programmers should be trusted to write code as text, but the IDE should in some way help visualise how data flows through the system.
Intentional programming seems interesting. Reminds me a little of BDD frameworks like Cucumber (https://cucumber.io/docs)
I'll agree that graphical languages don't seem to have caught on for general purpose programming, but some reasonably powerful ones certainly exist at this point.
Speculating as to why, I admit I have no intention of picking up a graphical language for my next project. Partly it's familiarity (I don't know what I'm missing), partly it's learning curve (expending effort when my current tools already work), and there's definitely concern about the ecosystem (manually writing bindings is never fun). There are also existing tools whose functionality overlaps to some extent - I've seen (and briefly played with) tools for some languages that will create flow diagrams from your source code. It seems like graphic-centric languages exist, but only gain widespread adoption for specific tasks that are frustrating or tedious to address without them.
(Now, that was long enough ago that I forget most of my specific opinions, and many of them are probably now outdated.)
> I've seen (and briefly played with) tools for some languages that will create flow diagrams from your source code.
Could you share what those tools were?
JetBrains also provides a few diagramming plugins, but I've never used them.
I haven't yet come across tooling that does the same for C, C++, or D. This response inspired me to take a look though, and I did find something for Python (https://stackoverflow.com/questions/45238329). Thinking about it, the instrumentation approach taken there might actually work fairly well for most systems languages assuming you don't have any dead (or rarely called) code. Graphviz could be combined with the "-finstrument-functions" GCC flag and a few supporting data structures. Templated code would be tricky to deal with though.
Edit: Just came across CppDepend (https://www.cppdepend.com/). It's proprietary, but appears to be incredibly powerful at first glance. See its dependency analysis in particular (https://www.cppdepend.com/dependenciesview).
What stood out to me was the instant feedback that's provided when the pipeline was modified; you can immediately see the ramifications of your actions.
I don’t think we really view a file of source code as a linear page of text though, right? It’s a tree. Sibling nodes are often laid out either horizontally or vertically, and children are often wrapped in some type of brace and/or indented, maybe delimited.
I think the fact that editors usually a) align the textual boundaries of tree nodes, and b) allow syntactically/semantically-invalid states, sometimes gets people thinking about editing a character stream instead of a semantic tree.
Having used node-based programming environments extensively (Max, Reaktor) I am not convinced that that there is a ergonomically sound alternative to just writing the code in linear text files, but admit that there are probably domains where it is more suitable. I found it tedious and straining, particularly when you have to use both mouse and keyboard.
IDEs are the continuation of those models.
Spreadsheets would be much more maintainable if people separated data from the view.
You have to think about 9p as an RPC protocol with files representing objects within the file server program. Reading/writing those files is how you interact with said objects. And it doesn't have to be text, it can be binary. Though text is used when a human has to interact with something. This is why you can do a lot of neat tricks using just a shell script as you can directly interact with a program using a standardized interface. No other operating system can claim such a high level of homogeneity.
As a hypothetical example, take the game Doom. We modify it to serve a file system to expose all of the players stats as a file tree. So a file called health is an rpc call to read and write the players health. This means you can '% echo 100 >/n/doom/player/health' to set your health to 100. It also means you eliminated the need to reinvent the wheel and integrate a console shell in the game. This saves the programmer invaluable time and eliminates duplicate code. Now we can use shell scripts or helper programs to interact with the game. And they can be in any language as all they have to do is open(/path/to/file) and read() write(). Imagine how much code you can eliminate and how much flexibility you gain by exposing your programs innards in such a standard manner? At this point, you might be thinking "So, if it's a file server, does that mean I can export it to the network?" Yes. You can have another computer mount that doom file server and interact with it.
You can also export your USB controller or other hardware using the same method. The level of flexibility is intoxicating and I don't care if it doesn't play youtube (that's what archaic and primitive 70's os's running in vmx(3) are for :-).
Modern plan 9 and resources: http://9front.org/ (highly active community and recommended if you pan to investigate) http://ants.9gridchan.org/ (pop on the grid and say hello! also recommended) http://postnix.pw/ (resources)
Legacy and Labs stuff (some activity still): http://9legacy.org/ (labs 9 and patches) http://9p.io/ (labs mirror, needs updating)
Because of this the whole system is introspectable via cating interesting files.