Re: [fonc] What's wrong with storing programs as text?

2013-10-14 Thread Pavel Bažant
I agree with your analysis. I especially like the fact that the editor is
general purpose. The screenshots are already very cool!! Will check this
program when time allows.



On Sat, Oct 12, 2013 at 1:48 PM, Levente Mészáros 
levente.mesza...@gmail.com wrote:

 Dear list members,

 Let me talk about this question without introducing myself...

 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
  

Re: [fonc] What's wrong with storing programs as text?

2013-10-14 Thread David Barbour
On Tue, Oct 15, 2013 at 12:09 AM, Faré fah...@gmail.com 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
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc