I agree with much of what you describe about the problem. We should support many different views of the data describing the program. And not just for different people. Even a single person can benefit from many views, e.g. when debugging or addressing different problems. Text seems to be very opaque for most analyses, requires too much non-local interpretation.
What model do you use for projectional editing? Lenses or something else? On Sat, Oct 12, 2013 at 6:48 AM, Levente Mészáros < levente.mesza...@gmail.com> wrote: > I think the short answer is that there's nothing wrong with it per se, but > on the other hand I think there's a lot. I think the problem lies in that > it's difficult to understand, develop and maintain a complex program. The > real question is this: what can tools do to help people (and not just > programmers) with that? This quote comes to my mind: > > “Programs must be written for people to read, and only incidentally for > machines to execute.” > -- Hal Abelson, Structure and Interpretation of Computer Programs > > I think people working on a complex program > - have different domain specific knowledge (requirements, business model, > aesthetics, usability, technical background, etc.) > - have different roles (business analyst, domain expert, graphical > designer, programmer, tester, technical writer, project manager, etc.) > - understand different aspects (user interface, business processes, data > structures, algorithms, etc.) > - work on different parts (individual forms, queries, algorithms, > graphics, etc.) > - collaborate with each other (feature discussions, design issues, well > defined APIs, bug tickets) > - manage multiple versions (testing, production, backward compatibility) > - etc. > > I think people need better tools that provide different presentations of > the same complex program based on their knownledge, role, understanding, > working area, etc. in short: their current presentation context. The > presented parts may contain business requirements, documentations, > discussions, graphical designs, business processes, design decisisons, > architectures, algorithms, data structures, version histories, APIs, code > blocks, etc. and any combination of these. The presented parts should be > interlinked, navigable and editable independently of the used notation be > it textual, tabular, graphical, etc. or any combination ot these. > Filtering, grouping, ordering and annotating information while editing > should be provided as a generic feature. > > I think that it's easier to fulfill the above requirements if the program > is stored in a complex mixture of domain specific data structures such as > styled text, tables, trees, graphs, graphics, flow charts, programming > language constructs, etc. Editing operations shouldn't be limited in any > way: in other words the data structures should be able to represent any > desired state such as partially invalid program in textual notation. I > strongly believe that it's possible to make a tool that also allows editing > programs in various notations including textual while stores them in domain > specific data structures optionally resorting to store some parts as text > if needed. The interesting thing to note here is that whether the program > is valid at any given time is not that important (see the quote above). > > Without going into too much detail on what becomes possible when programs > are stored in domain specific data structures let me list a few things here: > - styling with colors, fonts, sizes, etc. is possible > - renaming anything becomes trivial > - moving things around doesn't break references > - multiple different ordering and grouping becomes possible > - semantic analyzation of changes results in less conflicts > - discussing and annotating anything in place > - mixing and using notations accorind to needs > - presenting things in multiple locations while still being the same > - literate programming is pushed to its extreme > - filtering, grouping, ordering anything to your needs in multiple ways > - cooperating with domain experts directly > - versioning anything > - etc. > > Let me present a Projectional Editor prototype I was working on as a hobby > project in the past years (quite a few months in total working time). > Unfortunately due to my day job I lack the time to make this more complete > in the near future, but I think it already shows some interesting things. > The editor (in textual notation) supports cursor navigation as normal text > editors do, and this is despite the fact that the edited documents are > highly domain specific data structures. There are some simple text editing > operations such as changing string and numeric literals (by typing in > place) and there are also some basic structure related operations. I > created a somewhat complex demo that shows a document containing chapters, > styled text, HTML, JavaScript, JSON and Common Lisp code mixed together. > > The function that creates the document: > https://github.com/projectured/projectured/blob/unstable/test/content.lisp#L326 > The function that creates the projection: > https://github.com/projectured/projectured/blob/unstable/test/projection.lisp#L696 > The first screenshot on this page shows this demo: > https://github.com/projectured/projectured/wiki/Screenshots > > ProjecturEd is a generic purpose projectional editor written in Common > Lisp. It supports editing multiple domains represented in arbitrary data > structures. It also supports multiple bidirectional projections providing > different notations varying from textual to graphics. > > The wiki pages provide some trace amounts of documentation if you are > interested in that. > Wiki: https://github.com/projectured/projectured/wiki > Project home: http://projectured.org/ > > All comments and suggestions are welcomed! > > Best regards, > Levente Mészáros > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
