I have long wanted to see programmers experiment with taking this IDE thing much further. Almost every other authoring tool has an opaque file format, manipulated via one or more views. E.g. when a digital artist wants to create and manage a complex 3D scene, they use a tool like Maya. They're not fussed about whether they can read the file format!

So why not try letting the program exist as an embellished AST, that you edit in multiple IDE views? You could still have text views that present the program in one or more programming languages. But also views like circuit diagrams, graphical call graphs, other standard programmer diagram types. A run-time view with a time axis and time controls, with graphical representations of the program, ability to rewind, fiddle with state, travel visually down all the code paths.

Can we really do no better than text + our imaginations and whiteboards? I'm almost certain we can do better.

Or, if you find those ideas a bit eccentric, then start with just having views of source code. For example, my team requires verbose symbols, but I like very short symbols. I wish I could just have a simple map from the long symbol names to short ones, and toggle my view of the source code without affecting the source code. But since no IDE I know of has the concept of a view, I don't know how to do this today with existing tools.

I like this idea, not least because I've also had it myself. I use Xcode's "Callers" and "Callees" assistant editor all the time but that's a primitive tool compared to your suggestion.

> Edit in multiple views

If you take a closed system, one that begins executing from a fixed point and doesn't have to handle events, concurrency, asynchronous calls, interaction with any external process, then you probably could create a tool like this that would work nicely most of the time. It's going to be a bit harder to do that once you introduce those common real-world situations.

I think you're really asking for a tool which externalizes a lot of the internal reasoning we do as programmers. You want a tool to make concrete some of the abstract models we build up in our heads about the structure of our programs: call graphs, event sequences etc. I wonder if it would be useful for education? If not that, then such a tool would be incredibly helpful for getting to grips with a new, large codebase.

I'm just not sure it's particularly do-able in any kind of non-trivial way.

Yes, this is definitely what I'm getting at. I do think it would be amazing for education, but also for real work. The Unity Editor, and other similar WYSIWYG game editors, are kind of half-way between tools like Maya and programming environments. Other than being buggy and disorganized, the idea of it is amazing. They let you view "the program" from the 3rd person, as a visual object, inspect and edit state, etc. The productivity gains are real, IMO.

I think the approach generalizes, in principle, to all systems, including the real-world concerns in your second paragraph. Certainly it would be non-trivial. Still, if I ever have the free time, it's about the only thing I'd want to work on.

One place to start could be the debugger. This at least has the advantage of a fixed call stack at any point of inspection rather than a whole cloud of possibilities, making drawing some of those call graphs and flows much easier.

I agree, I think it'd be really useful for real work, particularly maintenance work and ramping up on established code bases.

I've been playing around with a similar idea for the design of a language/tool suite I've been working on (essentially a DSL for narrative structures in games/interactive multimedia), and it's been very nice so far. I'm definitely surprised it isn't an approach more are trying.

Another interesting example is Antimony (http://www.mattkeeter.com/projects/antimony/3/), an experimental CAD program that came out of the MIT Media Lab. The main metaphor is dataflow programming (with nice built-in Python scripting within nodes), but that exists side by side with a pane exposing a more traditional 3D modeling interface. It's not quite production-ready, but as a UI experiment I find it way easier to use than traditional CAD software.

> I have long wanted to see programmers experiment with taking this IDE thing much further. Almost every other authoring tool has an opaque file format, manipulated via one or more views. E.g. when a digital artist wants to create and manage a complex 3D scene, they use a tool like Maya. They're not fussed about whether they can read the file format!

Interesting choice of example, because over the last few years open formats like Pixar's USD (https://graphics.pixar.com/usd/docs/index.html) have been emerging for managing complex 3D scenes - precisely because of problems with opaque file formats.

That said, we're now seeing more and more things like Unreal Engine's Blueprints, Apple's "Swift Playgrounds" and so on. I think your wish is slowly coming true.

> Almost every other authoring tool has an opaque file format, manipulated via one or more views.

There is a strong trend away from this. Blender is taking over the 3D world by having a programming-like CLI. AutoCAD brought layout as a LISP into architecture and basically destroyed everyone there. Image manipulation software are starting to offer custom sequences of manipulations instead of just filters. Mechanics 3D CADs are getting CLIs everywhere.

I've had this on my mind in various forms for almost a decade. It's only recently been crystallized from something abstract into much more concrete thanks largely in part to Bret Victor's talks. If you haven't already seen them, I highly recommend "Stop Drawing Dead Fish"[0] and "The Future of Programming"[1] as starting videos. Then just watch all the rest of his talks. :)

[0] https://vimeo.com/64895205

[1] https://vimeo.com/71278954

