Levente Mészáros
2013-10-12 11:48:09 UTC
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
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
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
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