actually Mr. Reese has an excellent point. If Tolstoy wrote War & Peace a sentence at a time, and had a group of editors watching over his shoulder as he wrote longhand onto paper this very complex novel, would it have helped or hindered? i think most of us can imagine it would have prevented the creation of the work. If people want to have any fluidity in their creative process having interruptions that distract you from the larger goal is indeed counter-productive. When you want to check a section, you might indicate such, It is an interesting contest, to see if the graphical input of programs can beat the textual in flexibility and speed at the same time. Clearly that is the goal of many of the people on this board. I am of the opinion that we must improve the underlying language first before attempting a graphical input assist, because the current languages have deep intrinsic flaws that prevent robust programs, and hinder interchangeable parts. If we create a graphical programming system, let's say something like Luna is trying to do, how do you copy/paste code unless you have an underlying textual form. So whatever graphical assist one invents, it must produce a textual form in order to be printed, and sections adapted. If you pin a programming language to a single IDE and editor you doom that language, because no IDE lasts nearly as long as a language does. A language has a grammar, a set of abstractions, and a runtime to support its execution on the operating system of the time. An IDE is a much more complex thing, that usually depends deeply on the graphical primitives of an OS.

I hadn't considered this persistence-centric argument against graphical representations, but given my interest in long-term data preservation, it's appealing. Specifically: working in plain-text systems makes your work more likely to be reusable a decade from now For decades, the plain text file has remained a pretty good common denominator for a diverse set of tools, which creates friction against graphically-oriented authoring environments. I've seen this play out most vividly in iOS development, where there are very well supported graphical tools for UI layout authoring, but many people avoid using them (in favor of generating UI elements in code and layout constraints in a textual DSL) because git version control and code review diffing operates on the harder-to-read plain-text serialization of the visual format, and it can be difficult to do a merge correctly. Does that mean we're stuck here forever? I'd like to think not, but I believe it depends on us finding the next set of long-term primitives beyond text files in folder hierarchies

Wouldn't a serialization format that supports diffs and merges and tools that help visualize UI layout diffs fix that? Unreal Blueprints have diff and merge tools that show visual graph differences. The merge tool doesn't really work but the diff tool is actually pretty useful. It's especially necessary because Blueprints serialize as binary

We explored building diff tools for graphs. Flat text files separated into lines has been the data storage mechanism for code for decades. Visual programming languages are much more complicated and are full of domain specific abstractions. It’s not hard to build a diff and merge tool once, but every small change you make to your VPL now needs to be understood by your SCM tools so it knows how to treat representations from different versions of your tool differently. Then the SCM tools starts to look a whole lot more like a database migration suit than an SCM management tool. Then there’s error management. In text you just thrown conflicts inline and let users fix them — with VPLs if you don’t add a nice errors pane to your app there’s no resolution path. The one good decision we made is using event sourcing as our persistence mechanism. Each meaningful change was represented by an event and the graph was built up from that. Event sourcing gives you collaboration for free google drive style and it probably makes some of these issues easier to deal with if you try to diff and merge those vs the resulting graphs. We didn’t dig here long enough to know for sure.

It’s funny how text formats enjoy such a special treatment, just because we’ve been using them for ages and all the tools are in place. Isn’t text just a soup of bytes that adhere to either ASCII or UTF-8 — both quite complex formats (if you count the international extensions for 8-bit ASCII)? And editors and diffs just work so well because we all agreed that a specific sequence of bits in these formats means line feed and/or/with carriage return (even that convention is quite messy if you consider the details, and let’s not get into other white space…), so we humans can better read it. If aliens (or humans in 1k years) ever discover data stored that way, it’ll be worth not much without a decoding table explaining these formats. Some simple proprietary binary formats might be even simpler to reverse engineer, if you don’t know which bit sequence translates to which symbol. Decipher this, future 👽 or 🤖, 💩😈! Also, why should we limit ourselves to a solution space that requires a symbolic / textual representation that we then try to find a visual and/or interactive representation for, instead of looking for visual and interactive representations directly (or first, and then try to find a symbolic one later)? I firmly believe that focusing on a symbolic — and specifically textual — representation first is part of the reason why we haven’t had a breakthrough success in visual languages in the last half-century. It’s the “emulating old media in new media because we don’t know better” story all over again. At least everybody is fine now that we have moved on from printing our text symbols on paper to electronic displays, even though most editors have been designed for that printing environment and there are religious believers out there that you’re supposed to only use those text editors built for that ancient world. Btw, there’s nothing wrong with using them. If you love them, keep using them! That technology brought us here, so kudos to everyone who contributed on getting us here. There are lots of great, well-designed, and extremely robust tools out there that have proven their worth and stood the test of time. Just don’t keep telling me the future will be more of the same.