Thinking of something like Halide, which splits the program into a algorithm part and an execution schedule: there may be productive ways to factorize "one-text-file" programming conventions into multiple aspects written in different IDE modes.

Haskell's "do" notation always seems ripe for this. Write the non-pure aspects of your code in a more appropriate language, or any one of a choice of front-ends. The aesthetic of typographic code in a flat file is strong in the FP community, but "do" notation is not its finest hour.

I wrote an article on a relatively simple approach to building language systems with these properties titled, "How to Make View-Independent Program Models"[0]

I haven't had a chance to try an implementation yet, and maybe there's a reason why it wouldn't work, but I've been looking and haven't found it yet (maybe someone here will!).

[0] http://westoncb.blogspot.com/2015/06/how-to-make-view-indepe...

I think the challenge for systems like this is flexible editing -- the most natural way of making changes to source code often goes through "invalid" states which can't be represented as an AST (or as a path through a parser automaton).

I think that has been true for AST editors because they remain halfway in the traditional text-editing paradigm, which involves these invalid states because the granularity of the interface is single character operations, while the model you are specifying with those characters (the AST) doesn't recognize those units.

An alternative is to have the editor operate on language constructs rather than characters. Rather than parsing the program view in order to arrive at a model of your program, you arrive at a view by rendering the model in some way. But the key thing is the model always stays intact because the operations you perform on it through your editor are in terms of language constructs (e.g. a single action in your editor might be 'add property' or 'create class', which is ordinarily accomplished by typing out lots of characters that can hopefully be parsed into such things).

I believe in this approach, but making it usable is harder than it sounds. Once I tried watching myself program with this idea in mind. I realized I often start by typing methods which don't yet have a class, code fragments which don't yet belong to a function, even expressions which don't yet live in a statement and which refer to variables which not only don't yet exist but don't belong to any yet-existing class — maybe I'll pause half-way through writing the expression and start creating the class in another window.

So you pass through a lot of ill-defined states. For the IDE to keep up it would have to just represent explicitly "this is a code fragment which doesn't have a name", "this is a variable which isn't defined anywhere" and so forth.

Those states are only ill-defined on the assumption that you're entering text which will be parsed. You can still enter fragments when operations are in terms of language constructs rather than characters--you have just supplied a partial set of parameters to the construct, which you can go back and finish later.

Maybe the other part of this issue is expecting to use these potentially better editors in the same way we use text editors. I would bet different patterns of interaction would surface for the new editors which aren't obvious from our present standpoint.

xoL is a graphic based programming language that I have been working on. The goal is to make programs visually easier to read. And to be editable with almost no use of keyboard. It can work well on tablets. A partially working prototype can be found here: https://github.com/lignixz/xoL

I have a newer design with substantial improvements. If only I had funding to focus on this.

This sounds a lot like Simonyi's "intentional programming"

Code stored as AST in a database, text representation in a specific language is just one of many possible views

Problem with that is that programming languages are not just about ASTs, they also have different semantics. A "class" in C++ is not like "class" in Java. Nor is it very easy to translate between a garbage-collected language and a one with manual memory management.

One could think that such an "AST in database" solution should have one agreed-upon semantics common to all its textual representations, but at this point you may as well serialize your AST into s-expressions and suddenly you're writing in Lisp.

Yeah, my recollections are from a talk I attended 17 years ago, so details may be a little off. It was the first time that I ever saw refactoring demoed. I have no idea what happened to it in the longer term, I know that Simonyi left Microsoft and started a company just to pursue intentional programming.

FWIW I do remember that the name comes from the ideas that the most important thing that a developer does is express intent. I've found that to be a powerful way of thinking over the years.

> So why not try letting the program exist as an embellished AST, that you edit in multiple IDE views?

That is possible with Jetbrain MPS's Projectional Editor [0], used for developing (using) DSLs.

Cool thing is, you can define your own projections and e.g have your program projected from AST to a table, graph, text etc.

[0] https://www.jetbrains.com/mps/

AST = Abstract Syntax Tree.

" ... manipulate AST ... "

Interesting thought, but that's not a property of a language per se but a function of the IDE.

Except for editing lisp, which manipulating the AST directly in code.

Not really. The AST in lisps is much more obvious, but you're still editing a text serialisation format, and any features that operate on the AST itself are provided by the IDE on top of that.

There is no "concrete" AST that's not a "serialization format". A binary AST is also a serialization of AST.

Lisp source is pretty much as close to AST as you can get while still staying in text-land. That said, experienced Lisp developers often use tools like Paredit mode that let them navigate and edit the code in terms of tree nodes, not characters.

Indeed. Any AST in binary format is going to give version control some trouble since those seem best suited for text formats.

Macros operate on the AST at compile and run time, without any support from the IDE.

I am talking about IDEs.