On Tue, Oct 15, 2013 at 12:09 AM, Faré <[email protected]> wrote: > > > Without going into too much detail on what becomes possible when programs > > are stored in domain specific data structures [...] > Yes, yes, yes, but to beat a good text editor like Emacs, you have to > fight this phenomenon identified long ago by Alan Perlis: "It is > better to have 100 functions operate on one data structure than 10 > functions on 10 data structures." > [..] > A good text editor can can in constant programming time improve all > the points of views at the same time, and delegate the finer > non-trivial details of bridging to the human imagination. That > requires fewer people with loose coupling. >
As I see it, text is still structured in domain-specific ways, and text editors make it very difficult to provide useful views on this data without also integrating ad-hoc parsers, language specific environment models and module systems, even type checkers - all of which is very painful to do. Alan Perlis noted in the same epigrams you quote: "The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information." Also, I think we can have 100s of functions for 100s of data structures if we take a different approach to developing those functions, such as programming-by-example. Especially if many data structures have common classes that can immediately use many generic functions (like document, graph, diagram, geometry, table, matrix, spreadsheet, etc.). > > Doing it will [take] a committed person at the heart who has a good architectural vision that makes sense and attracts hackers, can maybe communicate it well enough to convince other people to join Whatever happened to your TUNES project? I believe I've developed a new approach that can achieve the TUNES vision, albeit with a different... point of view. I'd be interested in your opinion. See my recent post on Personal Programming Environment. > > data structures should be able to represent any desired state such as > partially invalid program in textual notation. > > > That's an essential insight indeed. It should be possible to start > thinking according to one point of view without having to keep > coherence with other points of view at all times. But then, how does > your system reconcile things? What if two people edit at the same > time, breaking different invariants? Soon enough, you'll find you need > version control, transactions, schema invariant enforcement, and > tracking of temporarily broken invariants (where "temporary" all too > often means "till death do us part"). > I think a more useful question might be: how should these conditions be addressed in a live programming system? I think the answer is that programmers should be able to control and understand the boundaries for failure. Making failure too fine-grained is problematic, since it requires handling a partial success. Making failure too coarse-grained is problematic because it hinders reasoning about security properties. Best, Dave
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
