Yes, what you write is what I had in mind. But this would really be abandoning 1d representation. I consider this to be a very important conceptual shift, not a mere moderate change! The presentation would be still 1d-like, but this is not important -- you may very well switch among several presentations. Applying this universally in the whole system allows one to use generic editing tools, without the impedance mismatch and continuous parsing of flat text in gazillion of different formats. It is then natural to apply this approach to the whole OS shell, not just the IDE. I had the "source control for free" idea, too, and it is nice to hear it from someone else, too.
On Sun, Jul 21, 2013 at 2:04 PM, Gath-Gealaich <[email protected]>wrote: > On Sat, 20 Jul 2013 17:54:54 +0200 > frank <[email protected]> wrote: > > > This! > > > > There have been so many attempts - by people who were by no means > > stupid - to replace text as the primary representation of code! > > And ALL of them have failed, miserably! > > The best anyone has ever achieved was to enthuse a few managers, > > much to the detriment of the engineers who eventually had to use > > the shit on a daily basis! > > > Hmm, perhaps extremes are a bad thing, but some moderate changes could > yield improvements? I've recently thought of a programming system that > would dispense with source files, but not in order to replace them with > some sort of "visual programming" system or anything of the kind - > simply to impose some potentially useful constraints onto the editing > process, Paredit-style. For example, keeping the source in form of a > data structure would obviate the parsing process - you'd eliminate > syntactic errors. That's not to say that this would make the editing > process "visual", as in playing with pictures - you'd simply be unable > to make edits that violate the code structure (say "bye" to unbalanced > parentheses - yes, I'd like the system to be an enhanced derivative of > Scheme, coincidentally). > > When I started thinking about the editing process this way, some > interesting ideas clicked into place - for example the notion that if I > made the program data structure (every module being a grove of trees) > a persistent one, many useful and desirable features of a programming > environment get simplified: for example, the notion of Git-like > versioning on disk and undo-redo in memory simply become the same > thing. The different versions of the code would share most of the > structure, dispensing with most of the need for compression (which Git > needs in order not to blow up your disk with redundant data) and > simplifying code comparison and diffing (once you find that two > (sub)trees of code you're comparing have an identical root node, you > don't need to go any deeper; you already know that they're identical). > > Gath > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
