I've been thinking about this constantly for the last 2-3 years. I'm working on something which might lead to this. What I've concluded, is that we don't have a good representation for a general purpose tree editor to work on. Roughly speaking, S-expressions are just a bit too simple, and XML is way too complicated. General purpose plain text editors work so well because we've agreed on a common representation (more…
I've also been thinking about this for about as long (read this same article about 2-3 years ago), and came to pretty much the same conclusion. I actually think defining the grammar for turning text into a tree is likely to be the easy part, compared with building the editor itself. That said, during my research I ran across an ancient Usenet thread from 1989[1]. In it, the OP asks: > Should the language designers be…
Re: Why Don't We Have a General-Purpose Tree Editor? (2014)
#161Back in '84 I was an undergrad at Boston University, doing an independent study with one of the business professors, Dr. Fedoritz, on a "next generation spreadsheet" that was to incorporate a cell-less freeform tree structure to represent Frames of Reference. Operating under the business school, we were working on advanced interfaces for financial professionals. The project was called a Frame Based Knowledge Representation System, with each node being a collection of data, with two special data types, one called a "frame" that contains logic and references to the other fields of the node, and one called a "reference" that pointed to a "frame" of some other node. All very basic, as the end-users were not programmers but financial analysts. Due to the freeform intended usage, the UI was on a vector monitor (like the old Asteroids arcade game), and end-users were trained to use the system as a collection of notes they can freeform write anywhere about their job, with little formulas to calculate things within a note and between other notes. It was explained to be like a combination notepad and spreadsheet. And it made a lot of sense to the end-users; they quickly got elaborate with their logic. The UI got zooming capabilities so actively edited or evaluated nodes would scale up while others shrank down, the end-users kept asking for more sophisticated features, and it really looked like we were on to something BIG. During an evaluation of the project with other professors, one of them asked "Once you've completed these requested features from your financial analysts, haven't you recreated just another programming language? The UI is unique, but I'm just seeing an interpreted language and a metaphor for programming that works with your finance end-users." ...And he was right.