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

[Levente Mészáros]

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

[David Barbour]

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 <

Post by Levente Mészáros
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
“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
- 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.
https://github.com/projectured/projectured/blob/unstable/test/content.lisp#L326
https://github.com/projectured/projectured/blob/unstable/test/projection.lisp#L696
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
http://vpri.org/mailman/listinfo/fonc

[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 <

Post by Levente Mészáros
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
“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
- 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.
https://github.com/projectured/projectured/blob/unstable/test/content.lisp#L326
https://github.com/projectured/projectured/blob/unstable/test/projection.lisp#L696
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
http://vpri.org/mailman/listinfo/fonc

[Faré]

Dear Levy,

“Programs must be written for people to read, and only incidentally for
machines to execute.”
-- Hal Abelson, Structure and Interpretation of Computer Programs

As Henry Baker put it (long afterward), "[A] Computer [programming]
language is inherently a pun -- [it] needs to be interpreted by both
men & machines."

I think people working on a complex program
- have different [...]

different points of view. And even the same person has multiple points
of view at different moments.

I think people need better tools that provide different presentations of the
same complex program [...]

I like to call them points of view.

I suppose you are familiar with the work of that other Hungarian guy,
Charles Simonyi, on Intentional Programming. Our common friend Attila
L. worked briefly with him. That was his general idea, and he still
has working prototypes (he's also very much a proprietary software guy
and a control freak).

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."

Your super structure editor will have work that grows super-linearly
with the number of points of views that you're interested in and
number of non-trivial bridges between them. That's a lot of work, and
it soon requires many people, who are non-trivial to coordinate.

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.

It might not be impossible to beat the text editor, but that'll be
mighty hard, and probably very domain-specific. Doing it will 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, but surely knows how to coordinate
hackers, at la Linus.

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").

Wiki: https://github.com/projectured/projectured/wiki
Project home: http://projectured.org/

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Intentions are not so much direct descriptions of actual mind processes as
Schelling points in the way social animals communicate.

[David Barbour]

Post by Faré

Post by Levente Mészáros
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.).

Post by Faré
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.

Post by Faré

Post by Levente Mészáros
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

[Levente Mészáros]

Post by David Barbour
What model do you use for projectional editing? Lenses or something else?

AFAICT my approach is somewhat similar to lenses but it's obviously
less formal and more organic in the sense of being evolved according
to my needs.

This wiki page explains some concepts (printer, reader, etc.) I used
in the projections:
https://github.com/projectured/projectured/wiki/Projection

I think another interesting part is how the generalized REPL uses the
printer and the reader algorithms described above:
https://github.com/projectured/projectured/wiki/Overview#how-does-the-projectional-editor-work-internally

Best regards,
Levente Mészáros

[Levente Mészáros]

Dear Faré,

Post by Faré
different points of view. And even the same person has multiple points
of view at different moments.

You're absolutely right, and I only left this very important point out
accidentally... For example, I could use a projection that allows me
editing all function calls to a particular function including the
lexical contexts they appear in, or another projection that allows me
editing all methods of a particular generic function together, or one
that allows me editing the body of some functions inlined into their
call site, etc.

You're also right about how difficult it is to beat or just to even be
on a par with text editors while editing text. On the other hand I
don't quite agree with the difficulty analysis you gave because you
ignore the fact that you are talking about different set of features
when comparing the possible point of views provided by text and
structure editors.

Post by Faré
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

I don't really see any difference in this regard between text editors
and structure editors. How do you reconcile some text changes properly
that really represent something more abstract? I think that's even
harder to do correctly with text: just think about renaming a function
while somebody else swaps it with another. Current version control
systems fail miserably in this very simple case. After all, any change
you do through any projection using a projectional editor will be
represented in the document that is being edited. So I think if there
are concurrent edits to the same document there must be some way of
merging them either automatically or manually (transactions,
versioning, conflict resolution, etc.).

Best regards,
Levente Mészáros

[Attila Lendvai]

FYI, there's a new demo video:

it's basically demoing the editing of the source code of a website
(all kinds of domains mixed into one document), that at the end gets
rendered into valid CL code, and into a working website.

there have also been some cleanups and code reorg, so running the code
is reasonably simple now (using quicklisp).

https://github.com/projectured/projectured

[Aaron Gray]

Hi,

To me model is core whether be represented in text, XML, or binary,
but preferably binary. It might even be accessed over a network via
sockets from a model server allowing multiple users and processes to
access the model.

The model can contain different information types, be viewed in
different forms using different techniques and programs.

The model should be described by a meta model, this allows the model
to be bounded and able to be more that just random data formats. This
makes it easier for different programs to interact with the data over
a socket via an API.

The meta model itself should be meta and described in itself, and
possibly lifted by another lower level model used for its
implementation and API access.

Yes text files suck !

Post by Attila Lendvai
http://youtu.be/s05SlmZ7ZPc
it's basically demoing the editing of the source code of a website
(all kinds of domains mixed into one document), that at the end gets
rendered into valid CL code, and into a working website.
there have also been some cleanups and code reorg, so running the code
is reasonably simple now (using quicklisp).
https://github.com/projectured/projectured
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The direct use of physical force is so poor a solution to the problem
of limited resources that it is commonly employed only by small
children and great nations.”
— David D. Friedman (1945–), 'The Machinery of Freedom' (1973)
_______________________________________________
Fonc mailing list
http://mailman.vpri.org/mailman/listinfo/fonc_mailman.vpri.org

[Julian Leviston]

This breaks down when you want to use it in a language that has constructs that aren’t possible to model in the primary implementation language.