I wish visual tools had a better track record. I would love to see us move away from text too but it’s so hard to get anywhere close to the functional expectations of developers you need to start a groundswell. These tools all have a certain runway and if they can’t move fast enough to take off they die. You need SCM, testability, and other basic -day-1 expectations to be met in order to take off. I’m glad this has come up here because I do think some kind of universal toolkit for VPLs should exist. General purpose probably shouldn’t be the goal — it should be more analogous to LLVM than Swift, but that could be a cool project for this group. If you could spin up hundreds of domain specific VPLs that’d give a few of them a good chance of taking off in their domains.

Our eyes have most bandwidth so it is natural that visuals tools will become more popular. I still think text will be important because text is basically speech on paper and we speak a lot every day and the mouth and ears are good communicators but ears and mouth do not analyze as well as eyes. Our biggest problem are that the code today is not humanlike. So everyone has to learn a new language in order to speak with the computer. I think we should use more grammar of more humanlike languages to create new programming languages. Programming is difficult through text, but so is Chinese for a English speaking person...

In the early 1600's Descartes invented Analytic Geometry, which converted geometrical problems into algebra. One can argue when you review the history of mathematics that this has been the trend. It is more intuitive to work in a geometrical space, so there is strong interest in the graphical assistants, but clearly at the end of the day one is building statements in a language. Clicking on a point in a grid is selecting something in the XY plane, and 2 numbers denote that, so there is a perfect 1:1 mapping between the operations one does with a mouse or hand gesture. programming will not have breakthroughs in reliability or interchangeable parts merely by adding nice graphical inputs/manipulations.

https://futureofcoding.slack.com/archives/C5T9GPWFL/p1546130568160100?thread_ts=1545983608.108800&cid=C5T9GPWFL Inform 7 uses something closer to English grammar, which I guess is what you mean by human like. The problem is, although it's easier to read for non-programmers and English speakers in general, it's hard to write because you end up in an uncanny valley where English grammar rules and simpler imperative programming language rules get confused.

@Stefan wrote

It’s funny how text formats enjoy such a special treatment

Yes. I'd like to draw a distinction between text as a user interface and text files as a storage/versioning format. Note that spreadsheets are text heavy user interfaces but poorly supported by so called 'text oriented' tools such as Git. Specifically in files there's the notion of a structure built on lines of text. It's a very hard ceiling in the current ecosystem. Even if we say 'text is great as programming language', we don't have to accept 'large blobs of text' are the best storage format (e.g. you could parse and store/version a graph structure, or store individual cells, etc.). I have a couple of write-ups specifically around plain text files starting here: https://shalabh.com/programmable-systems/plain-text.html

@shalabh Thanks for bringing up the difference between storage format and user interface! That is an important distinction. Think about it, we even have about 100 individual hardware buttons for specific letters of our alphabet — that’s how special text is treated in the user interface. I’m more interested in the user interface side currently, and if I understand correctly, @shalabh and @Joe Trellick at least have some strong opinions about the storage side. Of course, these are not as easy to separate as it looks. Text editors have to do the transformation from byte stream to symbols/glyphs to allow any meaningful manipulation, but isn’t that exactly the thing all data formats need — an editor that allows us to read and manipulate the stored data?

I wouldn't say I have 'strong' opinions, but more like negative opinions of the status quo, with only vague ideas of better systems. (I'm not just anti text file but also anti file in general.) I believe storage and UI are not easy to separate in the current systems. Text editors do parse homogenized byte arrays into richer structures. They partially (and poorly) duplicate functionality already implemented in the language parsers. Why is this pervasive reimplementation needed? Can we have a storage substrate that can preserve the rich structures instead of homogenizing them and then having to globally distribute the parsing knowledge out of band?

I love text as a medium to program. A purely visual environment will make the "programming is writing" analogies moot, and that'll be a sad thing to lose 🙂 But today's environments are too text-centric. Ansible's YAML configs for example are a pain to work with, and I've often wished there was a graphical, interactive way to configure system provisioning. I think a judicious mix of both text and visual environments is what we should move towards.