There are various ways to present the same structure. > Trees, for example, can be represented top-down, bottom-up, > left-to-right, dynamically (front to bottom), graphically, textually, > etc. Each representation can also lead to different ways of editing > them. So each application wants to represent them in a certain way.
So you can have a toolbox of tree representations and editing modes, but > don't count on having a single one to serve all the applications. > Yes, I agree. But that's just what I had in mind with the pixmap editor example -- the editor provides a specialized pixamap drawing interface, but the idea was the general array editing capability provided by the OS shell to be applicable *uniformly* to any array-like structure in any application, i.e. to the pixmap, too. This way any generic array manipulation tools I may have created for myself have much broader usability. The whole environment (OS + applications) would be "structure centric", not "bytestream centric". > > > And this problem is compounded by the number of different data > structures. > A nD array and a tree cover 80 % of structures the user conceptually works with. Add DAGs and a few other types of graphs and you are at 90 %. Moreover, specialized views can often be ambiguous, whereas the generic ones wouldn't be ambiguous. > > > > 3) Get rid of established but unnatural ways of manipulating data. > > Most importantly, get rid of flat text and find neat graphical > > representations for the most common structures. > > Bouhahaha! > > I mean, graphical representations are nice. To read them. But when it > comes to editing, ie. to transfering information from the human brain to > the computer, nothing beats in bandwidth the ten fingers and the > ~100-key keyboard. > > I am sorry, my wording was not exact. I meant to say find neat generic graphical *presentations* of structures and edit the structures directly, not their on-disk linear representations. I didn't say anything about input methods. There is no reason why one couldn't directly and very efficiently edit structures using a keyboard. Such systems actually exist, but I think they are underused in the programming community. > Unless you want to develop high resolution brain waves reading systems. > This would be nice, I could then prepare my answers in advance. > The point is that you can't think like that, in such general terms, for > all applications and for everybody. Yes, I use very general arguments, so there is greater risk of missing important details. At the same time, there is higher chance of finding new ways to simplify all this stuff. Software development is a disaster today and the various tools constantly emerging are actually just masking the real problems, making really effective solutions even less likely.
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