In other words, what do you do with the dynamic types / static types problem?

The entire model code needs to be able to be represented in its own data format, a la LISP, but also able to be statically type-checked, how do you do this, if it’s meta-recursive? If so, the problem of “how do you represent code in data” arises. Code is not data, yet it is. One could say code is data that the computer decided to execute. This forms a problem because of the semantics of the data.

The bulk of the FoNC project was created as a set of mini-languages described in OMeta as the meta-language. This *has* to be a better way than spending hundreds of thousands of lines of code just to describe an editor, no?

Wasn’t structural editing implicit in the FoNC project? Structural editing is simply semantic editing.

The trouble with representing this stuff is that you generally get tied to a particular implementation at some point if you want to do anything useful, I think. OMeta “solves” this by being a symbiotic/hybrid language with a host language that you express functionality in.

In my explorations of doing similar things I’ve had to use a data-named “bottom” point for all of the functionality that I’ve wanted to include, (a transfer point between built-in functionality and functionality constructed by composition of these base elements), which is less than ideal I suppose, though the alternative seems to be not type-checking your code, which is worse.

All of this stuff seems to be circling around how we can integrate these two worlds: type safety, and dynamic types. I think most runtime and syntax errors should be a thing of the past, and yes, structural editing would solve all syntax errors. As to semantic errors (type errors), I’m not sure.

Julian

Post by Aaron Gray
Hi,
To me model is core whether be represented in text, XML, or binary,
but preferably binary. It might even be accessed over a network via
sockets from a model server allowing multiple users and processes to
access the model.
The model can contain different information types, be viewed in
different forms using different techniques and programs.
The model should be described by a meta model, this allows the model
to be bounded and able to be more that just random data formats. This
makes it easier for different programs to interact with the data over
a socket via an API.
The meta model itself should be meta and described in itself, and
possibly lifted by another lower level model used for its
implementation and API access.
Yes text files suck !

Post by Attila Lendvai
http://youtu.be/s05SlmZ7ZPc
it's basically demoing the editing of the source code of a website
(all kinds of domains mixed into one document), that at the end gets
rendered into valid CL code, and into a working website.
there have also been some cleanups and code reorg, so running the code
is reasonably simple now (using quicklisp).
https://github.com/projectured/projectured
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The direct use of physical force is so poor a solution to the problem
of limited resources that it is commonly employed only by small
children and great nations.”
— David D. Friedman (1945–), 'The Machinery of Freedom' (1973)
_______________________________________________
Fonc mailing list
http://mailman.vpri.org/mailman/listinfo/fonc_mailman.vpri.org

_______________________________________________
Fonc mailing list
http://mailman.vpri.org/mailman/listinfo/fonc_mailman.vpri.org

[Aaron Gray]

Type checking is a semantic problem it would be just implemented as a
facility in the meta system. The core is language neutral.

Post by Julian Leviston
This breaks down when you want to use it in a language that has constructs
that aren’t possible to model in the primary implementation language.
In other words, what do you do with the dynamic types / static types problem?
The entire model code needs to be able to be represented in its own data
format, a la LISP, but also able to be statically type-checked, how do you
do this, if it’s meta-recursive? If so, the problem of “how do you represent
code in data” arises. Code is not data, yet it is. One could say code is
data that the computer decided to execute. This forms a problem because of
the semantics of the data.
The bulk of the FoNC project was created as a set of mini-languages
described in OMeta as the meta-language. This *has* to be a better way than
spending hundreds of thousands of lines of code just to describe an editor,
no?
Wasn’t structural editing implicit in the FoNC project? Structural editing
is simply semantic editing.
The trouble with representing this stuff is that you generally get tied to a
particular implementation at some point if you want to do anything useful, I
think. OMeta “solves” this by being a symbiotic/hybrid language with a host
language that you express functionality in.
In my explorations of doing similar things I’ve had to use a data-named
“bottom” point for all of the functionality that I’ve wanted to include, (a
transfer point between built-in functionality and functionality constructed
by composition of these base elements), which is less than ideal I suppose,
though the alternative seems to be not type-checking your code, which is
worse.
All of this stuff seems to be circling around how we can integrate these two
worlds: type safety, and dynamic types. I think most runtime and syntax
errors should be a thing of the past, and yes, structural editing would
solve all syntax errors. As to semantic errors (type errors), I’m not sure.
Julian
Hi,
To me model is core whether be represented in text, XML, or binary,
but preferably binary. It might even be accessed over a network via
sockets from a model server allowing multiple users and processes to
access the model.
The model can contain different information types, be viewed in
different forms using different techniques and programs.
The model should be described by a meta model, this allows the model
to be bounded and able to be more that just random data formats. This
makes it easier for different programs to interact with the data over
a socket via an API.
The meta model itself should be meta and described in itself, and
possibly lifted by another lower level model used for its
implementation and API access.
Yes text files suck !
http://youtu.be/s05SlmZ7ZPc
it's basically demoing the editing of the source code of a website
(all kinds of domains mixed into one document), that at the end gets
rendered into valid CL code, and into a working website.
there have also been some cleanups and code reorg, so running the code
is reasonably simple now (using quicklisp).
https://github.com/projectured/projectured
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The direct use of physical force is so poor a solution to the problem
of limited resources that it is commonly employed only by small
children and great nations.”
— David D. Friedman (1945–), 'The Machinery of Freedom' (1973)
_______________________________________________
Fonc mailing list
http://mailman.vpri.org/mailman/listinfo/fonc_mailman.vpri.org
_______________________________________________
Fonc mailing list
http://mailman.vpri.org/mailman/listinfo/fonc_mailman.vpri.org