Anyone ever hear of Doug Engelbart? Ever type his name into Google? Ever looked
to see how the code and documentation for his system was organized?
Cheers,
Alan
________________________________
From: BGB <cr88...@hotmail.com>
To: Fundamentals of New Computing <fonc@vpri.org>
Sent: Mon, May 10, 2010 5:50:31 PM
Subject: Re: [fonc] Program representation
----- Original Message -----
>From: John Nilsson
>To: Fundamentals of New Computing
>Sent: Monday, May 10, 2010 3:33 PM
>Subject: Re: [fonc] Program
> representation
>
>
>
>On Mon, May 10, 2010 at 11:29 PM, BGB <cr88...@hotmail.com> >wrote:
>
>like having documentation in a hypertext form,
>> and having code contain links into the docs, and from the docs back into
>> the
>> code?...
>For example.
>
I don't know of an example...
I guess something like this could be done by an IDE
and using XML, but I don't know of an IDE which does this.
Visual Studio allows putting XML into doc
comments for sake of documentation-writing, but this is different.
I am I guess imagining having a much closer
connection between the docs and code, which is a little different (although the
basic mechanism is similar).
a little lighter-weight could be to use wiki-style
references:
/* See [[MyApp.Docs.Foo]] for further info on
this. */
this defining a comment containing an external
link.
or, for purely external comments:
/*[[MyApp.Focs.Bar]]*/
which the IDE could see as a normal comment, but it
is located elsewhere.
/**[[MyApp.Focs.Baz]]*/
would be similar, but work more like doc-comments
and assert that the following item is documented by the referenced
item.
the documentation system could in general be
structured somewhat after a wiki.
>I guess it
>> would be a notable improvement on having to edit external files for the
>> documents, and an improvement on javadocs-style comments (which make code
>> less readable by sticking large gobs of text in the middle of
>> it...).
>Another improvement would be to get rid of the inherent
> ordering and context of a text file. Instead one could surround a piece of
> code, i.e. a method, with context relevant that piece such as dependencies,
> usages, supplements and complements. The code bubbles project is very
> interesting in that regard.
>
yep, this depends a lot on the
language structure and semantics.
for example, a language could use
namespaces, and support multiple namespaces per file.
namespace Foo {
... stuff
scoped in Foo ...
}
namespace Bar {
... stuff for
bar ...
}
namespace Foo {
... more stuff
in Foo ...
}
AFAIK, C# can be used like this,
but this is not the common practice (where typically source files are organized
along with their respective namespaces, and it is more common to have a single
namespace spread between several related files, rather than multiple namespaces
in a single file...).
dependencies can also be
given via "using", which can be placed either within the namespace, or
within the toplevel (although AFAIK with different semantics).
for BGBScript I have considered a
similar feature, although I am more borrowing from ActionScript's
syntax:
package Foo {
import
Bar;
...
}
one oddity though is that I may
actually allow multiple "toplevels", each of which potentially having
potentially different collections of packages/namespaces.
it will not be possible to
reference between one toplevel and another, rather only references may be
passed.
unlike many existing languages,
the toplevel is not assumed to be absolute.
the idea is that this will allow
creating toplevels which have less access to the rest of the app, such as to
allow for sandboxing. for example, the default toplevel can see directly into
the C toplevel, but an app may have reason to create a more restricted
toplevel,
which will only be able to see namespaces which it is given (likely excluding
the C toplevel).
the idea here is that binding
environments are also first-class objects (so, a namespace is not so much a
location in some fixed tree-structure, rather a path through a series of slots
relative to some known location).
however, there are still some
technical issues to be addressed here...
note:
an issue at present is that some
code (ordinary functions) are use dynamic-scoping for the toplevel, whereas
closures use lexical scoping for the toplevel (later, both may be made to
be lexically-bound).
note that even though the locals
and toplevel are semantically lexically-scoped, both use a different way of
implementing the bindings.
>well, I guess some people like flowcharts/...,
>> but personally I don't like them all that much (or, at least on the
>> small-scale). I can more easily imagine them being used to describe
>> things
>> like library dependencies, ... but, when used to describe code,
>> one almost may as well just be using
>> assembler...
>
>
>Have a look at Conal Elliotts Tangible Functional
> Programming
> http://conal.net/blog/posts/tangible-functional-programming-a-modern-marriage-of-usability-and-composability/
> he
> has some interesting examples of a style of visual programming that might
> actually be useful.
>
yes, will have to look at
this...
I was more thinking about
traditional program-charts, which personally seem not all that good of a way of
doing this, given the very low density of this representation, and level of
effort needed to make them, ...
psudeocode, plain-language
descriptions, ... each seem like a much better strategy...
granted, flowcharts make a lot
more sense for much higher-level organizational-charts and
similar...
but, all this may just be my own
personal opinion...
>
>BR,
>John
________________________________
> _______________________________________________
>fonc mailing
> list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
