subject:"Re\: \[fonc\] Alternative Web programming models\?"

On 6/19/2011 9:49 PM, Julian Leviston wrote:

On 20/06/2011, at 2:33 PM, BGB wrote:

in a sense, the metaphor no longer works, and should likely itself be left to
fall into the recycle-bin of history. worse yet is having to read stuff written
by people who actually take this metaphor seriously.

Given the historical perspective, it was appropriate at the time. These days, our
computers are so vastly scaled beyond the original intention of the file
metaphor that it's getting silly, I'd grant you that.

yep.

It's not really any surprise, then, that Apple's trying to get rid of the file system,
is it? :) Mind you, I think the app metaphor is just as crappy, personally. I like the
idea of workflows much more, and combining a few small simple tools together to get some particular
job done.

interestingly, I don't believe in getting rid of the file-system,
per-se, as technically it works fairly well and is a proven piece of
technology.

but, mostly, I just want the filing-cabinet metaphor to go away, if
anything, so that people making stupid computer/filing-cabinet analogies
will go away, or worse yet, talking about computers implying that they
themselves are subject to the same sort of limitations as filing
cabinets, or describing technical limitations WRT computers and data
storage which haven't really been the case since maybe the 70s or 80s...
(such as claiming that files are simply collections of fixed-format
records and are unable to store heterogeneous data, leaving me to think
WTF?...).

if I could make any notable change to how filesystems worked, it would
be likely to introduce user-defined VFS systems as an OS-level facility.

this would mean one of several things:
ability to more easily introduce user-defined virtual directories as a
part of the host operating file-system (as is, on both Windows and
Linux, it is a little nasty...);
ability to run apps (and parts of apps) inside of custom VFS's (more
like finer-grained chroot);
potentially a virtual mount facility, where an app can locally
mount/unmount volumes it has rights to, and can choose whether or not
they are visible to the external OS (say, an app might mount its own
data-files as volumes, and choose that only itself can see them);

...

as-is, it is generally less nasty to do this within the app, essentially
having the app provide its own VFS and drivers (for example, my project
can mount zip-files as volumes, including for random read/write, albeit
with a few limitations...).

going more extreme, one could begin to blur the line between files and
in-program objects and code (say, packages, functions/methods/variables,
... could be potentially visible as part of the VFS).
implementation-wise, there is likely to be a layer of separation above
the true filesystem (this would introduce a huge number of tiny files
which would not map effectively onto most existing filesystems, and so
it would seem better to introduce this as a virtual mount).

another possible idea could be to go from a traditional
mount/unmount/fstab style system, to possibly supporting a mechanism
partway between mounts and symlinks (one doesn't mount a volume, they
link to it...). I am partly imagining links partway between
Unix-style symlinks, and the links supported by Windows, but with more
features (such as ability to mount something via accessing a link, or
redirect to a network resource such as a CIFS/HTTP/WebDav/FTP share).

and, for something like the prior concept, they can create a link from a
directory into a program, allowing the program to fill a role partway
between being an application, an FS driver, and an OS service.

taken further, this could also potentially be partly used as an
alternative to traditional DLL/shared-library and IPC/RPC mechanics as
well (could get hairy, primarily if C/C++ and data sharing are involved,
potentially limiting to high-level managed types, which may either be
copied or passed as handles...).

worst case for the above, probably can't be too much worse than MS's COM
system (COM / COM+ / DCOM).

a proper HLL could probably mostly hide the underlying mechanisms.

trivia:
in a much-older version of my projects, it was possible to open network
sockets purely via a VFS vffopen() operation, but this feature later
died with a rewrite of my VFS mechanism some years back (I may
eventually re-add it, possibly among several other VFS features, namely
cached HTTP mounts and ability to support virtual file encryption).

basically, the rewrite partly broke my ability to route network sockets
over the local VFS (in general), as well as several other things.

my code also generally works within a local VFS, rather than directly
using the OS provided FS facilities. the VFS is actually one of the
oldest parts of my codebase (dating to sometime around the late 90s...).

For example, when web programming on a specific web app, I use a web browser, a text editor, a

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)


On 20/06/2011, at 4:33 PM, BGB wrote:

 interestingly, I don't believe in getting rid of the file-system, per-se, as 
 technically it works fairly well and is a proven piece of technology.

Interestingly, I disagree entirely. Finding things is a pain for most people 
(including myself).

Julian.


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)


On 20/06/2011, at 4:33 PM, BGB wrote:

 For example, when web programming on a specific web app, I use a web 
 browser, a text editor, a database management program, a command line, and a 
 couple other tools. It'd be nice to be able to fit these tools together 
 into a pseudo-app and then build documents for this pseudo-app... that 
 were accessible within the pseudo-app (ie not the file system) to use 
 Apple's idea, and that could simply do all the things I generally need to 
 do... (there are only a few tasks I generally do and none of them 
 correlate directly into any one particular application).
 
 I love the way I edit text in my one particular text editor. Why do I have 
 to use a different editor to edit my email text? lol... it makes little 
 sense.
 
 well, mostly I am using Windows Explorer and the shell (both CMD and Bash) 
 for managing things on Windows, and this setup works adequately.
 
 admittedly, I am not entirely sure how the idea you are describing will work, 
 so maybe it can be described in more detail? (like, what parts it may contain 
 and how they may fit together...).
 


Perhaps you might take a look at Panic's Coda

http://www.panic.com/coda/

This is *one instance* of what I'm talking about generally... it does for most 
web developers what I was describing... but I'm talking about having a more 
modular approach in that you should be able to build a tool that incorporates 
other things, too (for example, I might decide I want a particular 
colour-picker in there, or a specific interactive language reference or API 
reference, or perhaps I'd like to have some form of rudimentary image editing, 
because I do that in my work).

You get me?

Julian.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)


On 6/19/2011 11:54 PM, Julian Leviston wrote:

On 20/06/2011, at 4:33 PM, BGB wrote:


interestingly, I don't believe in getting rid of the file-system, per-se, as 
technically it works fairly well and is a proven piece of technology.

Interestingly, I disagree entirely. Finding things is a pain for most people 
(including myself).



a relevant distinction can be made though:
for the user;
or, for programs...

it is like, for programs, systems with a structure similar to the 
Windows System Registry are very useful, but for users, they can 
become hopelessly confused, and naive changes risk irreparably breaking 
the OS...


(one of my first personal major encounters with the System Registry had, 
at the time, rendered the computer unable to boot...).



Unix-style single-root-mount systems are IMO most convenient from a 
software-development perspective, albeit they have a few present severe 
limitations (mostly that it is nearly impossible to keep applications 
and the OS separate), as apparently Unix and Linux were designed with 
it in mind that apparently of course, user applications and data will 
go in /usr/bin and /usr/var and similar, and system applications and 
data in /bin and /var


a few features I sort of wish Linux had:
~/bin, ~/var, ~/etc, ... (or: ~/.usr/bin, ~/.usr/var, ~/.usr/etc, ...), 
which would be used for per-user programs and settings (vs the current 
mess that ~ tends to become);
a shared-object system which looked up SO's more like Windows does DLLs 
(largely eliminating the need for rpath and similar);

...

a Unix-style organization for a VFS is fairly helpful though.


for users, it is different:

MS partly does the whole My Documents thing, I guess as an effort to 
simplify things for newbies (albeit, IMO, they did it poorly).


one possibility would be organizing the filesystem differently for the 
user and for the OS.


...


in my case, I have a personal file-management system which mostly 
prevents me losing stuff, but is technically a fairly 
complex/bureaucratic process (would be difficult to really elaborate on).


OTOH, my dad just sort of naively organizes things in a deep hierarchy 
based on associations, and so tends to loose stuff fairly often.



or such...


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-20 Thread Steve Dekorte


On 2011-06-19 Sun, at 09:33 PM, BGB wrote:
 .. which mappings are more natural and under which circumstances seems to be 
 the important question and one, AFAICS, that may not well answered by simply 
 replacing words with ideograms and expressions with boxes and arrows.
 
 agreed... I really don't believe graphical solutions are necessarily ideal.
 
 but, at the same time, there is also the matter of finding the right tool 
 for the job.
 
 for example, code works great for expression program logic, but falls flat 
 for many other tasks:
 creating a graphical image;
 creating a 3D model or scene;
 ...
 
 in these cases, having more specialized tools tends to be far more effective.

I agree and notice that none of the good solutions we have for those involve 
ideograms and... boxes and arrows. It's as if compsci culture is unable to 
let go of flow charts, even if they aren't used for constructing complex 
circuits anymore which (AFAIK) was the inspiration for their use.


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

On 6/19/2011 11:58 PM, Julian Leviston wrote:

On 20/06/2011, at 4:33 PM, BGB wrote:

For example, when web programming on a specific web app, I use a web browser, a text editor, a database
management program, a command line, and a couple other tools. It'd be nice to be able to fit these
tools together into a pseudo-app and then build documents for this pseudo-app... that were
accessible within the pseudo-app (ie not the file system) to use Apple's idea, and that could simply do all
the things I generally need to do... (there are only a few tasks I generally do and none of them
correlate directly into any one particular application).

I love the way I edit text in my one particular text editor. Why do I have to
use a different editor to edit my email text? lol... it makes little sense.

well, mostly I am using Windows Explorer and the shell (both CMD and Bash) for managing
things on Windows, and this setup works adequately.

admittedly, I am not entirely sure how the idea you are describing will work,
so maybe it can be described in more detail? (like, what parts it may contain
and how they may fit together...).

Perhaps you might take a look at Panic's Coda

http://www.panic.com/coda/

This is *one instance* of what I'm talking about generally... it does for most
web developers what I was describing... but I'm talking about having a more
modular approach in that you should be able to build a tool that incorporates
other things, too (for example, I might decide I want a particular
colour-picker in there, or a specific interactive language reference or API
reference, or perhaps I'd like to have some form of rudimentary image editing,
because I do that in my work).

You get me?

errm, the modular part sort of sounds like what OLE and COM were meant
to be (although presumably without all the MS or the suck, and ideally
without big security holes like putting virus-laden ActiveX controls in
emails...).

the linked-to site sort of sounds like an IDE or something...

I am not certain I follow how this would get rid of file-systems though...
I am not aware of any good alternative to the filesystem which is
generally better than the filesystem (can effectively manage huge
numbers of files and multiple TB of disk space, can effectively
multiplex between a large number of apps, and still is accessible to
mere humans, ...).

also, the vast majority of existing software would break if no FS were
available.

although, there are things which are lacking with traditional OS-level
filesystems:
ability to have localized and customized filesystems (usually done via
app-local VFS's);
ability to easily sandbox or virtualize the filesystem (apart from
fairly heavy-handed/costly mechanisms, such as chroot);
ability to see into app-internal data (can be handled via FUSE on
Linux, but AFAIK there is no good analogue for Windows);
generally require jerkoff to access network resources (although GVFS
does this, but the Linux VFS requires mounts, and Windows requires
mount as drive letter or using Win32 API calls to be able to access
UNC files, which for who-knows-what-reason don't seem to work with
fopen/fclose or open/close last I checked, and instead require using
OpenFile or such...);

...

sadly, the least nasty (IMO) option is essentially to just have ones'
program provide and use its own VFS internally...

actually, Steam also does this (for one who wants their apps to work
with GCF files) but sadly the process of connecting to the Steam VFS is
... nasty...

hence, even then, one still needs their own VFS...

or such...

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)


On 6/20/2011 2:19 AM, Julian Leviston wrote:

On 20/06/2011, at 6:33 PM, BGB wrote:


I am not certain I follow how this would get rid of file-systems though...
I am not aware of any good alternative to the filesystem which is generally 
better than the filesystem (can effectively manage huge numbers of files and 
multiple TB of disk space, can effectively multiplex between a large number of 
apps, and still is accessible to mere humans, ...).

Really? So you don't like the idea of an application managing its own content? 
Effectively saying hey, let's store our data with our code... which is the 
encapsulation pattern of OOP isn't it?


I missed wherever this was mentioned...
but, no, this is not generally ideal either IMO.


if an image-based strategy, it is my personal belief that these are 
unlikely to (in themselves) be a general-purpose workable strategy (if 
contrasted with a file-based, or file-backed strategy).


databases are sort of a compromise IMO, as then one can store their data 
in a database, and fetch it back out. IMO, this is better with 
hierarchical (registry-like databases) though, as IMO most generic 
data-storage tasks are a poor match for an RDBMS (since it is generally 
a pain to put data into or get it out of an RDBMS), but an HDB usually 
matches a little more closely with application data-storage tasks IME.


in the case of my BGBScript language, the HDB actually forms a fairly 
important part of the underlying structure of the VM.


but, a database is still stored as files...


I guess XML is also possible/popular, but I am not aware of any 
particularly scalable way to access/query/... lots of XML-based data 
(and a DB which quickly bogs down is not exactly ideal...).


also, by itself, XML isn't terribly easy to work with either...


hmm... S-Expression database?...
sort of like a hybrid between a database and a persistent store.


or such...


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)


On 20/06/2011, at 8:06 PM, BGB wrote:

 hmm... S-Expression database?...
 sort of like a hybrid between a database and a persistent store.
 
 
 or such...


I'd like to know if you think there's a difference between a filesystem and a 
database... conceptually...

or such...
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)


On 6/20/2011 3:22 AM, Julian Leviston wrote:

On 20/06/2011, at 8:06 PM, BGB wrote:


hmm... S-Expression database?...
sort of like a hybrid between a database and a persistent store.


or such...


I'd like to know if you think there's a difference between a filesystem and a 
database... conceptually...

or such...


interesting thought...

well, filesystems are generally hierarchical, don't generally support 
user-defined fields, and store all data as large binary globs. some 
filesystems (such as HFS/HFS+ and NTFS) allow multiple forks per file, 
others don't (FAT32 / EXT* / ...).


generally, filesystems store data in terms of disk-blocks, and often 
make little/no provision for tiny files (partial exception being EXT* 
and ReiserFS, the former supporting inlining the contents of small files 
into the inode, the latter supporting the storage of sub-block files 
into B+Tree leaves).



databases may come in any number of varieties, and generally store 
structured or semi-structured information;
the contents of a database are generally individual datums, rather than 
binary globs;

typically, databases store contents according to user-defined structures;
typically, databases are stored using structures such as B+Trees;
...


for example, the HDB used for my VM framework has a structure like:
each node is identified by a path, generally with a POSIX-style name 
foo/bar/baz;
each node may contain a number of key/value pairs, with a special 
null/default key internally named '_', and the key is identified 
following ':', and sometimes key indices are used following a '.', ...

stored values are generally untyped, and treated as if they were strings.

foo/bar/baz:name
node: foo/bar/baz
key: name
foo/bar/baz:item.3
node: foo/bar/baz
key: item
index: 3

the index allows treating the key like a small array.

possible, but not currently supported (at least not efficiently) would 
be to apply an index to a node, allowing treating the node as a 
makeshift indexed table:

foo/bar/baz.59:name

the optimization would be to transform the above into a key-index:
foo/bar/baz:name.59, allowing for storing the values as arrays.

however, in this case, table-like nodes would not allow for indexed keys:
foo/bar/baz.59:item.5
since this would require double-indexing, but the keys are presently 
only defined as 1D arrays.


at present, this will work, as the node index would just store multiple 
nodes with dotted names (baz.59 will simply be interpreted as a nodes' 
name).


as-is, node names may also begin with '.', however these nodes are 
treated as volatile and effectively will not be saved back into the 
database (this mechanism is generally used for storing volatile 
information, namely information about things like environment variables, 
which libraries or modules are currently loaded, ...).


so .var/foo:name is volatile, as neither .var nor any of its 
children will be saved to disk.



note:
the present system does not allow for non-trivial queries (besides 
?next, ?prev, ...), but interestingly, for most uses of this system, 
one doesn't generally need to perform queries (much like, for the most 
part, application code doesn't really need readdir either, since its 
main use is mostly for presenting directory listings to the user).


it is worth noting that the design of this system was originally partly 
inspired by the Windows Registry, but there are differences (the nodes 
being untyped, and the use of '/' rather than '\', and the present lack 
of hives albeit a similar mechanism may be needed for other reasons, 
and may need to be retrofitted on, that or supporting in-database 
mounts and links...).


the external serialized database format somewhat resembles '.reg' files 
(albeit, technically if .reg and .ini files hybridized).


unlike more proper databases, the current implementation uses AVL trees 
rather than B+Trees internally. the main reason for AVL trees was that 
they were less effort to implement (actually, it is a tree of AVL trees, 
as each node-level starts a new AVL tree).
the internal structure of the code for managing the HDB is a bit nasty, 
luckily, nearly all access is via named path-strings (the path-key then 
is its canonical structure, and all of the mucking around with AVL 
trees/... is hidden behind the API).


as I think noted previously, the main reason I chose an HDB style design 
(rather than an RDB / Relational Database) was because an HDB is 
generally much easier to work with via a programmatic interface, whereas 
working with relational databases is a bit more painful, as nearly every 
operation will involve queries and having to work with tables or similar...



or such...


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

Hi... (see below)...

On 21/06/2011, at 3:42 AM, BGB wrote:

 On 6/20/2011 3:22 AM, Julian Leviston wrote:
 On 20/06/2011, at 8:06 PM, BGB wrote:
 
 hmm... S-Expression database?...
 sort of like a hybrid between a database and a persistent store.
 
 
 or such...
 
 I'd like to know if you think there's a difference between a filesystem and 
 a database... conceptually...
 
 or such...
 
 interesting thought...
 

Note that I asked if you think there's a difference not how they differ. I'd be 
surprised if there were any people on this list who didn't know how they 
differed.

I don't consider there to be much of a difference between the two, conceptually 
- they are both concerned with the retrieval and storage of data (I'm using the 
term 'data' here to mean any form of raw information at all, useful or 
otherwise, including programs).

 well, filesystems are generally hierarchical, don't generally support 
 user-defined fields, and store all data as large binary globs. some 
 filesystems (such as HFS/HFS+ and NTFS) allow multiple forks per file, others 
 don't (FAT32 / EXT* / ...).
 
 generally, filesystems store data in terms of disk-blocks, and often make 
 little/no provision for tiny files (partial exception being EXT* and 
 ReiserFS, the former supporting inlining the contents of small files into the 
 inode, the latter supporting the storage of sub-block files into B+Tree 
 leaves).
 
 
 databases may come in any number of varieties, and generally store structured 
 or semi-structured information;
 the contents of a database are generally individual datums, rather than 
 binary globs;
 typically, databases store contents according to user-defined structures;
 typically, databases are stored using structures such as B+Trees;
 ...
 
 
 for example, the HDB used for my VM framework has a structure like:
 each node is identified by a path, generally with a POSIX-style name 
 foo/bar/baz;
 each node may contain a number of key/value pairs, with a special 
 null/default key internally named '_', and the key is identified following 
 ':', and sometimes key indices are used following a '.', ...
 stored values are generally untyped, and treated as if they were strings.
 
 foo/bar/baz:name
node: foo/bar/baz
key: name
 foo/bar/baz:item.3
node: foo/bar/baz
key: item
index: 3
 
 the index allows treating the key like a small array.
 
 possible, but not currently supported (at least not efficiently) would be to 
 apply an index to a node, allowing treating the node as a makeshift indexed 
 table:
 foo/bar/baz.59:name
 
 the optimization would be to transform the above into a key-index:
 foo/bar/baz:name.59, allowing for storing the values as arrays.
 
 however, in this case, table-like nodes would not allow for indexed keys:
 foo/bar/baz.59:item.5
 since this would require double-indexing, but the keys are presently only 
 defined as 1D arrays.
 
 at present, this will work, as the node index would just store multiple nodes 
 with dotted names (baz.59 will simply be interpreted as a nodes' name).
 
 as-is, node names may also begin with '.', however these nodes are treated as 
 volatile and effectively will not be saved back into the database (this 
 mechanism is generally used for storing volatile information, namely 
 information about things like environment variables, which libraries or 
 modules are currently loaded, ...).
 
 so .var/foo:name is volatile, as neither .var nor any of its children 
 will be saved to disk.
 
 
 note:
 the present system does not allow for non-trivial queries (besides ?next, 
 ?prev, ...), but interestingly, for most uses of this system, one doesn't 
 generally need to perform queries (much like, for the most part, application 
 code doesn't really need readdir either, since its main use is mostly for 
 presenting directory listings to the user).
 
 it is worth noting that the design of this system was originally partly 
 inspired by the Windows Registry, but there are differences (the nodes being 
 untyped, and the use of '/' rather than '\', and the present lack of hives 
 albeit a similar mechanism may be needed for other reasons, and may need to 
 be retrofitted on, that or supporting in-database mounts and links...).
 
 the external serialized database format somewhat resembles '.reg' files 
 (albeit, technically if .reg and .ini files hybridized).
 
 unlike more proper databases, the current implementation uses AVL trees 
 rather than B+Trees internally. the main reason for AVL trees was that they 
 were less effort to implement (actually, it is a tree of AVL trees, as each 
 node-level starts a new AVL tree).
 the internal structure of the code for managing the HDB is a bit nasty, 
 luckily, nearly all access is via named path-strings (the path-key then is 
 its canonical structure, and all of the mucking around with AVL trees/... is 
 hidden behind the API).
 
 as I think noted previously, the main reason I chose an HDB style design 
 (rather than

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-19 Thread Steve Dekorte


On 2011-06-14 Tue, at 09:36 PM, Julian Leviston wrote:
 The thing that irritates me about this attitude of don't consider kids as 
 equal is that we DO consider them as equal in other frames... we expect so 
 much of them in terms of linguistic and cognitive development... and actually 
 the abstractions (zero-th order abstraction) capable of and exhibited by a 5 
 year old are used when in the activity called programming all the time... 
 so much so we as adult programmers rarely think about them.

I agree. People seem to define smart as something like things I can't do 
easily. So, for example, if they can use a keyboard, well someone like a child 
who can't must not be smart and this is why people were surprised when the 
mouse and graphical UIs allowed toddlers to use the Mac or touch screens 
allowed near infants to use iPads today. All along it was an issue of unnatural 
conceptual mapping (like asking a right handed person to throw with their left 
hand) that was the problem, not a lack of smarts. 

From this perspective we could see the history of programming as one of finding 
ever more natural mappings between how our minds work and how we can get 
machines to do what we want - just as steering wheel and floor pedals map 
between our bodies and our vehicles. If so, which mappings are more natural and 
under which circumstances seems to be the important question and one, AFAICS, 
that may not well answered by simply replacing words with ideograms and 
expressions with boxes and arrows.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-19 Thread Julian Leviston


On 20/06/2011, at 12:20 PM, Steve Dekorte wrote:

 From this perspective we could see the history of programming as one of 
 finding ever more natural mappings between how our minds work and how we can 
 get machines to do what we want - just as steering wheel and floor pedals map 
 between our bodies and our vehicles. If so, which mappings are more natural 
 and under which circumstances seems to be the important question and one, 
 AFAICS, that may not well answered by simply replacing words with ideograms 
 and expressions with boxes and arrows.

Or even - might I proffer - that mapping are fairly arbitrary by their very 
nature, and therefore perhaps the mappings should be able to be inspected, 
translated between, and even completely reworked or added to as deemed fit. One 
of the issues that immediately springs from this is that as programmers of 
incredibly large (in terms of complexity) computers which don't offer physical 
switches, it's almost impossible to escape this abstract mapping, because the 
tools used to deal even directly with what makes up a computer involve a large 
amount of mapping (always at least two). It's not like we can switch switches 
anymore! In other words, the programming interfaces are virtual.

We're always modelling. We need to also be CONTEXTUALLY EXPLAINING what the 
models are as we're modelling (ie baked into the modelling process, even) them 
so that people trying to understand the models (artefacts of our processes) can 
hold them in the right contextual frame. (Holding something in the right 
contextual frame is another name for understanding).

What I'm stipulating, is not replacing words with ideograms and expressions 
with boxes and arrows, but building a representation (a visual mapping) such 
that it's immediately obvious what the intent of the objects in a system are 
doing. For example, if you have two numbers, then the numbers get visually 
transformed each to a set of dots with a perimeter (border) around them, and 
they're animated towards each other and the border becomes one border, and the 
dots all join into the one set... and then that set is animated into the sum of 
the two original numbers, this is *A* visual representation of addition. (note 
that there are definitely many others - there are many methods to doing 
something just as there are in other places in computing, and just as there are 
many styles to learning. If I didn't understand that representation of 
addition, then I pick another one, and interact with or watch that).

Note that addition is a very low level concept used thousands of times a day in 
computer programming, so most likely most of *us* as fairly complex 
programmers wouldn't ever use this particular pedagogical tool... unless we 
wanted to explain addition to our kids... we might replace the dots with 3d 
oranges... and then a tiny child could understand the concept in seconds...

Note also that the only thing I'm really interested in proposing here is that 
knowledge be inlined... that is... as I'm writing code, my intention is written 
down too... or to put another way... if I'm drawing a terrain map THAT I 
INCLUDE THE KEY FOR THE MAP WITH THE MAP ITSELF... so that later, someone can 
interpret what it means. This removes the need for documentation, and also 
allows it to be generated easily if it's required... but also, hopefully 
doesn't let people build things they don't understand... so that in the end if 
someone doesn't understand how something in particular works, well then the 
learning of it is in the environment where the object is itself... 

Note that this seems SO RIDICULOUSLY OBVIOUS to me that it's not even funny... 
it also makes explaining computer to people incredibly saddening, because to 
someone with the requisite knowledge, computing is incredibly easy, but getting 
the requisite bits of knowledge into the right parts of a person is often so 
frustrating for the person in question.

One thing I liked about Self and to a lesser degree SmallTalk (especially 
Squeak) is that if you want to work out how something works, you yank it out, 
or build an example of it, and inspect it... and you can go on ad infinitum... 
inspecting... seeing how things are composed. There's still a HUGE amount of 
assumed and required knowledge in there in order to use the system, but the 
idea is what I mean... where there's a totally uniform interface that can be 
inspected to learn about it, up to the point that the original programmer 
decides to allow you to see inside it.

I should be able to inspect to the degree of machine code... if I want to... to 
find out how my large sum addition is clothed in machine code on my particular 
computer... and perhaps even lower - see the particular way that byte-size 
integer addition happens on my particular machine if there's a pedagogical 
model in place to see it. 

I know for a fact that young inquisitive kids will find this fascinating, and 
when there's less stuff

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-19 Thread BGB

On 6/19/2011 7:20 PM, Steve Dekorte wrote:

On 2011-06-14 Tue, at 09:36 PM, Julian Leviston wrote:

The thing that irritates me about this attitude of don't consider kids as equal is that
we DO consider them as equal in other frames... we expect so much of them in terms of linguistic
and cognitive development... and actually the abstractions (zero-th order abstraction) capable of
and exhibited by a 5 year old are used when in the activity called programming all the
time... so much so we as adult programmers rarely think about them.

I agree. People seem to define smart as something like things I can't do
easily. So, for example, if they can use a keyboard, well someone like a child who can't must
not be smart and this is why people were surprised when the mouse and graphical UIs allowed
toddlers to use the Mac or touch screens allowed near infants to use iPads today. All along it was
an issue of unnatural conceptual mapping (like asking a right handed person to throw with their
left hand) that was the problem, not a lack of smarts.

also, mouse or touch-screen are relatively direct-feedback, rather than
requiring high-levels of abstract thought to work with.

part of the problem may be that of preexisting knowledge...
sometimes, knowledge can help people understand things easier;
often, existing knowledge will lead to very nasty conceptual kludges.

an example of the above I think is the ever-persistent file-cabinet
metaphor:
people very often portray things like files/... by making references
back to this metaphor.
the assumption (I guess) is that people will be more familiar with
filing cabinets or find them more intuitive or similar.

but, from the POV of someone who has never really used them for their
intended purpose, or worked with piles of paper documents, the analogy
doesn't really seem to work, as filing cabinets and filing systems
really seem very much like unrelated concepts...

at best, the terminology has been overloaded, and the new concept of
file (a hierarchical tree of directories containing files each
containing some number of bytes) has almost entirely subsumed the
file-cabinet concept on which the original metaphor was based.

in a sense, the metaphor no longer works, and should likely itself be
left to fall into the recycle-bin of history. worse yet is having to
read stuff written by people who actually take this metaphor seriously.

granted, there are other annoying metaphors, but most others are not
used nearly so offensively...

a young child though will probably see things more how they are, and not
likely build their thinking around metaphors which are borderline absurd:
that a computer is a filing cabinet in an office residing on the surface
of a giant desk for which a man in a robe will pop out just as soon as
one pokes at it... (and where one is honestly expected to take advice
from an anthropomorphic paper-clip...).

yet, at the same time, it seems far more the case that society in
general disregards people, and tries to force them into their particular
mindset and worldview. one is not then really allowed to see the world
as it is, but expected to deal with it in terms of layers of
intellectual and ideological cruft.

granted, maybe not everyone will come into the same reality, but maybe
this is ok as well. it is a curious observation that so many people,
living in essentially the same world and often from the same culture and
geographic area, will come to have a number of different worldviews.

(but, going more into this topic goes into some rather awkward issues...).

From this perspective we could see the history of programming as one of
finding ever more natural mappings between how our minds work and how we can
get machines to do what we want - just as steering wheel and floor pedals map
between our bodies and our vehicles. If so, which mappings are more natural and
under which circumstances seems to be the important question and one, AFAICS,
that may not well answered by simply replacing words with ideograms and
expressions with boxes and arrows.

agreed... I really don't believe graphical solutions are necessarily ideal.

but, at the same time, there is also the matter of finding the right
tool for the job.

for example, code works great for expression program logic, but falls
flat for many other tasks:

creating a graphical image;
creating a 3D model or scene;
...

in these cases, having more specialized tools tends to be far more
effective.

for example, for editing a photo, one summons up a tool like GIMP.
and, for making a 3D model, or working on its animations, one will
generally summon up a dedicated 3D tool.

picking the right sort of tool can notably reduce the effort required to
complete a given task.
in the above cases, a graphical tool is generally the best solution, but
graphics are not best for all tasks either.

a partial issue may then be battling a more subtle problem:
it is very common

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-19 Thread Julian Leviston


On 20/06/2011, at 2:33 PM, BGB wrote:

 in a sense, the metaphor no longer works, and should likely itself be left to 
 fall into the recycle-bin of history. worse yet is having to read stuff 
 written by people who actually take this metaphor seriously.

Given the historical perspective, it was appropriate at the time. These days, 
our computers are so vastly scaled beyond the original intention of the file 
metaphor that it's getting silly, I'd grant you that.

It's not really any surprise, then, that Apple's trying to get rid of the 
file system, is it? :) Mind you, I think the app metaphor is just as crappy, 
personally. I like the idea of workflows much more, and combining a few small 
simple tools together to get some particular job done.

For example, when web programming on a specific web app, I use a web browser, a 
text editor, a database management program, a command line, and a couple other 
tools. It'd be nice to be able to fit these tools together into a pseudo-app 
and then build documents for this pseudo-app... that were accessible within 
the pseudo-app (ie not the file system) to use Apple's idea, and that could 
simply do all the things I generally need to do... (there are only a few 
tasks I generally do and none of them correlate directly into any one 
particular application).

I love the way I edit text in my one particular text editor. Why do I have to 
use a different editor to edit my email text? lol... it makes little sense.

Julian.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-15 Thread BGB

On 6/14/2011 9:50 PM, Dethe Elza wrote:

On 2011-06-14, at 9:36 PM, Julian Leviston wrote:

Not equal. Children are very different cognitively from adults and it is
important to resist the temptation to treat them as little adults. On the other
hand, we shouldn't condescend to them, they are like learning sponges and can
absorb ideas far beyond what we generally give them credit for.

not much experience interacting with kids (don't have kids, never
married, don't have a significant other either, as things just never
seem to go anywhere...).

but, yeah... being young, time seems to go by very slowly, and just
sitting around fiddling with something, one accomplishes a lot of stuff
in a relatively short period of time.

as one gets older though, time goes by ever faster, and one can observe
that less and less happens in a given period of time. then one sees many
older people, and what one sees doesn't look all that promising.

sadly, as is seemingly the case that a lot of potentially ones'
potentially most productive years are squandered away doing things like
schoolwork and similar, and by the time one generally gets done with all
this, ones' mind has already become somewhat dulled due to age.

it is like, me noting that several years ago, I was dealing with a
personal-project codebase expansion of around +120 kloc/yr or so (and a
few cases of breaking 1 kloc/day, usually in bursts), but more recently,
my codebase has actually been shrinking (seemingly defying common
sense...). granted, it is a question of how big of a codebase can be
reasonably developed and maintained by a single developer though.

also, maybe the underlying forces behind codebase expansion and
shrinking, where positive effort and adding functionality doesn't
necessarily always make ones' code get bigger, ... it leaves something
to ponder.

granted, at the time I was pulling off high output rates:
I wrote an x86 assembler/linker, pulling off around 10 kloc in 3 days or
something;
when writing a C compiler, which turned out very large, and a bug-ridden
mess;
writing an x86 interpreter, which itself was like 40 kloc in around a 2
weeks or similar;

...

granted, these sorts of efforts are relatively rare.
scary would be if someone else could (actually) pull off consistent
output at this rate (and emit code consistently at approx 1Mloc/yr...).

and, meanwhile, recent output has been net negative...

hmm...

One problem is immersion. They learn language amazingly fast (in large part) because they
are immersed in it constantly. Seymour Papert's book, Mindstorms is one of the best reads
I've ever had about software, and he discusses creating worlds for math,
physics, and other subjects on the computer so that children can be as immersed in those
worlds as they are naturally in the world of language. That was one of the guiding ideas
behind the creation of Logo.

yes, but it is also notable that they learn language, being exposed to
it in its full complexity.

it is like, kids don't learn from a watered-down subset of the language,
they just learn the language from hearing others use it.

hence, a large portion of immersion may be more due to availability and
them having a personal interest or reason.

Some of the structural patterns that a small child already has at least some
mastership of are connection, fitting, representation, indirection, context,
mood, physical relationship. These are all used in simple programming. Perhaps
they don't have the meta-words, but that's okay - that can come later at about
12 when they begin their next level of abstract cognitive development (ie
proper abstract thought).

My flatmate's 7 year old daughter is in the process of mastering addition,
subtraction, multiplication and division. These things are quite abstract. My
flatmate's THREE year old (!!) understands in a non-verbal way the idea of a
pointer and mouse connection. Do you realise how advanced that idea is?
Consider that he's only really begun to talk in sentences properly in the last
6 to 8 weeks. It's very simple in terms of our usage of computers, but it's an
incredibly complex structural pattern, really... it's representation and
indirection... you move this thing, and it represents this other thing, and we
can use it to manipulate yet more things... of course the child doesn't realise
that the things on the screen aren't real that they're simply further
representations... but you get the gist... the capacity is there... and the
ENERGY that

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-15 Thread Tristan Slominski


 but, yeah... being young, time seems to go by very slowly, and just sitting
 around fiddling with something, one accomplishes a lot of stuff in a
 relatively short period of time.

 as one gets older though, time goes by ever faster, and one can observe
 that less and less happens in a given period of time. then one sees many
 older people, and what one sees doesn't look all that promising.

 sadly, as is seemingly the case that a lot of potentially ones' potentially
 most productive years are squandered away doing things like schoolwork and
 similar, and by the time one generally gets done with all this, ones' mind
 has already become somewhat dulled due to age.


From the insights into how the human neocortex learns information gained
from the research (not mine) in Hierarchical Temporal Memory (HTM) machine
learning model, I would contest the idea that less happens in a give period
of time as you get older.

If you explore HTM, it illustrates that as inputs are generated, they are
evaluated in the context of the predictions that the network is making at
any given time.

As a young person, the neocortex knows nothing, so all the predictions are
most often wrong. When there is dissonance between prediction and input, a
sort of *interrupt* happens ( which gives us awareness of time ) and
learning of a new pattern eventually occurs.  As we get older, less and less
of the world becomes *novel*, so our neocortical predictions are more and
more correct, generating less and less interrupts. One could argue that our
perception of time is the number of these interrupts occurring in an
interval of proper time. The concept of *flow* for example, when one loses
track of time being fully immersed in a problem, could be simply the fact
that you are so engaged and knowledgable in an area that your mind is able
to successfully isolate itself from interrupt generating input and process
information at peak efficiency.

I would go even as far as saying that the productivity described in
productive years is more of an exposure to novel input than actual
productivity.
Perhaps another way of stating what you're perceiving could be that you have
more and more *friction* of learned patterns to overcome as you try to adapt
to novel input as you get older.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Waterbear announcement (was Re: Age and Language (was Re: [fonc] Alternative Web programming models?))

2011-06-15 Thread Dethe Elza

On 2011-06-15, at 3:42 PM, Dale Schumacher wrote:

 On Wed, Jun 15, 2011 at 8:30 AM, Dethe Elza de...@livingcode.org wrote:
 In fact, I'm interested enough in the block structure visualization that 
 I've been porting just the blocks, without the Scratch semantics and 
 runtime, to the web. You can use scratch-like blocks to write and output any 
 language, provided a language plugin. As a demonstration, I'm writing a 
 language plugin for Javascript (plus Raphael, for graphics) and Martyn 
 Eggleton is working on a plugin for writing Arduino code. It is still early 
 days, very alpha, but if anyone is interested there is more here:
 
 https://github.com/dethe/waterbear/wiki [info]
 https://github.com/dethe/waterbear/ [code]
 https://waterbearlang.com/ [Javascript demo]
 http://stretch.deedah.org/waterbear/ [Arduino demo]
 
 I've been meaning to share this with the group here, but wanting to get it 
 roughed in a bit more, but here it is in all its half-baked glory. Feedback 
 highly appreciated.
 
 --Dethe
 
 Very cool project.  I'd like to see how easy it would be to use it for
 Humus programs.

Thanks! I don't know how easy it would be to use with Humus, but I'd be happy 
to help explore it and find out.

I'm just finishing up a couple of side projects so I can devote all my hobby 
coding time to Waterbear. One big refactoring is going to be control of (most 
of) the UI from a language plugin, and multiple language plugins supported from 
the same version (right now they are separate forks).

--Dethe
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Waterbear announcement (was Re: Age and Language (was Re: [fonc] Alternative Web programming models?))

2011-06-15 Thread Steve Wart

I like it. My son is very keen on Scratch (although he prefers Lua
these days), but we picked up an Arduino kit last month, and I'm
looking forward to playing with that.

His eyes kind of glazed over looking at the C code, as simple as it is
for Arduino. I got the impression he was just happy to have dad
perform magic tricks for him :-)

Cheers,
Steve

On Wed, Jun 15, 2011 at 3:49 PM, Dethe Elza de...@livingcode.org wrote:
 On 2011-06-15, at 3:42 PM, Dale Schumacher wrote:

 On Wed, Jun 15, 2011 at 8:30 AM, Dethe Elza de...@livingcode.org wrote:
 In fact, I'm interested enough in the block structure visualization that 
 I've been porting just the blocks, without the Scratch semantics and 
 runtime, to the web. You can use scratch-like blocks to write and output 
 any language, provided a language plugin. As a demonstration, I'm writing a 
 language plugin for Javascript (plus Raphael, for graphics) and Martyn 
 Eggleton is working on a plugin for writing Arduino code. It is still early 
 days, very alpha, but if anyone is interested there is more here:

 https://github.com/dethe/waterbear/wiki [info]
 https://github.com/dethe/waterbear/ [code]
 https://waterbearlang.com/ [Javascript demo]
 http://stretch.deedah.org/waterbear/ [Arduino demo]

 I've been meaning to share this with the group here, but wanting to get it 
 roughed in a bit more, but here it is in all its half-baked glory. Feedback 
 highly appreciated.

 --Dethe

 Very cool project.  I'd like to see how easy it would be to use it for
 Humus programs.

 Thanks! I don't know how easy it would be to use with Humus, but I'd be happy 
 to help explore it and find out.

 I'm just finishing up a couple of side projects so I can devote all my hobby 
 coding time to Waterbear. One big refactoring is going to be control of (most 
 of) the UI from a language plugin, and multiple language plugins supported 
 from the same version (right now they are separate forks).

 --Dethe
 ___
 fonc mailing list
 fonc@vpri.org
 http://vpri.org/mailman/listinfo/fonc


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-15 Thread K. K. Subramaniam

On Monday 13 Jun 2011 8:47:49 PM Alan Kay wrote:
 It would be great if everyone on this list would think deeply about how to
 have  an eternal system, and only be amplified by it.
The picture I had in mind was a interconnection of systems that grow in an 
interdependent way by absorbing selectively from each other. This implies 
mechanisms for diffing two systems and filtering appropriate elements for 
absorption into one of the systems. While a system can be used independently 
(i.e. it has its intrinsic worth), it is capable of absorbing, adapting and 
amplifying its capabilities when plunked into a network systems.

In this scenario, diffing a system against itself along a timeline is just a 
special case. Warth's Worlds is a fascinating paper but I didn't see it 
address multiple world scenario (yet!). It is possible that my reading hasn't 
gone deep enough to realize its ramifications.

xmldiff was an injudicious analogy for a research mailing list :-(. Apologies.

Subbu

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Waterbear announcement (was Re: Age and Language (was Re: [fonc] Alternative Web programming models?))

2011-06-15 Thread Steve Wart

On Wed, Jun 15, 2011 at 8:16 PM, Dethe Elza de...@livingcode.org wrote:

 Glad you like it. How old is your son? Maybe we should organize a Vancouver 
 Geek Kids, or meet up at
 Maker Faire next week. Or there is this: http://www.tedxkidsbc.com/

TEDx kids looks wonderful - thanks for that link.

A Geek Kids meetup would be very popular; he's 13 and his sister is
12. They're up in Vancouver for the Summer, but unfortunately I'll be
in San Jose with only a couple of very short trips back.

We took them to the Maker's Faire in San Mateo last month and they
were thrilled, especially with the hands-on labs, but it was too much
to cover with the intense crowds and we missed a lot. The mini Faire
should be a lot more manageable. I'll pass on that info and hopefully
we can get them to go.

 I'm working to get the Arduino code merged in with the main fork. Also 
 looking at options for wrapping the webapp in a native shell using 
 Appcelerator Titanium or Mozilla Chromeless so we can access the serial port 
 from Javascript.


I'll have a look at the code this weekend. Other than a somewhat
obsessive use of Minecraft as social media, things are quiet here :)

Cheers,
Steve

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

On Mon, Jun 13, 2011 at 9:26 PM, Julian Leviston jul...@leviston.net wrote:
 ... also, the idea of modelling change ITSELF is an appealing one in this
 context, and all changes including data entry etc being simply represented
 as a log of mutations using the command pattern. Thus the data represented
 in the first world would be mutated and propagated to the new world
 (actually more like the view of it filtered or some-such) according to the
 new rules, and the inverse would apply as well...

There might be some experience on this in the CQRS-community. They
usually model systems with event sourcing as the primary
representation of state and have to deal with the versioning issues.

Then there's the experience with working with databases, both
relational and OO. The practice that seems to work is to model new
versions in a backwards-compatible way and then refactor once the old
versions has been completely shut down.

My own thinking in this area is that you handle merges automatically
if you can but fall back on manual intervention if not. Hopefully the
system has a user-base that knows what to do with inconsistent data.

In any case I guess the default behaviour when branching is to simply
diverge, merges in any direction, should only happen if asked to, and
when asked to. The Git workflow seems to work very well. If there is
anything broken with it it is that it tends to express dependencies
that aren't really there, but that isn't a fundamental property of the
DAG-model just a consequence of how the tools steers you. The Darcs
approach with it's theory of patches be better in this regard, have no
experience working with it though.

BR,
John

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

On Mon, Jun 13, 2011 at 10:02 PM, BGB cr88...@gmail.com wrote:
 but, what would be the gain?... the major issue with most possible graphical
 representations, is that they are far less compact. hence, the common use of
 graphical presentations to represent a small amount in information in a
 compelling way (say, a bar-chart or line-graph which represents only a
 small number of data-points).

I too have been thinking that the textual representation has to go.
Not to replace it with fancy icons but mainly to remove the limits
imposed by parsing, but also to make graphical representations
available, for example tables is a language construct I usually miss,
arrays of arrays of objects just doesn't cut it.

By parsing limits I mean the fact that the language grammar usually
has to be more verbose than is required by a human to resolve
ambiguity and other issues. This is mainly a problem if you start
thinking of how to mix languages. To integrates say Java, SQL and
regular expressions in one grammar. Sure it can be done by careful
attention to the grammar, like PL/SQL f.ex. but how do you do it in a
generic way such that DSLs can be created as libraries by application
programmers?

BR,
John

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-14 Thread Tristan Slominski



 By parsing limits I mean the fact that the language grammar usually
 has to be more verbose than is required by a human to resolve
 ambiguity and other issues. This is mainly a problem if you start
 thinking of how to mix languages. To integrates say Java, SQL and
 regular expressions in one grammar. Sure it can be done by careful
 attention to the grammar, like PL/SQL f.ex. but how do you do it in a
 generic way such that DSLs can be created as libraries by application
 programmers?

 BR,
 John


This looks like a job for OMeta ( http://tinlizzie.org/ometa/ )
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-14 Thread Tristan Slominski


 I had some thoughts about how to approach the issue. I was thinking that
 you could represent the language in a more semanticaly rich form such as a
 RAG stored in a graph database. Then languages would be composed by
 declaring lenses between them.

 As long as there is a lens to a editor dsl you could edit the labguage in
 that editor. If you had a lens from SQL to Java (for example via jdbc) you
 could ebed SQL expressions in java code. Give transitive lenses it would
 also be a system supporting much reuse. A new DSL could then leverage the
 semantic editing support allredy created for other languages.

 BR,
 John

Just for completeness, the lenses you describe here remind me of OMeta's
foreign rule invocation:

from http://www.vpri.org/pdf/tr2008003_experimenting.pdf

see 2.3.4 Foreign Rule Invocation p. 27 of paper, p. 46 of pdf

So, if you don't like the PEG roots of OMeta, perhaps it's a good reference
that already works?

Cheers,

Tristan
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

Thanks for the pointer. I'll have a look.

BR,
John

Sent from my phone
Den 14 jun 2011 17:17 skrev Tristan Slominski tristan.slomin...@gmail.com
:

 I had some thoughts about how to approach the issue. I was thinking that
 you could represent the language in a more semanticaly rich form such as
a
 RAG stored in a graph database. Then languages would be composed by
 declaring lenses between them.

 As long as there is a lens to a editor dsl you could edit the labguage in
 that editor. If you had a lens from SQL to Java (for example via jdbc)
you
 could ebed SQL expressions in java code. Give transitive lenses it would
 also be a system supporting much reuse. A new DSL could then leverage the
 semantic editing support allredy created for other languages.

 BR,
 John

 Just for completeness, the lenses you describe here remind me of OMeta's
 foreign rule invocation:

 from http://www.vpri.org/pdf/tr2008003_experimenting.pdf

 see 2.3.4 Foreign Rule Invocation p. 27 of paper, p. 46 of pdf

 So, if you don't like the PEG roots of OMeta, perhaps it's a good
reference
 that already works?

 Cheers,

 Tristan
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-14 Thread Julian Leviston


On 15/06/2011, at 1:14 AM, Tristan Slominski wrote:

 Just for completeness, the lenses you describe here remind me of OMeta's 
 foreign rule invocation:
 

Yeah, I think there is a fair amount of deep digestion required to fully grok 
these ideas, personally. Haha that sounds disturbing. :)
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

On Tue, Jun 14, 2011 at 5:14 PM, Tristan Slominski
tristan.slomin...@gmail.com wrote:
 Just for completeness, the lenses you describe here remind me of OMeta's
 foreign rule invocation:
 from http://www.vpri.org/pdf/tr2008003_experimenting.pdf
 see 2.3.4 Foreign Rule Invocation p. 27 of paper, p. 46 of pdf
 So, if you don't like the PEG roots of OMeta, perhaps it's a good reference
 that already works?

The foreign rule invocation let you reuse other grammar but you still
have to carefully declare how the merged grammar should behave. What I
as aiming for was a more dynamic approach in that the merged grammar
doesn't exist as such but is just an execution state derived from the
combined program fragments and available lenses. To continue the
Java/SQL example, lets say I had a program like this:

public int totalAmmount(InvoiceNo invoceNo) {
  return SELECT SUM(ammount) FROM Invoices WHERE invoiceNo = :InvoiceNo;
}

To make this work I would need three things
1. The java grammar in which the method is declared
2. The SQL grammar in which the expression is declared
3. Something that can translate an SQL expression to a Java
expression, and Java type-errors to SQL type-errors (the lens).
4. A way to annotate the syntax to distinguish Java-syntax from SQL-syntax.

It is step 4 that I think makes it hard to keep a text representation.
A generic syntax to separate any given language would probably be very
convoluted. OTOH extending all languages one want to include to
support grammar switches means that you will end up having to create
those extensions yourself (which could be hard) or live at the mercy
of the syntax-component you depend on. So my fix is to make the
separation a hidden thing, which means the program needs to be
represented in something that allows such hidden things (and I don't
think Unicode control characters is the way to go here).


Btw, if it wasn't clear form the context before, by RAG I meant a
Reference Attributed Grammar.


BR,
John

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-14 Thread Michael FIG

Hi,

John Nilsson j...@milsson.nu writes:

 So my fix is to make the separation a hidden thing, which means the
 program needs to be represented in something that allows such hidden
 things (and I don't think Unicode control characters is the way to go
 here).

Why not crib a hack from JavaDoc and make your nested syntax embedded in
comments in the host language?

-- 
Michael FIG mich...@fig.org //\
   http://michael.fig.org/\//

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-14 Thread BGB


On 6/13/2011 8:09 PM, Julian Leviston wrote:

On 14/06/2011, at 7:33 AM, Casey Ransberger wrote:


Kids may not have the linguistic development out of the way that one needs to do 
serious programming. Adults who don't already code may find themselves short 
on some of the core concepts that conventional programming languages expect of the user. 
In both cases, I think visual systems can get useless syntactic hurdles out of the way, 
so that users can focus of developing a command of the core concepts at work.


In most parts of the world, Monks used to be the only people who could read and 
write, you know. ;-)



I started out messing around with computers in maybe 3rd and 4th grade, 
mostly as that was when I started having them around...


personally, the textual nature of code was not such an issue, but I do 
remember at the time having a little confusion over the whole order of 
operations thing (I think I was left to wonder some why some operations 
would bind more tightly than others, they did not mention it in 
classes). at the time, it was mostly QBasic and DOS...


much younger, and it is doubtful people can do much of anything useful.
can you teach programming to a kindergartner?...
maybe not such a good idea, so, it is an issue for what a good 
lower-limit is for where to try.


ultimately, maybe the whole topic is beyond the reach of many people 
(like, maybe ability to program is more of an inherent ability, rather 
than a learned skill?...). in this case, one can just make things 
available, and see who catches on...



I don't necessarily think graphics are the answer though. people learn 
to read and write either way, and using graphics seems a bit much like a 
vain attempt at trying to water down the topic.


or such...


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-14 Thread Dethe Elza

On 2011-06-14, at 12:33 PM, BGB wrote:

 much younger, and it is doubtful people can do much of anything useful.
 can you teach programming to a kindergartner?...
 maybe not such a good idea, so, it is an issue for what a good lower-limit is 
 for where to try.


My kids learned to program around kindergarten/first grade. My son started with 
Scratch when he was six and is now teaching himself Javascript/Raphael and 
HTML/CSS at age 10.

One advantage graphic tools like Scratch have for younger learners is that they 
don't have to know how to type, just read and write. Having the syntax enforced 
by the structure of the blocks helps too (no typos, no syntax errors, in 
addition to the aforementioned enforced strong typing).

--Dethe
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

On both questions the answer is basically that Java was an example. I was
looking for a general solution. Something that would work withoug prior
assumptions about the languages involved.

The problem I was thinking about was how to provide an infrastructure where
in anyone could be a language designer and almost for free get all the
tooling support required for the language to gain traction. It seems to me
that the effort required to go from an itch to a fully mainstream language
is way to high. And partly to blame why we are still introducing
inventions from the sixties in current mainstream languages.

BR,
John

Sent from my phone
Den 14 jun 2011 22:10 skrev BGB cr88...@gmail.com:
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-14 Thread Kevin Driedger

I wonder if a thousand years ago the readers of the world thought that only
certain people had an aptitude for reading.
=

As a professional coder and father of young children I find Dethe's anecdote
of teaching his children to code/program at an early age has me thinking I
need to take another stab at showing Scratch again to my children.




On Tue, Jun 14, 2011 at 4:09 PM, Dethe Elza de...@livingcode.org wrote:

 On 2011-06-14, at 12:33 PM, BGB wrote:

  much younger, and it is doubtful people can do much of anything useful.
  can you teach programming to a kindergartner?...
  maybe not such a good idea, so, it is an issue for what a good
 lower-limit is for where to try.


 My kids learned to program around kindergarten/first grade. My son started
 with Scratch when he was six and is now teaching himself Javascript/Raphael
 and HTML/CSS at age 10.

 One advantage graphic tools like Scratch have for younger learners is that
 they don't have to know how to type, just read and write. Having the syntax
 enforced by the structure of the blocks helps too (no typos, no syntax
 errors, in addition to the aforementioned enforced strong typing).

 --Dethe
 ___
 fonc mailing list
 fonc@vpri.org
 http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-14 Thread Ondřej Bílka

On Tue, Jun 14, 2011 at 01:04:20PM -0700, BGB wrote:
 On 6/14/2011 12:14 PM, Michael FIG wrote:
 Hi,
 
 John Nilssonj...@milsson.nu  writes:
 
 So my fix is to make the separation a hidden thing, which means the
 program needs to be represented in something that allows such hidden
 things (and I don't think Unicode control characters is the way to go
 here).
 Why not crib a hack from JavaDoc and make your nested syntax embedded in
 comments in the host language?
 
 
 or, like in my languages (generally for other things):
 use a keyword...
 
 reusing prior example:
 
 public int totalAmmount(InvoiceNo invoceNo)
 {
   return SQLExpr {
 SELECT SUM(ammount) FROM Invoices WHERE invoiceNo = :InvoiceNo;
   }
 }
 

Well you can embed languages easily using fact that in any sane language 
parenthness match 
unless you areb inside string.
You could get pretty strong preprocessor in few lines like my preprocessor 
which I attach.

It has one command 
register(name,command)  
which replaces all subsequent occurences of name(args){properly parenthized 
text} 
by output of command with args given and text pasted as input.
-- 

Big to little endian conversion error
$reg={register=true}
def subp(s,i,l,r)
return [,i] if s[i,1]!=l
o=
pc=0
begin
pc+=1 if s[i,1]==l
pc-=1 if s[i,1]==r
if s[i,1]==''
while s[i+1,1]!=''  s[i,1]!='\\'
os[i,1]
i+=1 
end
i+=1
end
os[i,1]
i+=1
end while pc0
[process(o[1,o.size-2]),i]
end
def process(s)
o=
i=0
while is.size
ch=false
$reg.each{|name,command| 
if name==s[i,name.size]  !(s[i+name.size]=~/\w/)
i+=name.size
args,i=subp(s,i,(,))
text,i=subp(s,i,{,})
if name==register
word,program=args.split(,)
$reg[word]=program
else
File.open(tmp1,w){|f| f.puts(text)}
`#{command} #{args} tmp1 tmp2`

oprocess(File.new(tmp2).lines.to_a*)
end
ch=true
break
end
}
if !ch
os[i,1]
i+=1
end
end
o
end
puts process(File.new(ARGV[0]).lines.to_a*)
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

Let say I want this then:

public int totalAmmount()
{
  return SELECT SUM(ammount) FROM Invoices WHERE invoiceNo =
Invoice.currentId();
}

That is now there is Java nested inside the SQL. When I ask the IDE to
list all references to Invoice.currentId(), this instance should also
be included.

There was some paper on macros that solved this with varios nestings
of ?() or some such construct. But that isn't very readable when you
add lots of back and forth.

Oh well, it isn't a project I'm working actively on, just a wild idea
for the future ;-)

BR,
John

2011/6/15 Ondřej Bílka nel...@seznam.cz:
 On Tue, Jun 14, 2011 at 01:04:20PM -0700, BGB wrote:
 On 6/14/2011 12:14 PM, Michael FIG wrote:
 Hi,
 
 John Nilssonj...@milsson.nu  writes:
 
 So my fix is to make the separation a hidden thing, which means the
 program needs to be represented in something that allows such hidden
 things (and I don't think Unicode control characters is the way to go
 here).
 Why not crib a hack from JavaDoc and make your nested syntax embedded in
 comments in the host language?
 

 or, like in my languages (generally for other things):
 use a keyword...

 reusing prior example:

 public int totalAmmount(InvoiceNo invoceNo)
 {
   return SQLExpr {
     SELECT SUM(ammount) FROM Invoices WHERE invoiceNo = :InvoiceNo;
   }
 }


 Well you can embed languages easily using fact that in any sane language 
 parenthness match
 unless you areb inside string.
 You could get pretty strong preprocessor in few lines like my preprocessor 
 which I attach.

 It has one command
 register(name,command)
 which replaces all subsequent occurences of name(args){properly parenthized 
 text}
 by output of command with args given and text pasted as input.
 --

 Big to little endian conversion error

 ___
 fonc mailing list
 fonc@vpri.org
 http://vpri.org/mailman/listinfo/fonc



___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-14 Thread BGB




On 6/14/2011 4:24 PM, John Nilsson wrote:


Yes. And now add to that semantic editing support for such extensions 
automatically inherited. Things like syntax highlighting, 
intellisense, find references. Also interoperabilty with libs/modules 
in other languages is important.


BR,
John



yeah.

I don't have special editor support for extensions, mostly because I 
don't have a special dedicated editor (as-is, I do most text-editing 
with Notepad2... mostly as it is fairly lightweight and does enough for 
my uses...).
in my case, I generally just tell it that my language is JavaScript, and 
it does well enough.


granted, a fancy editor which supported both a base language, and syntax 
extensions, could probably handle all this as well, more so if the 
editor was able to make use of the VM's facilities. granted, this would 
mean plug-ins also registering interfaces for things like autocomplete 
and similar.




as for cross-language interfacing...

actually, if the other language is C, my VM already does fairly well at 
this, since it was designed with a fancy C FFI.


in terms of the implementation, the C FFI is generally handled by 
special object, and in particular an object I call CTop (for C 
Toplevel, but it also supports scoped-lookups as well).


basically, the VM is set up to delegate to this special object (via a 
delegation-based lookup). when a request for something reaches this 
object, it will then call off into a C-side API to basically look up 
whatever is being asked for (involves a database, and 
GetProcAddress/dlsym, ...). variables will be marshaled into dynamically 
typed values. functions will be auto-wrapped as special function 
objects (which basically implements the Apply handler, so it can be 
called like a function... other special handlers have names like 
GetSlot, SetSlot, MethodCall, ...).


(how the lookup system works would be difficult to explain here, but 
IIRC some of the basic ideas/mechanism came from Self, and some stuff I 
ran into online describing some of the internals of Squeak IIRC, so this 
should be somewhere in the right direction...).



when called, the function object will take the arguments (generally 
passed to it as a list), and basically coerce this into the format 
expected by the native function and the relevant ABI, and then will then 
call the native function. on return, it will go the other way, and 
coerce the native return value back into a dynamically-typed reference. 
this step currently involves some amount of ASM, but I have recently 
considered the possibility of an optional pure C solution (likely 
involving a big-ass switch block, probably using autogenerated code).


there is a little nastiness in the details, but in general it manages to 
work fairly well...


it also has some basic support for C macros and similar as well (may 
involve eval, and so doesn't always work, and doesn't currently 
support function-like macros, ...).



eventually, I may work on extending the mechanism to support interfacing 
with C++ APIs, but this is likely to be big and nasty...



interfacing with other VM-based languages shouldn't be too difficult. 
one would mostly just have to implement an object type which can perform 
the relevant lookup operations, and returns function objects (objects 
which support being called/applied).


oh yeah, and one can create new objects to exhibit generally whatever 
other behaviors are needed as well (recently, I also added handlers/... 
related to value-type objects, which can support pass-by-value semantics 
rather than necessarily follow pass-by-reference, ...).



or such...



Sent from my phone

Den 15 jun 2011 01:08 skrev BGB cr88...@gmail.com 
mailto:cr88...@gmail.com:

 On 6/14/2011 2:31 PM, John Nilsson wrote:

 On both questions the answer is basically that Java was an example. I
 was looking for a general solution. Something that would work withoug
 prior assumptions about the languages involved.

 The problem I was thinking about was how to provide an infrastructure
 where in anyone could be a language designer and almost for free get
 all the tooling support required for the language to gain traction. It
 seems to me that the effort required to go from an itch to a fully
 mainstream language is way to high. And partly to blame why we are
 still introducing inventions from the sixties in current mainstream
 languages.


 possibly, opening up the implementation more...

 namely:
 the parser produces an AST, in a form that user-written code can work
 with (one possibility being a List/S-Expression based form, or an
 XML-based format);
 allowing code to create its own ASTs and feed them into the compiler/VM;
 also allowing easy access to the ByteCode / IL (the JVM does this 
fairly
 well, for example, it is possible to produce class-objects and feed 
them

 into the JVM);
 access to low-level facilities;
 reflection, ...

 as well as possibly the ability to register plug in features at most
 levels, such

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-14 Thread Julian Leviston


On 15/06/2011, at 9:00 AM, Kevin Driedger wrote:

 I wonder if a thousand years ago the readers of the world thought that only 
 certain people had an aptitude for reading.
 =
 
 As a professional coder and father of young children I find Dethe's anecdote 
 of teaching his children to code/program at an early age has me thinking I 
 need to take another stab at showing Scratch again to my children.

The thing that irritates me about this attitude of don't consider kids as 
equal is that we DO consider them as equal in other frames... we expect so 
much of them in terms of linguistic and cognitive development... and actually 
the abstractions (zero-th order abstraction) capable of and exhibited by a 5 
year old are used when in the activity called programming all the time... so 
much so we as adult programmers rarely think about them.

Some of the structural patterns that a small child already has at least some 
mastership of are connection, fitting, representation, indirection, context, 
mood, physical relationship. These are all used in simple programming. Perhaps 
they don't have the meta-words, but that's okay - that can come later at about 
12 when they begin their next level of abstract cognitive development (ie 
proper abstract thought).

My flatmate's 7 year old daughter is in the process of mastering addition, 
subtraction, multiplication and division. These things are quite abstract. My 
flatmate's THREE year old (!!) understands in a non-verbal way the idea of a 
pointer and mouse connection. Do you realise how advanced that idea is? 
Consider that he's only really begun to talk in sentences properly in the last 
6 to 8 weeks. It's very simple in terms of our usage of computers, but it's an 
incredibly complex structural pattern, really... it's representation and 
indirection... you move this thing, and it represents this other thing, and we 
can use it to manipulate yet more things... of course the child doesn't realise 
that the things on the screen aren't real that they're simply further 
representations... but you get the gist... the capacity is there... and the 
ENERGY that is there is amazing...

Julian.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-14 Thread Dethe Elza

On 2011-06-14, at 9:36 PM, Julian Leviston wrote:

 The thing that irritates me about this attitude of don't consider kids as 
 equal is that we DO consider them as equal in other frames... we expect so 
 much of them in terms of linguistic and cognitive development... and actually 
 the abstractions (zero-th order abstraction) capable of and exhibited by a 5 
 year old are used when in the activity called programming all the time... 
 so much so we as adult programmers rarely think about them.

Not equal. Children are very different cognitively from adults and it is 
important to resist the temptation to treat them as little adults. On the other 
hand, we shouldn't condescend to them, they are like learning sponges and can 
absorb ideas far beyond what we generally give them credit for.

One problem is immersion. They learn language amazingly fast (in large part) 
because they are immersed in it constantly. Seymour Papert's book, Mindstorms 
is one of the best reads I've ever had about software, and he discusses 
creating worlds for math, physics, and other subjects on the computer so that 
children can be as immersed in those worlds as they are naturally in the world 
of language. That was one of the guiding ideas behind the creation of Logo.

 Some of the structural patterns that a small child already has at least some 
 mastership of are connection, fitting, representation, indirection, context, 
 mood, physical relationship. These are all used in simple programming. 
 Perhaps they don't have the meta-words, but that's okay - that can come later 
 at about 12 when they begin their next level of abstract cognitive 
 development (ie proper abstract thought).
 
 My flatmate's 7 year old daughter is in the process of mastering addition, 
 subtraction, multiplication and division. These things are quite abstract. My 
 flatmate's THREE year old (!!) understands in a non-verbal way the idea of a 
 pointer and mouse connection. Do you realise how advanced that idea is? 
 Consider that he's only really begun to talk in sentences properly in the 
 last 6 to 8 weeks. It's very simple in terms of our usage of computers, but 
 it's an incredibly complex structural pattern, really... it's representation 
 and indirection... you move this thing, and it represents this other thing, 
 and we can use it to manipulate yet more things... of course the child 
 doesn't realise that the things on the screen aren't real that they're simply 
 further representations... but you get the gist... the capacity is there... 
 and the ENERGY that is there is amazing...

There are some pretty subversive tools out there. Reader Rabbit's math software 
was teaching my kids algabraic abstraction before they started school. It just 
used boxes where you fill in a value instead of variables like x. Very 
concrete and they got it right away.

--Dethe
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?


On 12/06/2011, at 1:00 PM, BGB wrote:

 image-based systems have their own sets of drawbacks though...
 
 dynamic reload could be a good enough compromise IMO, if done well...

I don't follow this train of thought. Everything runs in an image. That's to 
say, the source code directly relates to some piece of running code in the 
system at some point. Smalltalk, Self and the like simply let you interact with 
the running code in the same place as the artefacts that create the running 
code. It's akin to programming in a debugger that saves the contents of memory 
constantly as the source.

As it's 2011, surely we can come to a point where we can synthesise these two 
apparently orthogonal concerns?

I think the main issue with smalltalk-like image systems is that the system 
doesn't as easily let you start from blank like text-file source-code style 
coding does... thats to say, yes, it's possible to start new worlds, but it's 
not very easy to reference bits of your worlds from each other... 

and essentially, that's what text-file coding (ie editing offline code) does 
for us... because things are in files, it's easy to include a file as one 
packaged unit, or a group of file, or a package... and then that package 
can be referred to... separately, and even maintained by someone else, and it's 
not a COPY of the package, it's a reference to it...  you know? This is 
incredibly powerful.

The equivalent in a smalltalk system would need to be some kind of amazing 
version control system that can version worlds at certain points, and package 
code in a recursive encapsulation process. Having a global namespace is kind 
of retarded... because context is everything... 

... that's to say, when and as context yields meaning (as I believe it does 
from my fairly deep ponderings), no token that yields meaning in a given 
context holds its meaning when decontextualised in the same way, therefore 
names (as these tokens) are deeply important IN CONTEXT. What kind of 
relevance, therefore, has a global namespace got?

Julian.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-13 Thread BGB


On 6/13/2011 1:33 AM, Julian Leviston wrote:

On 12/06/2011, at 1:00 PM, BGB wrote:


image-based systems have their own sets of drawbacks though...

dynamic reload could be a good enough compromise IMO, if done well...

I don't follow this train of thought. Everything runs in an image. That's to say, the 
source code directly relates to some piece of running code in the system at some point. Smalltalk, 
Self and the like simply let you interact with the running code in the same place as the artefacts 
that create the running code. It's akin to programming in a debugger that saves the contents of 
memory constantly as the source.


except, that traditional source-files have a concrete representation 
as so many files, and, beyond these files, there is nothing really of 
relevance (at least, conceptually, a person could print a program to 
paper, re-type it somewhere else, and expect the result to work).


does it rebuild from source? does the rebuilt program work on the target 
systems of interest? if so, then everything is good.



an image based system, OTOH, often means having to drag around the image 
instead, which may include a bunch of other stuff beyond just the raw 
text of the program, and may couple the program and the particular 
development environment used to create it.


this coupling may be somewhat undesirable, and it is preferable to have 
the source as files, so then one can rebuild from source whenever this 
is needed.


also, another risk is of the development image becoming polluted as a 
result of prior actions or code, which may risk compromising a project.



granted, the one major drawback of traditional files-based development 
is its traditional dependency on the edit/compile/run cycle. scripting 
languages can often make this cycle a little faster, but don't 
necessarily eliminate it.



however, dynamic reload can stay with using plain text files (thus 
allowing restarting clean if/when needed), and preserving familiar 
aspects of the coding process (namely, having ones' code organized 
into a tree of source files), but allows some of the merits of 
live-system coding, such as the ability to quickly load their changes 
back into the app, without having to exit and restart the program...


in this case, the currently running program image is partially 
malleable, and so is subject to hot-patching (within sane limits), so 
changes to the source can be reflected more immediately (no app restart).


however, unlike full image-based development, the app will generally 
forget everything that was going on once it is exited and restarted.



by analogy, it is like running programs in Windows:
one can open/close/run programs, edit things, ... in Windows, and so 
long as it is running, it will remember all this;
but, if/when Windows is rebooted, it will forget, and one starts again 
with a clean slate of sorts (an empty desktop with only their icons 
and start-up programs to greet them...).


but, the merit of rebooting Windows is that it keeps the system clean, 
as running Windows continuously is prone to cause it to degrade over 
time, and without an occasional reboot will begin to manifest lots of 
buggy behavior and eventually crash (IME, much worse in Vista and Win7 
than in XP...).




As it's 2011, surely we can come to a point where we can synthesise these two 
apparently orthogonal concerns?

I think the main issue with smalltalk-like image systems is that the system doesn't as easily let 
you start from blank like text-file source-code style coding does... thats to say, yes, it's 
possible to start new worlds, but it's not very easy to reference bits of your worlds from each 
other...


yes. for many types of project though, this is a potential deal-breaker.


another part of the matter may be that of dealing with different 
libraries being updated independently by different developers.


I am not certain how well either image-based development would map to 
traditional team-based development practices (say, where 5 or 10 people 
are assigned to work on a particular component, and 5 or 10 others 
working mostly independently are assigned to an adjacent component, ...).


granted, I may be wrong here, as I haven't done a whole lot of 
development with image-based systems.




and essentially, that's what text-file coding (ie editing offline code) does for us... because things are 
in files, it's easy to include a file as one packaged unit, or a group of file, or a package... 
and then that package can be referred to... separately, and even maintained by someone else, and it's not a 
COPY of the package, it's a reference to it...  you know? This is incredibly powerful.


yep.

I am generally mostly in favor of using files.



The equivalent in a smalltalk system would need to be some kind of amazing version 
control system that can version worlds at certain points, and package code in a recursive 
encapsulation process. Having a global namespace is kind of retarded...

Re: [fonc] Alternative Web programming models?


On 13/06/2011, at 7:50 PM, BGB wrote:

 On 6/13/2011 1:33 AM, Julian Leviston wrote:
 On 12/06/2011, at 1:00 PM, BGB wrote:
 
 image-based systems have their own sets of drawbacks though...
 
 dynamic reload could be a good enough compromise IMO, if done well...
 I don't follow this train of thought. Everything runs in an image. That's 
 to say, the source code directly relates to some piece of running code in 
 the system at some point. Smalltalk, Self and the like simply let you 
 interact with the running code in the same place as the artefacts that 
 create the running code. It's akin to programming in a debugger that saves 
 the contents of memory constantly as the source.
 
 except, that traditional source-files have a concrete representation as so 
 many files, and, beyond these files, there is nothing really of relevance (at 
 least, conceptually, a person could print a program to paper, re-type it 
 somewhere else, and expect the result to work).
 
 does it rebuild from source? does the rebuilt program work on the target 
 systems of interest? if so, then everything is good.
 
 
 an image based system, OTOH, often means having to drag around the image 
 instead, which may include a bunch of other stuff beyond just the raw text 
 of the program, and may couple the program and the particular development 
 environment used to create it.
 
[SNIP]
 
 or such...
 

This brings up an interesting point for me.

Source is an interesting word, isn't it? :) Source of what, exactly? 
Intention, right? The real code is surely the electricity inside the computer 
in its various configurations which represent numbers in binary. This is not 
textual streams, it's binary numbers. The representation is the interesting 
thing as are the abstractions that we derive from them.

I don't think computer programs being represented as text is very appropriate, 
useful or even interesting. in fact, I'd suffice to say that it's a definite 
hate/love relationship. I *love* typography, text and typing, but this has 
little or naught to do with programming. Programming is simply done in this 
way by me at the moment, begrudgingly because I have nothing better yet.

Consider what it'd be like if we didn't represent code as text... and 
represented it maybe as series of ideograms or icons (TileScript nod). Syntax 
errors don't really crop up any more, do they? Given a slightly nicer User 
Interface than tilescript, you could still type your code, (ie use the keyboard 
to fast-select tokens), but the computer won't validate any input that isn't 
in its dictionary of known possible syntactically correct items given 
whatever context you're in.

By the way, SmallTalk and Self are perfectly representable in textual forms... 
(file out nod) just like JVM bytecode is perfectly representable in textual 
form, or assembler... but text probably isn't the most useful way to interact 
with these things... just as to edit your text you most likely use some form 
of IDE (and yes, I'd class VIM or EMACS as an IDE).

Do I need to represent here just how idiotic I think compilation is as a 
process? It's a series of text stream processors that aim at building an 
artefact that has little or nothing to do with a world that exists entirely in 
text. TEXT!!! It's a bad way to represent the internal world of computers, in 
my opinion. It'd be nice to use a system which represents things a few layers 
closer to what's actually going on, and surely the FoNC project is aimed at a 
pedagogical direction intending to strip away layers of cruft between the image 
inside the head of a user ( or programmer) that they have representing how it 
works, and how it actually works... 

Mind you, I think human language is fairly silly, too... we communicate using 
mental bubbles of non-language based patterns, rendered into language, formed 
into text. It's well retarded... but this might be considered a little out 
there, so I'll end here.

If I'm providing too much noise for the list, please anyone, let me know, and 
I'll be quiet.

Julian.___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-13 Thread Hans-Martin Mosner

Am 13.06.2011 11:50, schrieb BGB:
 an image based system, OTOH, often means having to drag around the image 
 instead, which may include a bunch of other
 stuff beyond just the raw text of the program, and may couple the program 
 and the particular development environment
 used to create it.

 this coupling may be somewhat undesirable, and it is preferable to have the 
 source as files, so then one can rebuild
 from source whenever this is needed.

 also, another risk is of the development image becoming polluted as a 
 result of prior actions or code, which may
 risk compromising a project.
Just some quick comments from a long-time Smalltalker (25 years):
Of course rebuilding from source is desirable at certain points in time. For 
example, in the project I'm currently
working on, every production build is created from a clean image into which the 
application's source code is loaded.
This is a single-click process, just like building a traditional program from 
source files (except that we use VAST,
where the source code is held in an ENVY repository for version and 
configuration control instead of plain files).
However, in the development process we rarely rebuild images from scratch. It's 
not that we depend on image artefacts
created long ago, but we prefer to keep our personal selection of tools and 
debugging aids. Using ENVY, it's very simple
to sync our actual application source with the newest version while keeping all 
the tools intact. I normally rebuild my
development image only when we switch to a completely new base software 
version, or when I've accidentally damaged it to
a point where self-repair is not possible anymore (extremely rare, I've done 
that maybe 3-4 times during the project's
lifetime of about 12 years).
So, the risk associated with image-based development is mostly a theoretical 
one. In practice, it can be controlled just
as well as with file-based development, and you get all the advantages of the 
image on top :-)

Cheers,
Hans-Martin

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-13 Thread Dale Schumacher

On Mon, Jun 13, 2011 at 4:50 AM, BGB cr88...@gmail.com wrote:

 however, unlike full image-based development, the app will generally
 forget everything that was going on once it is exited and restarted.


I think this is one of the most annoying features of our current
computer systems.  If I have a project (or 10 or 20 projects) spread
out on my workbench, and I leave to have something to eat, or go to
sleep, when I return everything is still (more or less) in the state I
left it.


 by analogy, it is like running programs in Windows:
 one can open/close/run programs, edit things, ... in Windows, and so long as
 it is running, it will remember all this;
 but, if/when Windows is rebooted, it will forget, and one starts again with
 a clean slate of sorts (an empty desktop with only their icons and
 start-up programs to greet them...).

 but, the merit of rebooting Windows is that it keeps the system clean, as
 running Windows continuously is prone to cause it to degrade over time, and
 without an occasional reboot will begin to manifest lots of buggy behavior
 and eventually crash (IME, much worse in Vista and Win7 than in XP...).


Long-running stability and continuous upgrading (WITHOUT rebooting)
should be the norm.  There should be no such thing as a boot
process.  A system should remain stable (and running) throughout a
lifetime of gradual evolution/mutation.  Of course, we also need a way
to branch/fork/clone/version and even start-from-embryo, to build new
systems.  The next step is to consider how the system (or parts of
it) can migrate, or become mobile, among hosts.


 and essentially, that's what text-file coding (ie editing offline code)
 does for us... because things are in files, it's easy to include a file as
 one packaged unit, or a group of file, or a package... and then that
 package can be referred to... separately, and even maintained by someone
 else, and it's not a COPY of the package, it's a reference to it...  you
 know? This is incredibly powerful.

 yep.

 I am generally mostly in favor of using files.


Naming is certainly important, as is contextual reference, but I'm not
convinced that files are a necessary part of providing that
mechanism.  Consider, as a possible alternative, the idea of
parametrizing a module with its dependencies.  This is just the
principle of applying abstractions to allow local naming (aliasing) of
externally provided objects.

my_module(something_i_need, ...) = ... module specification using
something_i_need ...

create my_module(provider_of_service, ...)

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-13 Thread K. K. Subramaniam

On Monday 13 Jun 2011 2:03:29 PM Julian Leviston wrote:
 I think the main issue with smalltalk-like image systems is that the
 system doesn't as easily let you start from blank like text-file
 source-code style coding does... thats to say, yes, it's possible to start
 new worlds, but it's not very easy to reference bits of your worlds from
 each other... 
The pre-req for this is a tool to diff two images to generate a delta that can 
be applied to one to produce another. This is easy to do with line-oriented 
text files or non-linear xml files but difficult to do with blobs like images. 
Tools like xdelta operate only at bit level and not object level.

Of course, if there was a (normalized) way to transcode .image into .xml and 
vice versa then xmldiff can be used for that purpose.

Subbu

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?


On 14/06/2011, at 1:17 AM, Alan Kay wrote:

 It would be great if everyone on this list would think deeply about how to 
 have an eternal system, and only be amplified by it.

Hi Alan,

You might need to elucidate a little more on this for me to personally 
understand you. Not sure how others feel, but the Worlds work seems to be 
just a description of a versioning pattern applied to running program state. 
Why is it especially interesting? In the Ruby community, we have gem which is 
a package manager and also bundler, the two of which handle dependency 
management and sets of bundles of dependencies in context and situ elegantly 
and beautifully. Depending on your requirements when writing code, you can 
point to a version of a gem, the latest version, or say things like versions 
greater than 2.3. It works really well. It also fits very neatly with your 
idea of (Alexander's? ;-)) the arch and biological cellular structure being a 
scalable system: this system is working in practice extremely well. (Mind you, 
there's a global namespace, so it will eventually get crowded I'm sure ;-))

What do you mean by an eternal system? Do you mean a system which lasts 
forever? and what do you mean by amplified? Do you mean amplified as in our 
energy around this topic, or something else?

Sorry for not understanding you straight away,

Regards,
Julian.___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-13 Thread Josh Gargus


On Jun 13, 2011, at 9:35 AM, Julian Leviston wrote:

 
 On 14/06/2011, at 1:17 AM, Alan Kay wrote:
 
 It would be great if everyone on this list would think deeply about how to 
 have an eternal system, and only be amplified by it.
 
 Hi Alan,
 
 You might need to elucidate a little more on this for me to personally 
 understand you. Not sure how others feel, but the Worlds work seems to be 
 just a description of a versioning pattern applied to running program state.

It seems like much more than that to me.


 Why is it especially interesting? In the Ruby community, we have gem which 
 is a package manager and also bundler, the two of which handle dependency 
 management and sets of bundles of dependencies in context and situ elegantly 
 and beautifully. Depending on your requirements when writing code, you can 
 point to a version of a gem, the latest version, or say things like 
 versions greater than 2.3. It works really well. It also fits very neatly 
 with your idea of (Alexander's? ;-)) the arch and biological cellular 
 structure being a scalable system: this system is working in practice 
 extremely well. (Mind you, there's a global namespace, so it will eventually 
 get crowded I'm sure ;-))
 

Consider that in a Squeak image, the compiled methods are reified as objects.  
With Worlds, you can make exploratory changes to code in a *complex running 
system*, and then back out effortlessly if it doesn't work.  You just throw 
away the World containing the modified code as well as the objects that were 
modified as a side-effect of running the modified code.


 What do you mean by an eternal system? Do you mean a system which lasts 
 forever?

Yes, I believe that's what Alan means.  One things that Worlds do are fill in a 
gap that prevents Smalltalk-80 from being an eternal system.  The problem with 
Smalltalk is that, although it is is possible to make code changes in a running 
image, it is also possible to easily trash the image by making the wrong code 
changes.  Furthermore, the more complicated the system that you're building, 
the easier it is to trash the image.  

To successfully build complex systems in Smalltalk, the typical approach is to 
periodically bootstrap the system by loading code into a fresh image, and 
running initialization scripts to bring the image up to a start-state.  We 
employed this approach at Qwaq/Teleplace.

Worlds provides a way (or at least points in a direction) to never need to shut 
down the running system.  Any changes made to the system can safely and easily 
be reverted.  I don't know how familiar you are with Croquet, but when I 
consider this capability in the context of replicated Islands of objects 
(including code), I find the potential to be breathtaking.


 and what do you mean by amplified? Do you mean amplified as in our energy 
 around this topic, or something else?

I'm not sure that I understood this, either.

Cheers,
Josh



 
 Sorry for not understanding you straight away,
 
 Regards,
 Julian.
 ___
 fonc mailing list
 fonc@vpri.org
 http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-13 Thread Casey Ransberger

Amplification: if I wagered a guess, I'd go with of human reach or of 
potential leverage.

I also have one amp that goes up to 11, which is really nice because sometimes 
I like a touch of extra kick for the solo.


On Jun 13, 2011, at 9:35 AM, Julian Leviston jul...@leviston.net wrote:

 
 On 14/06/2011, at 1:17 AM, Alan Kay wrote:
 
 It would be great if everyone on this list would think deeply about how to 
 have an eternal system, and only be amplified by it.
 
 Hi Alan,
 
 You might need to elucidate a little more on this for me to personally 
 understand you. Not sure how others feel, but the Worlds work seems to be 
 just a description of a versioning pattern applied to running program state. 
 Why is it especially interesting? In the Ruby community, we have gem which 
 is a package manager and also bundler, the two of which handle dependency 
 management and sets of bundles of dependencies in context and situ elegantly 
 and beautifully. Depending on your requirements when writing code, you can 
 point to a version of a gem, the latest version, or say things like 
 versions greater than 2.3. It works really well. It also fits very neatly 
 with your idea of (Alexander's? ;-)) the arch and biological cellular 
 structure being a scalable system: this system is working in practice 
 extremely well. (Mind you, there's a global namespace, so it will eventually 
 get crowded I'm sure ;-))
 
 What do you mean by an eternal system? Do you mean a system which lasts 
 forever? and what do you mean by amplified? Do you mean amplified as in our 
 energy around this topic, or something else?
 
 Sorry for not understanding you straight away,
 
 Regards,
 Julian.
 ___
 fonc mailing list
 fonc@vpri.org
 http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?


On 14/06/2011, at 4:07 AM, Josh Gargus wrote:

 
 On Jun 13, 2011, at 9:35 AM, Julian Leviston wrote:
 
 
 On 14/06/2011, at 1:17 AM, Alan Kay wrote:
 
 It would be great if everyone on this list would think deeply about how to 
 have an eternal system, and only be amplified by it.
 
 Hi Alan,
 
 You might need to elucidate a little more on this for me to personally 
 understand you. Not sure how others feel, but the Worlds work seems to be 
 just a description of a versioning pattern applied to running program state.
 
 It seems like much more than that to me.
 

Cool :) I'm not saying it doesn't have interesting ramifications ;-)


 
 Why is it especially interesting? In the Ruby community, we have gem which 
 is a package manager and also bundler, the two of which handle dependency 
 management and sets of bundles of dependencies in context and situ elegantly 
 and beautifully. Depending on your requirements when writing code, you can 
 point to a version of a gem, the latest version, or say things like 
 versions greater than 2.3. It works really well. It also fits very neatly 
 with your idea of (Alexander's? ;-)) the arch and biological cellular 
 structure being a scalable system: this system is working in practice 
 extremely well. (Mind you, there's a global namespace, so it will eventually 
 get crowded I'm sure ;-))
 
 
 Consider that in a Squeak image, the compiled methods are reified as objects. 
  With Worlds, you can make exploratory changes to code in a *complex running 
 system*, and then back out effortlessly if it doesn't work.  You just throw 
 away the World containing the modified code as well as the objects that were 
 modified as a side-effect of running the modified code.
 

Yes, I've considered this. One of the things that crops up, though, is what 
about data? That is to say, what if one of the world experimentations one 
ends up doing involves experimenting with modifying some of the model of a 
particular piece of code... and this necessarily involve mutating a data type 
(ie model parent object or class implementation)... how does the idea/system 
apply to this, especially when considering things from the point of view of 
concurrent simultaneous users... where one person may mutate the state in the 
discussed manner, but another person is using a different world (a previous 
one with a different data structure in place)... yet they both still need to 
use the same data (ie imagine an address book application where one person is 
mutating the model layer live, and both people are using it live and inputting 
new data)... 

... the idea of published / unpublished (ie published being a particular 
world that is being pointed to as the current live one) seems to serve well 
here.

... also, the idea of modelling change ITSELF is an appealing one in this 
context, and all changes including data entry etc being simply represented as 
a log of mutations using the command pattern. Thus the data represented in the 
first world would be mutated and propagated to the new world (actually more 
like the view of it filtered or some-such) according to the new rules, and 
the inverse would apply as well... 

... of course, the question of irreversible transactions (ie destructive or 
creationist commands) arises... what to do about when adding or destroying 
structure inside a data structure when involving those worlds? (in other words, 
the second, experimental world perhaps has added a title field to a person, 
and then the second world user adds a new person, with the title field... what 
does the first world user see?, etc. This is a superficially simple 
illustration - add some code to the second world which would break if things 
aren't set up in a particular structure, such as a requirement on the title 
for a person, and then the first world entry not actually having a title, and 
we get a bit stickier - this particular example falls apart rather easily, but 
you get the gist, hopefully?)

The worlds idea seems to ignore the fact that the only way to really get the 
feel for something is to use it... so an experiment (ie a child world) would 
need to be using real, live data... so a user or programmer would end up 
with the painful situation of having to migrate their created application 
objects - the data - back into the parent world but not migrate the code back 
if the experiment failed... *or* they would have to treat the experimental 
world as experimental only and not real, but doing this wouldn't actually 
allow one to know whether the experiment was working or not... *or* they'd have 
to use two worlds simultaneously - the first, un-experimental world to just use 
their application, and the second world to test things out until they were 
happy that it would work as they anticipated (ie the experiment worked).

Either way, it could bear more thinking...

Julian.

___
fonc mailing list
fonc@vpri.org

Re: [fonc] Alternative Web programming models?

I wrote this without reading the very latest 
http://www.vpri.org/pdf/tr2011001_final_worlds.pdf so if I say anything that is 
obviously missing that understanding, please bear with me :) I'll read it 
shortly.

Julian.


On 14/06/2011, at 5:26 AM, Julian Leviston wrote:

 
 On 14/06/2011, at 4:07 AM, Josh Gargus wrote:
 
 
 On Jun 13, 2011, at 9:35 AM, Julian Leviston wrote:
 
 
 On 14/06/2011, at 1:17 AM, Alan Kay wrote:
 
 It would be great if everyone on this list would think deeply about how to 
 have an eternal system, and only be amplified by it.
 
 Hi Alan,
 
 You might need to elucidate a little more on this for me to personally 
 understand you. Not sure how others feel, but the Worlds work seems to be 
 just a description of a versioning pattern applied to running program state.
 
 It seems like much more than that to me.
 
 
 Cool :) I'm not saying it doesn't have interesting ramifications ;-)
 
 
 
 Why is it especially interesting? In the Ruby community, we have gem 
 which is a package manager and also bundler, the two of which handle 
 dependency management and sets of bundles of dependencies in context and 
 situ elegantly and beautifully. Depending on your requirements when writing 
 code, you can point to a version of a gem, the latest version, or say 
 things like versions greater than 2.3. It works really well. It also fits 
 very neatly with your idea of (Alexander's? ;-)) the arch and biological 
 cellular structure being a scalable system: this system is working in 
 practice extremely well. (Mind you, there's a global namespace, so it will 
 eventually get crowded I'm sure ;-))
 
 
 Consider that in a Squeak image, the compiled methods are reified as 
 objects.  With Worlds, you can make exploratory changes to code in a 
 *complex running system*, and then back out effortlessly if it doesn't work. 
  You just throw away the World containing the modified code as well as the 
 objects that were modified as a side-effect of running the modified code.
 
 
 Yes, I've considered this. One of the things that crops up, though, is what 
 about data? That is to say, what if one of the world experimentations one 
 ends up doing involves experimenting with modifying some of the model of a 
 particular piece of code... and this necessarily involve mutating a data type 
 (ie model parent object or class implementation)... how does the 
 idea/system apply to this, especially when considering things from the point 
 of view of concurrent simultaneous users... where one person may mutate the 
 state in the discussed manner, but another person is using a different 
 world (a previous one with a different data structure in place)... yet they 
 both still need to use the same data (ie imagine an address book application 
 where one person is mutating the model layer live, and both people are using 
 it live and inputting new data)... 
 
 ... the idea of published / unpublished (ie published being a particular 
 world that is being pointed to as the current live one) seems to serve 
 well here.
 
 ... also, the idea of modelling change ITSELF is an appealing one in this 
 context, and all changes including data entry etc being simply represented 
 as a log of mutations using the command pattern. Thus the data represented in 
 the first world would be mutated and propagated to the new world 
 (actually more like the view of it filtered or some-such) according to the 
 new rules, and the inverse would apply as well... 
 
 ... of course, the question of irreversible transactions (ie destructive or 
 creationist commands) arises... what to do about when adding or destroying 
 structure inside a data structure when involving those worlds? (in other 
 words, the second, experimental world perhaps has added a title field to a 
 person, and then the second world user adds a new person, with the title 
 field... what does the first world user see?, etc. This is a superficially 
 simple illustration - add some code to the second world which would break if 
 things aren't set up in a particular structure, such as a requirement on the 
 title for a person, and then the first world entry not actually having a 
 title, and we get a bit stickier - this particular example falls apart rather 
 easily, but you get the gist, hopefully?)
 
 The worlds idea seems to ignore the fact that the only way to really get the 
 feel for something is to use it... so an experiment (ie a child world) would 
 need to be using real, live data... so a user or programmer would end up 
 with the painful situation of having to migrate their created application 
 objects - the data - back into the parent world but not migrate the code 
 back if the experiment failed... *or* they would have to treat the 
 experimental world as experimental only and not real, but doing this 
 wouldn't actually allow one to know whether the experiment was working or 
 not... *or* they'd have to use two worlds simultaneously - the first, 
 un-experimental world

Re: [fonc] Alternative Web programming models?

2011-06-13 Thread karl ramberg

On Mon, Jun 13, 2011 at 9:31 PM, Julian Leviston jul...@leviston.netwrote:

 I wrote this without reading the very latest
 http://www.vpri.org/pdf/tr2011001_final_worlds.pdf so if I say anything
 that is obviously missing that understanding, please bear with me :) I'll
 read it shortly.



I got wondering about commit failure and cases where you needed certain
objects in the world child anyway.
Or two different worlds merging. Will that be possible ?

NB! A link in document
http://www.vpri.org/pdf/tr2011001_final_worlds.pdf didnt
work
http://www.tinlizzie.org/%CB%9Cawarth/worlds
this works
http://www.tinlizzie.org/~awarth/worlds/

Karl


 Julian.


 On 14/06/2011, at 5:26 AM, Julian Leviston wrote:


 On 14/06/2011, at 4:07 AM, Josh Gargus wrote:


 On Jun 13, 2011, at 9:35 AM, Julian Leviston wrote:


 On 14/06/2011, at 1:17 AM, Alan Kay wrote:

 It would be great if everyone on this list would think deeply about how to
 have an eternal system, and only be amplified by it.


 Hi Alan,

 You might need to elucidate a little more on this for me to personally
 understand you. Not sure how others feel, but the Worlds work seems to be
 just a description of a versioning pattern applied to running program state.


 It seems like much more than that to me.


 Cool :) I'm not saying it doesn't have interesting ramifications ;-)



 Why is it especially interesting? In the Ruby community, we have gem
 which is a package manager and also bundler, the two of which handle
 dependency management and sets of bundles of dependencies in context and
 situ elegantly and beautifully. Depending on your requirements when writing
 code, you can point to a version of a gem, the latest version, or say
 things like versions greater than 2.3. It works really well. It also fits
 very neatly with your idea of (Alexander's? ;-)) the arch and biological
 cellular structure being a scalable system: this system is working in
 practice extremely well. (Mind you, there's a global namespace, so it will
 eventually get crowded I'm sure ;-))


 Consider that in a Squeak image, the compiled methods are reified as
 objects.  With Worlds, you can make exploratory changes to code in a
 *complex running system*, and then back out effortlessly if it doesn't work.
  You just throw away the World containing the modified code as well as the
 objects that were modified as a side-effect of running the modified code.


 Yes, I've considered this. One of the things that crops up, though, is what
 about data? That is to say, what if one of the world experimentations
 one ends up doing involves experimenting with modifying some of the model of
 a particular piece of code... and this necessarily involve mutating a data
 type (ie model parent object or class implementation)... how does the
 idea/system apply to this, especially when considering things from the point
 of view of concurrent simultaneous users... where one person may mutate the
 state in the discussed manner, but another person is using a different
 world (a previous one with a different data structure in place)... yet
 they both still need to use the same data (ie imagine an address book
 application where one person is mutating the model layer live, and both
 people are using it live and inputting new data)...

 ... the idea of published / unpublished (ie published being a particular
 world that is being pointed to as the current live one) seems to serve
 well here.

 ... also, the idea of modelling change ITSELF is an appealing one in this
 context, and all changes including data entry etc being simply represented
 as a log of mutations using the command pattern. Thus the data represented
 in the first world would be mutated and propagated to the new world
 (actually more like the view of it filtered or some-such) according to the
 new rules, and the inverse would apply as well...

 ... of course, the question of irreversible transactions (ie destructive or
 creationist commands) arises... what to do about when adding or destroying
 structure inside a data structure when involving those worlds? (in other
 words, the second, experimental world perhaps has added a title field to a
 person, and then the second world user adds a new person, with the title
 field... what does the first world user see?, etc. This is a superficially
 simple illustration - add some code to the second world which would break if
 things aren't set up in a particular structure, such as a requirement on the
 title for a person, and then the first world entry not actually having a
 title, and we get a bit stickier - this particular example falls apart
 rather easily, but you get the gist, hopefully?)

 The worlds idea seems to ignore the fact that the only way to really get
 the feel for something is to use it... so an experiment (ie a child world)
 would need to be using real, live data... so a user or programmer would
 end up with the painful situation of having to migrate their created
 application objects - the data

Re: Persistence and the Great Horse Trade (was Re: [fonc] Alternative Web programming models?)

2011-06-13 Thread Dale Schumacher

On Mon, Jun 13, 2011 at 2:21 PM, Casey Ransberger
casey.obrie...@gmail.com wrote:
 Comments below.
 On Jun 13, 2011, at 6:00 AM, Dale Schumacher dale.schumac...@gmail.com
 wrote:

 On Mon, Jun 13, 2011 at 4:50 AM, BGB cr88...@gmail.com wrote:

 however, unlike full image-based development, the app will generally
 forget everything that was going on once it is exited and restarted.


 I think this is one of the most annoying features of our current
 computer systems.  If I have a project (or 10 or 20 projects) spread
 out on my workbench, and I leave to have something to eat, or go to
 sleep, when I return everything is still (more or less) in the state I
 left it.

 Dale, when read this it wasn't clear to me what you meant to convey. Are you
 saying it's annoying that when I come back to my bench, I have to swim all
 the way back to the context I was in before or are you saying when I
 return to my bench, it's annoying to have to close all of that stuff because
 what I usually want is a new context anyway?

I'm most definitely saying that I prefer the eternal (as Alan said)
system, with persistent state.

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-13 Thread BGB


On 6/13/2011 3:19 AM, Julian Leviston wrote:


On 13/06/2011, at 7:50 PM, BGB wrote:


On 6/13/2011 1:33 AM, Julian Leviston wrote:

On 12/06/2011, at 1:00 PM, BGB wrote:


image-based systems have their own sets of drawbacks though...

dynamic reload could be a good enough compromise IMO, if done well...
I don't follow this train of thought. Everything runs in an image. 
That's to say, the source code directly relates to some piece of 
running code in the system at some point. Smalltalk, Self and the 
like simply let you interact with the running code in the same place 
as the artefacts that create the running code. It's akin to 
programming in a debugger that saves the contents of memory 
constantly as the source.


except, that traditional source-files have a concrete 
representation as so many files, and, beyond these files, there is 
nothing really of relevance (at least, conceptually, a person could 
print a program to paper, re-type it somewhere else, and expect the 
result to work).


does it rebuild from source? does the rebuilt program work on the 
target systems of interest? if so, then everything is good.



an image based system, OTOH, often means having to drag around the 
image instead, which may include a bunch of other stuff beyond just 
the raw text of the program, and may couple the program and the 
particular development environment used to create it.



[SNIP]


or such...



This brings up an interesting point for me.

Source is an interesting word, isn't it? :) Source of what, exactly? 
Intention, right? The real code is surely the electricity inside the 
computer in its various configurations which represent numbers in 
binary. This is not textual streams, it's binary numbers. The 
representation is the interesting thing as are the abstractions 
that we derive from them.




yes, but as a general rule, this is irrelevant...
the OS is responsible for keeping the filesystem intact, and generally 
does a good enough job, and there one can backups and hard-copies 
in-case things don't work out (say, a good hard crash, and the OS goes 
and mince-meats the filesystem...).


as far as the user/developer can be concerned, it is all text.
more so, it is all ASCII text, given some of the inherent drawbacks of 
using non-ASCII characters in ones' code...



I don't think computer programs being represented as text is very 
appropriate, useful or even interesting. in fact, I'd suffice to say 
that it's a definite hate/love relationship. I *love* typography, text 
and typing, but this has little or naught to do with programming. 
Programming is simply done in this way by me at the moment, 
begrudgingly because I have nothing better yet.


well, the issue is of course, that there is nothing obviously better.


Consider what it'd be like if we didn't represent code as text... and 
represented it maybe as series of ideograms or icons (TileScript nod). 
Syntax errors don't really crop up any more, do they? Given a slightly 
nicer User Interface than tilescript, you could still type your code, 
(ie use the keyboard to fast-select tokens), but the computer won't 
validate any input that isn't in its dictionary of known possible 
syntactically correct items given whatever context you're in.




but, what would be the gain?... the major issue with most possible 
graphical representations, is that they are far less compact. hence, the 
common use of graphical presentations to represent a small amount in 
information in a compelling way (say, a bar-chart or line-graph which 
represents only a small number of data-points).


apparently, even despite this, some people believe in things like UML 
diagrams, but given the time and effort required to produce them, 
combined with their exceedingly low informational density, and I don't 
really see the point.


also, for most programming tasks, graphical presentation would not offer 
any real notable advantage over a textual representation.


at best, one has a pictographic system with a person new to the system 
trying to figure out just what the hell all of these intuitive icons 
mean and do. at that rate, one may almost as well just go make a 
programming language based on the Chinese writing system.


given that most non-Chinese can't read Chinese writing, despite that 
many of these characters do actually resemble crude line-art drawings of 
various things and ideas.


and meanwhile, many Asian countries either have shifted to, or are in 
the process of shifting to, the use of phonetic writing systems (Koreans 
created Hangul, Kanji gradually erodes in favor of Hiragana, ...). even 
in some places in China (such as Canton) the traditional writing system 
is degrading, with many elements of their spoken dialect being 
incorporated into the written language.


this could be taken as an indication that their may be some fundamental 
flaw with pictographic or ideographic systems.


or, more directly:
many people new to icons-only GUI designs spend some

Re: [fonc] Alternative Web programming models?

2011-06-13 Thread C. Scott Ananian

On Mon, Jun 13, 2011 at 4:02 PM, BGB cr88...@gmail.com wrote:
 Consider what it'd be like if we didn't represent code as text... and
 represented it maybe as series of ideograms or icons (TileScript nod).
 Syntax errors don't really crop up any more, do they? Given a slightly nicer
 User Interface than tilescript, you could still type your code, (ie use the
 keyboard to fast-select tokens), but the computer won't validate any input
 that isn't in its dictionary of known possible syntactically correct items
 given whatever context you're in.

I think Tiles prevent syntax errors is a red herring.  Sure, you can
prevent stupid typos by offering only tiles with correctly spelled
keywords, but that's not really a major problem in ordinary
experience.  The more pernicious errors aren't especially affected one
way or the other by tile-based systems.  (You could just as accurately
say that strongly-typed systems prevent errors.)

 given that most non-Chinese can't read Chinese writing, despite that many of
 these characters do actually resemble crude line-art drawings of various
 things and ideas.

It is a common linguistic misperception that there is some one-to-one
correspondence between an ideogram and the idea it represents.  The
english letter A was originally a drawing of an ox-head.
(http://en.wikipedia.org/wiki/A).  It is as accurate to say that
English letters resemble crude line-art drawings as to say that
Chinese ideograms do.

 and meanwhile, many Asian countries either have shifted to, or are in the
 process of shifting to, the use of phonetic writing systems (Koreans created
 Hangul, Kanji gradually erodes in favor of Hiragana, ...). even in some
 places in China (such as Canton) the traditional writing system is
 degrading, with many elements of their spoken dialect being incorporated
 into the written language.

This is also playing fast and loose with linguistics.  Let's be wary
of drawing analogies to fields where we are not expert.
  --scott

-- 
      ( http://cscott.net )

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Age and Language (was Re: [fonc] Alternative Web programming models?)

2011-06-13 Thread Casey Ransberger

Below.

On Jun 13, 2011, at 2:16 PM, C. Scott Ananian csc...@laptop.org wrote:

 On Mon, Jun 13, 2011 at 4:02 PM, BGB cr88...@gmail.com wrote:
 Consider what it'd be like if we didn't represent code as text... and
 represented it maybe as series of ideograms or icons (TileScript nod).
 Syntax errors don't really crop up any more, do they? Given a slightly nicer
 User Interface than tilescript, you could still type your code, (ie use the
 keyboard to fast-select tokens), but the computer won't validate any input
 that isn't in its dictionary of known possible syntactically correct items
 given whatever context you're in.
 
 I think Tiles prevent syntax errors is a red herring.  Sure, you can
 prevent stupid typos by offering only tiles with correctly spelled
 keywords, but that's not really a major problem in ordinary
 experience.  The more pernicious errors aren't especially affected one
 way or the other by tile-based systems.  (You could just as accurately
 say that strongly-typed systems prevent errors.)

Agreed, when we're talking about adults, and especially ones who've already 
learned to code. When it comes to kids and non-programming adults though, I do 
think that e.g. Scratch is really powerful.

I don't have the cognitive science to back up the statement that I'm about to 
make, so I'm hoping folks will try to shoot some holes in it.

Kids may not have the linguistic development out of the way that one needs to 
do serious programming. Adults who don't already code may find themselves 
short on some of the core concepts that conventional programming languages 
expect of the user. In both cases, I think visual systems can get useless 
syntactic hurdles out of the way, so that users can focus of developing a 
command of the core concepts at work.

Inviting criticism! Fire away, ladies and gentlemen.___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?


On 14/06/2011, at 6:02 AM, BGB wrote:

 but, what would be the gain?... the major issue with most possible graphical 
 representations, is that they are far less compact. hence, the common use of 
 graphical presentations to represent a small amount in information in a 
 compelling way (say, a bar-chart or line-graph which represents only a 
 small number of data-points).

If it gets longer than a page, something's gone wrong somewhere. ;-) Remember, 
most people on this list will think encapsulation and objects are good things 
;-) (ie small bits of code). So you don't need the kind of compactness you're 
talking about.

The gain is that a picture speaks a thousand words.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)


On 14/06/2011, at 7:33 AM, Casey Ransberger wrote:

 Kids may not have the linguistic development out of the way that one needs to 
 do serious programming. Adults who don't already code may find themselves 
 short on some of the core concepts that conventional programming languages 
 expect of the user. In both cases, I think visual systems can get useless 
 syntactic hurdles out of the way, so that users can focus of developing a 
 command of the core concepts at work.
 

In most parts of the world, Monks used to be the only people who could read and 
write, you know. ;-)

Julian.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?


On 14/06/2011, at 7:16 AM, C. Scott Ananian wrote:

 Consider what it'd be like if we didn't represent code as text... and
 represented it maybe as series of ideograms or icons (TileScript nod).
 Syntax errors don't really crop up any more, do they? Given a slightly nicer
 User Interface than tilescript, you could still type your code, (ie use the
 keyboard to fast-select tokens), but the computer won't validate any input
 that isn't in its dictionary of known possible syntactically correct items
 given whatever context you're in.
 
 I think Tiles prevent syntax errors is a red herring.  Sure, you can
 prevent stupid typos by offering only tiles with correctly spelled
 keywords, but that's not really a major problem in ordinary
 experience.  The more pernicious errors aren't especially affected one
 way or the other by tile-based systems.  (You could just as accurately
 say that strongly-typed systems prevent errors.)

When you're about to type the next tile, you're given options... anything 
outside of those options is impossible, so the computer doesn't put it in, 
because syntactically it wouldn't make sense. Do you see the power of options, 
here? :) It's another level of introspection for the programmer on the system 
that is possible if they need or want it.

shrug some people like the computer to do things like highlight matching 
parenthesis, provide code syntax highlighting and colouring... others don't. 
(I'm not sure who doesn't).

But we're kind of digressing from the point about the kinds of visual systems 
that I was originally talking about when mentioning TileScript. This isn't 
necessarily at all TileScript I'm talking about... it's about visual patterning 
languages (i'm using the term languages very loosely here). TileScript was 
simply a nod...  If you've used any kind of visual math formula builder like 
the one that used to be present in Microsoft Word I think (and probably still 
is, I don't know), then you know what I'm talking about.. the syntax is 
visually patterned in front of you as soon as it becomes apparent to the 
computer that you're writing a certain kind of math, so you can see what's 
going on... this stuff is very useful, I'm not sure why you can't see the 
benefit of it... perhaps you're just too attached to text? :)

As my memory recalls, Alan (and the entire VPRI crew I think) has said in the 
past, Math wins. Math is not written as a linear text per se, is it? Except, 
of course, where sequence is important ;-)

Julian.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-13 Thread Yoshiki Ohshima

At Mon, 13 Jun 2011 21:55:54 +0200,
karl ramberg wrote:
 
 I got wondering about commit failure and cases where you needed certain 
 objects in the world child anyway.
 Or two different worlds merging. Will that be possible ?

  Yes.  You catch an exception to keep the computation going:

  a := WPoint2 new x: 1; y: 0.
  w := WWorld2 thisWorld sprout.
  w eval: [a y: a y + 1].
  a y: 666.
  [w commit] on: Error do: [:ex | ].

then you can say:

  b := WPoint2 new.
  b x: (w eval: [a x]).
  b y: (w eval: [a y]).

to salvage the values of a in w into b in the top level world.

There should be more first class operations allowed, and perhaps the
serializability checks and commit logic should be customizable...

-- Yoshiki

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-13 Thread C. Scott Ananian

On Mon, Jun 13, 2011 at 11:17 PM, Julian Leviston jul...@leviston.net wrote:
 I think Tiles prevent syntax errors is a red herring.  Sure, you can
 prevent stupid typos by offering only tiles with correctly spelled
 keywords, but that's not really a major problem in ordinary
 experience.  The more pernicious errors aren't especially affected one
 way or the other by tile-based systems.  (You could just as accurately
 say that strongly-typed systems prevent errors.)

 When you're about to type the next tile, you're given options... anything 
 outside of those options is impossible, so the computer doesn't put it in, 
 because syntactically it wouldn't make sense.

There's nothing specific to tiles in what you wrote.  You could do the
same just as easily with a keyboard-based system.
This is what I mean when I say that tiles prevent syntax errors is
not accurate; it's confusing two separate things.
Again: more accurately you could say, strong typing can prevent
syntax errors...  tiles have nothing to do with it, really.
  --scott
-- 
      ( http://cscott.net )

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?


On 14/06/2011, at 1:50 PM, C. Scott Ananian wrote:

 When you're about to type the next tile, you're given options... anything 
 outside of those options is impossible, so the computer doesn't put it in, 
 because syntactically it wouldn't make sense.
 
 There's nothing specific to tiles in what you wrote.  You could do the
 same just as easily with a keyboard-based system.
 This is what I mean when I say that tiles prevent syntax errors is
 not accurate; it's confusing two separate things.
 Again: more accurately you could say, strong typing can prevent
 syntax errors...  tiles have nothing to do with it, really.

Assuming a compile after composing type of system. If it's a running, live, 
system, then type is irrelevant because an object at the point of being 
talked to will provide its own semantic and therefore 
syntactic-appropriateness context (ie duck typing for want of a better term). 
Do you see why I think text-stream based systems are outmoded crappy systems 
yet?

They're not real in the sense of first-level representational. It's the 
equivalent of me sending you this email by fax, and you running an OCR program 
across it so it can get into your computer, though obviously less error-prone.

However... not to be rude, but you're potentially missing my larger point, 
which was underneath the two lines you quoted... and you're perhaps getting 
caught on my bad example of syntax in TileScript - I'm saying the 
possibilities and ramifications of programming a live system using 
non-text-stream representation are far greater than that of text-stream ones... 
either that, or we have to re-engineer the natural possibilities after the 
fact... (ie Eclipse Java IDE is an example of doing this... where the IDE knows 
a lot about the language, rather than asking real live objects about 
themselves). Instead of having actual one-level-linked instantiated objects AT 
THE POINT of programming, we use multi-layered deferred referencing (ie 
text-stream based codes which are later processed and further decoded into 
computer codes by another computer program many times).

One of the troubles with computing is that there are so many layers between 
what's real and the user that we've forgotten how to deal directly with the 
real. We've forgotten what is happening when we use computers, and this is sad 
and needs to be addressed. It's the real that's exciting, interesting and 
impassion-ating...

... granted there will always be those who don't want to see the real, and for 
those people, we build layers on top (ie Apple products), but still allow the 
guts to be got at by those who wish it. Presently it's SO DIFFICULT to get at 
the guts and not because it's hard to fire up GCC... mostly it's the learning 
that gets in the way... (at least, that's my experience). The sheer amount of 
education one needs to get through before one can get to the point where one is 
a true systems expert on our current top-level systems is colossal, and this is 
mostly due to cruft, IMHO.

Julian.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-13 Thread BGB


On 6/13/2011 8:39 PM, Yoshiki Ohshima wrote:

At Mon, 13 Jun 2011 17:16:10 -0400,
C. Scott Ananian wrote:

given that most non-Chinese can't read Chinese writing, despite that many of
these characters do actually resemble crude line-art drawings of various
things and ideas.

It is a common linguistic misperception that there is some one-to-one
correspondence between an ideogram and the idea it represents.  The
english letter A was originally a drawing of an ox-head.
(http://en.wikipedia.org/wiki/A).  It is as accurate to say that
English letters resemble crude line-art drawings as to say that
Chinese ideograms do.


except that in the case of the Latin alphabet, all association with the 
original idea has long since gone away, and alphabetic characters have 
no real meaning in themselves, besides a loose association with a 
particular sound.


the pictographs generally have meanings more closely associated with 
particular things and idea.


like, a tree sort of resembles a tree, ...



and meanwhile, many Asian countries either have shifted to, or are in the
process of shifting to, the use of phonetic writing systems (Koreans created
Hangul, Kanji gradually erodes in favor of Hiragana, ...). even in some
places in China (such as Canton) the traditional writing system is
degrading, with many elements of their spoken dialect being incorporated
into the written language.

This is also playing fast and loose with linguistics.  Let's be wary
of drawing analogies to fields where we are not expert.

   Yup.  Such as this:

http://pugs.blogs.com/audrey/2009/10/our-paroqial-fermament-one-tide-on-another.html

is mainly in the context of # of characters, but also illustrates the
area it requires to convey the same amount of information.

   (And yup, I can tell you Japanese aren't erodes in favor of
Hiragana...)



sorry...

just I thought it was that originally nearly all of the writing was 
using Kanji, but over a long time (many centuries), the use of Kanji has 
lessened some, and Hiragana has become a larger portion of the text.


admittedly, I don't really know Japanese either though... (besides what 
I can gain from watching lots of anime...).


I have had some (limited) amount of personal experience interacting with 
Chinese people, but don't know Chinese either (can't really 
read/write/speak it, but can recognize a few of the basic characters...).



by complaining about density previously, I wasn't thinking like 
traditional pictographs though, so much as people doing similar with 
icons, say 64x64 pixels or so (like, more like Windows icons), and so 
would lead to a larger portion of the screen being needed than with 
words, or with the tradition of assigning meaning to particular globs of 
ASCII characters (say, -, =, =, ++, ...).


or, people using UML diagrams and flow charts, which use large amounts 
of screen or paper space, and often express less than could be stated 
with a few lines of text.


and also, that I don't personally believe a pictographic system to be 
inherently more intuitive than an equivalent word-based system, and 
maybe less so, given the general tool tips experience (like, hover 
mouse to try to figure out just what a given icon on the toolbar is 
supposed to do...).



or such...


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-11 Thread C. Scott Ananian

On Sat, Jun 11, 2011 at 1:40 AM, BGB cr88...@gmail.com wrote:
 The responsiveness of exploratory programming environments (such as the
 Smalltalk programming environment) allows the programmer to concentrate on
 the task at hand rather than being distracted by long pauses caused by
 compilation or linking.

 this is also partly where dynamic script loading and eval can be nifty...
 say, one is using an app, and then in the console they type in a command,
 say:
 ;load(scripts/myscript.bs);
 and can quickly edit the file, hit the uparrow in the console to re-enter
 the prior command, and observe the results.
 or, the ability to directly type script commands into the console to observe
 results, ...

You should spend some time playing around with the Web Inspector in
Chrome or other Webkit browser.  Console, live code editing, lots of
other good stuff.  The only big drawback is the complexity of the
system: HTML+CSS+JS is quite a hairy beast.

 but, I was also left recently thinking some about the possible strangeness
 of me basically creating a vaguely Lisp-like programming environment within
 C.

http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule
  --scott

-- 
      ( http://cscott.net )

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-11 Thread BGB


On 6/11/2011 6:30 PM, C. Scott Ananian wrote:

On Sat, Jun 11, 2011 at 1:40 AM, BGBcr88...@gmail.com  wrote:

The responsiveness of exploratory programming environments (such as the
Smalltalk programming environment) allows the programmer to concentrate on
the task at hand rather than being distracted by long pauses caused by
compilation or linking.

this is also partly where dynamic script loading and eval can be nifty...
say, one is using an app, and then in the console they type in a command,
say:
;load(scripts/myscript.bs);
and can quickly edit the file, hit the uparrow in the console to re-enter
the prior command, and observe the results.
or, the ability to directly type script commands into the console to observe
results, ...

You should spend some time playing around with the Web Inspector in
Chrome or other Webkit browser.  Console, live code editing, lots of
other good stuff.  The only big drawback is the complexity of the
system: HTML+CSS+JS is quite a hairy beast.



yeah...

my current strategy already involves some amount of typing commands into 
the console...
as noted in the other post, the main role that load(...) serves, is 
that I am limited to about 100 characters at a time I can type into the 
console, which is a limitation.


edit/reload/go is more of a compromise...



but, I was also left recently thinking some about the possible strangeness
of me basically creating a vaguely Lisp-like programming environment within
C.

http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule
   --scott


except, in my case, there is a more direct reason:
long ago, I had messed around with Scheme, and implemented a Scheme VM;
many Scheme-like facilities and practices have managed to somewhat 
outlive the original VM, but were just sort of kludged back onto C, and 
became a part of the baseline coding practice.


or such...



___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-10 Thread Josh Gargus


On Jun 9, 2011, at 2:38 PM, Casey Ransberger wrote:

 
 
 On Jun 9, 2011, at 11:01 AM, Josh Gargus j...@schwa.ca wrote:
 
 Conceptually, yes.  In practice, no, because the HTML/DOM render-target is 
 also the lingua franca that makes the Web searchable and mashupable.  
 
 So I'd like to first point out that you're making a great point here, so I 
 hope it isn't too odd that I'm about to try to tear it down. Devil's advocate?

Sure, why not?

You said a bunch of interesting things that circle around a point.  Rather than 
respond to some of them individually, which would miss the point, I'm going to 
have to ruminate about the whole for a while.

Cheers,
Josh
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-10 Thread Chris Warburton

On Thu, 2011-06-09 at 11:42 -0700, BGB wrote:
 interesting...
 less painfully slow than I would have expected from the description...
 
 I wasn't thinking exactly like run an emulator, run OS in emulator, 
 but more like, a browser plugin which looked and acted similar to a 
 small Unix (with processes and so on, and a POSIX-like API, and a 
 filesystem), but would likely be different in that it would mount 
 content from the website as part of its local filesystem (probably 
 read-only by default), and possibly each process could have its own 
 local VFS.
 
 screen/input/... would be provided by APIs.
snip

  However, such a hypervisor will also host more ambitious OSes, for
 example, platforms for persistent capability-secure peer-to-peer
 real-time collaborative end-use-scriptable augmented-reality
 environments.  (again, trying to use word-associations to roughly
 sketch what I'm referring to, as I did earlier with
 Croquet-Worlds-Frank-OMeta-whatnot).
 
  Does this make my original question clearer?
 
 ok.
 
 what exactly this would be like is less obvious.
 I personally have a much easier time imagining what Unix in a browser 
 would look like.
 
 
 with just a plain OS in the browser though, one could run apps...
 
 then one could have 3D mostly by having this virtual OS expose OpenGL 
 (or GL ES).
 
 possibly, for sake of simplicity, the app could always use OpenGL, 
 just its text mode would just be using OpenGL to draw all the characters.
 
 then maybe some special API calls for handling input, and enabling GL 
 (disabling drawing the console UI).
 
 
 I before wondered about the problem of what to do about client-program 
 memory use, but it seems like there is a nifty solution: if a limit is 
 exceeded, allocation calls fail (say, each process is limited to a 
 certain amount of memory).
 
 possibly, a given app is also limited to a certain maximum number of 
 child processes, at which point fork() calls will fail (or send out a 
 SIGKILL or similar to all processes belonging to the parent app).
 
 
 or such...

I've been following this discussion and it seems there are a lot of very
interesting ideas floating around, but I'm afraid I'm finding a lot of
it to be getting rather bogged down in details like plugins, processes,
etc. Forgive me if I'm missing something fundamental here, but to me
Alan's contrast of browser as application vs browser as OS can be
roughly translated to the browser is the 'real' application, the pages
are just data it reads vs the pages are the 'real' applications, the
browser just implements the lower levels of the stack.

The latter viewpoint is gradually taking over now, where those lower
levels are currently CPU (Javascript engine), storage (cookies, HTML5
local SQL, ...), networking (XMLHttpRequest, WebSockets, ...), display
(DOM, canvas, WebGL, SVG, ...), IO interrupts (events) and so on.

Can I ask how this is not an OS?

Regards,
Chris Warburton


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-10 Thread C. Scott Ananian

On Jun 9, 2011, at 5:58 AM, Julian Leviston jul...@leviston.net wrote:
 On 09/06/2011, at 7:04 PM, BGB wrote:
 actually, possibly a relevant question here, would be why Java applets 
 largely fell on their face, but Flash largely took off (in all its uses from 
 YouTube to Punch The Monkey...).
 My own opinion of this is the same reason that the iPad feels faster than a 
 modern desktop operating system: it was quicker to get to the user 
 interaction point.
 Julian.

The slow startup time is indeed why Sun's own team felt that Java
failed to get traction.  Unfortunately some basic architecture choices
in the standard library made it extremely difficult to fix the
problem.  (Broadly, how class initialization is handled and used.) The
latest Java plugins contain some impressive engineering to mitigate
the problem, but Java is still sluggish to start in my experience.

Library design matters!
 --scott

-- 
      ( http://cscott.net )

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-10 Thread BGB


On 6/10/2011 7:33 AM, Chris Warburton wrote:

On Thu, 2011-06-09 at 11:42 -0700, BGB wrote:

interesting...
less painfully slow than I would have expected from the description...

I wasn't thinking exactly like run an emulator, run OS in emulator,
but more like, a browser plugin which looked and acted similar to a
small Unix (with processes and so on, and a POSIX-like API, and a
filesystem), but would likely be different in that it would mount
content from the website as part of its local filesystem (probably
read-only by default), and possibly each process could have its own
local VFS.

screen/input/... would be provided by APIs.

snip


However, such a hypervisor will also host more ambitious OSes, for
example, platforms for persistent capability-secure peer-to-peer
real-time collaborative end-use-scriptable augmented-reality
environments.  (again, trying to use word-associations to roughly
sketch what I'm referring to, as I did earlier with
Croquet-Worlds-Frank-OMeta-whatnot).

Does this make my original question clearer?

ok.

what exactly this would be like is less obvious.
I personally have a much easier time imagining what Unix in a browser
would look like.


with just a plain OS in the browser though, one could run apps...

then one could have 3D mostly by having this virtual OS expose OpenGL
(or GL ES).

possibly, for sake of simplicity, the app could always use OpenGL,
just its text mode would just be using OpenGL to draw all the characters.

then maybe some special API calls for handling input, and enabling GL
(disabling drawing the console UI).


I before wondered about the problem of what to do about client-program
memory use, but it seems like there is a nifty solution: if a limit is
exceeded, allocation calls fail (say, each process is limited to a
certain amount of memory).

possibly, a given app is also limited to a certain maximum number of
child processes, at which point fork() calls will fail (or send out a
SIGKILL or similar to all processes belonging to the parent app).


or such...

I've been following this discussion and it seems there are a lot of very
interesting ideas floating around, but I'm afraid I'm finding a lot of
it to be getting rather bogged down in details like plugins, processes,
etc. Forgive me if I'm missing something fundamental here, but to me
Alan's contrast of browser as application vs browser as OS can be
roughly translated to the browser is the 'real' application, the pages
are just data it reads vs the pages are the 'real' applications, the
browser just implements the lower levels of the stack.

The latter viewpoint is gradually taking over now, where those lower
levels are currently CPU (Javascript engine), storage (cookies, HTML5
local SQL, ...), networking (XMLHttpRequest, WebSockets, ...), display
(DOM, canvas, WebGL, SVG, ...), IO interrupts (events) and so on.

Can I ask how this is not an OS?


errm...

I don't know...


as for differences from an OS:
it doesn't boot up with the hardware;
it doesn't have an obvious kernel (say, a core which runs the processor 
in Ring-0 or similar);
it doesn't provide process management or system calls (except maybe 
builtin functions in JavaScript?...);

...

there is not a whole lot that seems in common between a browser and an OS.

yes, there is Chrome OS, but I sort of suspect this will (probably) fall 
on its face (vs... say... installing real Linux on the netbooks...).



there is a lot more in common with it being an application:
it resides in Program Files or /usr/bin or similar;
it starts up after the main OS, and usually by direct action of the user;
it lives within a window, or multiple windows (it itself provides the UI);
...

it could be compared to a platform though, say similar to .NET or the 
JDK, which both have OS-like and application-like aspects:

they run on top of the underlying OS;
they sit around in the background (not generally directly visible to users);
they launch other programs on top of themselves;
...


otherwise, one would get into issues like, say, how is a modern game 
engine, such as Steam / Source, not an OS?... (yes, Steam and Source 
are technically separate product-wise, but share much of the same 
underlying architecture, and targeting apps to Steam often involves 
summoning up Source as a sort of a slave backend, such as for VFS and 
graphics/user-input services). when Source is being used as a game, it 
may summon up maps, which may have a lot going on internally, and may 
use mods, many of which used scripts (often Lua), ...


however, IMO, they are not really an OS, more 'platforms'...

and, many people would likely find the idea of booting a computer 
directly into the Source Engine to be a little silly... (start 
computer... start playing Portal 2...).


Steam could make a little more sense, since Steam is basically a 
glorified program downloader and launcher (and, interestingly, does some 
of its content presentation via HTML, IIRC).


Valve Steam OS, coming soon... but,

Re: [fonc] Alternative Web programming models?

2011-06-10 Thread BGB


On 6/10/2011 10:24 AM, C. Scott Ananian wrote:

On Jun 9, 2011, at 5:58 AM, Julian Levistonjul...@leviston.net  wrote:

On 09/06/2011, at 7:04 PM, BGB wrote:

actually, possibly a relevant question here, would be why Java applets largely fell on 
their face, but Flash largely took off (in all its uses from YouTube to Punch The 
Monkey...).

My own opinion of this is the same reason that the iPad feels faster than a 
modern desktop operating system: it was quicker to get to the user interaction 
point.
Julian.

The slow startup time is indeed why Sun's own team felt that Java
failed to get traction.  Unfortunately some basic architecture choices
in the standard library made it extremely difficult to fix the
problem.  (Broadly, how class initialization is handled and used.) The
latest Java plugins contain some impressive engineering to mitigate
the problem, but Java is still sluggish to start in my experience.

Library design matters!
  --scott


yep... Java does a lot of things in the library which could generally be 
considered a bad thing for performance.


one thing that took my attention before was noting just how many cases 
there are of operations taking the form:

new Something(...).someMethod(...);.

in places which could potentially impact performance if one is not 
careful (at least presuming the VM doesn't infer that the object is 
one-off and micro-optimize it some).



just had an idle thought of a JVM starting up as a prebuilt image 
(say, methods are pre-JIT'ed and pre-linked, static fields are 
pre-initialized, ...).


unless of course, they already started doing this (sadly, I am not much 
an expert on the JVM).


AFAIK, the main strategy generally used is to demand-load classes 
one-at-a-time from the JAR files, potentially validate them, JIT their 
methods, and call the sinit or similar static method. this process 
then may partly play out recursively, each class causing demand-loading 
more classes, ... until all relevant classes are loaded.


or, maybe it is that, within the class library, most classes are tangled 
up with many other classes, essentially turning the class library into 
some large bulk-loaded glob?...



well, not that my VM can say that much... sadly, in the present 
architecture, the toplevel is executed, which may in-turn load more code 
(the toplevel is itself a giant static initializer, and any 
functions/classes/... are built when their code is executed).


a sad result of this is that using executable statements/expressions in 
the toplevel, it is possible to fetch 'null' from slots prior to them 
being initialized, creating ordering issues in some cases.


say:
var foo=[bar, bar];
function bar() { ... }
foo[0] will currently hold null...

this is not an issue for normal calls though, since the call will 
generally happen following any needed functions having been assigned to 
their slots.


addressing the issue at present would likely require ugly hacks.


or such...


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-10 Thread C. Scott Ananian

On Fri, Jun 10, 2011 at 2:45 PM, BGB cr88...@gmail.com wrote:
 just had an idle thought of a JVM starting up as a prebuilt image (say,
 methods are pre-JIT'ed and pre-linked, static fields are pre-initialized,
 ...).
 unless of course, they already started doing this (sadly, I am not much an
 expert on the JVM).

Yes, they do this already; but this was part of the startup-time
optimizations which weren't initially present in the JVM.

 or, maybe it is that, within the class library, most classes are tangled up
 with many other classes, essentially turning the class library into some
 large bulk-loaded glob?...

Yes, that was a large part of the initial problem.  A particular
culprit was the String class, which wanted to have lots of convenient
hooks for different features (including locale-specific stuff like
uppercase/lowercase  sorting, regexs, etc) but that tangled it up
with everything else.  The basic JVM bytecode demanded intern'ed
strings, which required String class initialization, which then
required on-the-fly locale loaded based on environment variables
(removing the ability to precompile and image), and things went
rapidly downhill from there.

 a sad result of this is that using executable statements/expressions in the
 toplevel, it is possible to fetch 'null' from slots prior to them being
 initialized, creating ordering issues in some cases.

Yes, this was another fundamental problem with the JVM.  You needed
intimate knowledge of the library implementation in order to do
initial class initialization in the proper order to avoid crashes.
  --scott

-- 
      ( http://cscott.net )

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-10 Thread Max OrHai

On Fri, Jun 10, 2011 at 11:09 AM, BGB cr88...@gmail.com wrote:
 snip ... 

 there is not a whole lot that seems in common between a browser and an OS.

 yes, there is Chrome OS, but I sort of suspect this will (probably) fall on
 its face (vs... say... installing real Linux on the netbooks...).


BGB, you're being waay too literal-minded! This thread was (I thought) about
architecture, rather than implementation details of current technologies.

Chrome OS is a case in point, and FWIW, I expect it to succeed, maybe even
beyond Android, because it's been carefully built to give a seamless,
painless end-user experience. That's what most people want. Almost everyone
who casually uses a computer day-to-day doesn't give a damn about how
powerful or configurable it is. They just want it to work, get out of
their way, and not irritate them unnecessarily. Increasingly, most people
spend most of their computer time in a browser anyway. For quite a few, that
is (or easily could be) *all* of their time. Chrome OS just trims away
several layers of what these users would consider pointless complexity. As
others here have mentioned, the Web has *already* become the de-facto
universal communications medium.

The interesting question to me is, how do we help ordinary people (like, you
know, children) *use* this powerful new medium to learn, experiment, express
and communicate powerful ideas? As far as this question is concerned Chrome
OS and the Lively Kernel bring us back up to almost the level of Smalltalk
(plus or minus some semantic noise from Javascript, but hey). Surely we can
do better...

-- Max
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

This vs. That (was Re: [fonc] Alternative Web programming models?)

2011-06-10 Thread Casey Ransberger

Hahaha, this is it exactly! 

Perpendicular, but a poignant friend/mentor of mine said real software 
engineering hasn't emerged because there aren't enough people dying yet.

He said that after I made my bid on what the difference is. My angle was: the 
difference between software and engineering is just that when the real bridge 
you designed falls over with people on it, you probably won't work again, 
whereas in software we just apologize to the users and just ship a nice hotfix 
for them. 

In any event it seems that he and I agree that the difference is usually one of 
consequence, or lack thereof. 

I must tip my hat, however, to Alan's argument that we haven't even found our 
arches yet. This just resonates with me, especially after stomaching all of 
this best-practice-as-religion crap in industry; I really want more evidence 
that we haven't got a clue what we're doing yet, because it would be lovely to 
dispel the myth that we do. 

On Jun 10, 2011, at 3:00 PM, Craig Latta cr...@netjam.org wrote:

 
 Can I ask how this is not an OS?
 
 Operating systems have more entertaining failure modes... if a
 really bad crash can render the hardware unbootable, it's an operating
 system. :)
 
 
 -C
 
 --
 Craig Latta
 www.netjam.org/resume
 +31   6 2757 7177
 + 1 415  287 3547
 
 
 ___
 fonc mailing list
 fonc@vpri.org
 http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

history (Re: [fonc] Alternative Web programming models?)

2011-06-10 Thread BGB


(sorry, I don't know if this belongs on-list or not...).


On 6/10/2011 1:44 PM, Max OrHai wrote:

Well, INTP here, so at least we have /some/ common ground.



yeah... I think I generally get along well enough with most people, in 
general...


well, except Q's, which are basically people who act sort of like Q 
from Star Trek and generally start being all condescending about how 
stupid I supposedly am, ...


well, and females... things are just not generally prone to go well in 
this area... nothing immoral, mostly just they just tend to either be 
scared off, or things quickly get really awkward, so things tend to go 
nowhere...


well, me and working with people, sadly, doesn't usually go well... 
although I guess, as great as the idea of people working together for a 
common goal and a common good may seem, cooperative projects soon turn 
into lots of arguing and people stepping all over each other.


so, it has often usually just been me by myself, mostly doing my own 
thing...





For me it was:
 Apple II BASIC --
   Classic Macintosh with HyperCard --
BASH / C / Python on Linux --
   disgusted with computers entirely and more or less Luddite 
for about 5 years --

  Blackberry OS on my phone  --
  Smalltalk, Scheme, Haskell, and JavaScript/HTML on 
slightly better Linuxes --

  Same stuff on Mac OS X, mostly. Also, NetLogo.

I write this from work, where I'm juggling Fedora and WinXP, neither 
of which quite just work for the fairly simple tasks I expect of them.




yeah...

well, as noted before:
MS-DOS, QBasic, ...

I also ran Win 3.11 and Win32s, IIRC because I think for some reason I 
didn't really like Win95, and Win32s ran many Win95 apps.


later on, I jumped ship to Linux, which generally forced a complete 
switch over to C for coding (I could no longer use QBasic, being it was 
Linux and all...).



later on, came across Scheme (late 90s), and at first used Guile, and 
then ended up doing my own implementation, partly because at the time 
Guile did stuff that I personally found really annoying (generally, it 
was hard-coded to call abort() at the first sign of trouble, ...).


by a few years later (2003), this had turned unmaintainable (complex and 
nasty code), and so I dropped the VM and most code which was built 
around it. at the time, I had figured well, I am just going to write 
crap in plain C


then later (maybe at most a few months) was like, doing everything in 
plain C is lame...


at first, I implemented a PostScript variant, then realized that it was 
unusably terrible (trying to write code in PS, OMG this sucks...). 
basically, tokens were parsed and converted fairly directly into bytecode.


I also ran across JavaScript, and was like oh wow, this is cool
so, I threw together a few things, and then had my own makeshift 
JavaScript imitation (I first called it PDScript, but later renamed it 
BGBScript...). this was in early 2004.


actually, parts that went into it originally:
most of the machinery from the original PostScript interpreter (this 
formed the lower levels);

a lot of XML-processing code (a DOM-like system);
a recursive-descent parser, doing a JS-like syntax (parsing directly 
into XML nodes).


so, basically: BGBScript - XML - PostScript (sort of...)
the GC was also conservative mark/sweep with raw pointers.

it was also teh slow and spewed huge amounts of garbage, which was not 
good with a slow conservative GC.



a later partial rewrite (in 2006) re-incorporated a number of parts from 
the original Scheme VM (and made a number of language-level changes), 
and switched over to using S-Expressions as the internal representation 
for the ASTs, as well as re-using a variant of the Scheme-VM's GC 
(precise mark/sweep with reference-counting and tagged references).

the 2006 VM also had a working JIT.

in 2007, a C compiler was written, which switched back to XML for the 
ASTs (it was built more from code from the 2004 BGBScript 
implementation). the initial motivation was mostly that 
dynamically-compiled C could probably interface much better with native 
C. but, the compiler was very slow and buggy...


in 2008, BGBScript was partly rewritten again, mostly switching back to 
the other GC (conservative mark/sweep), mostly as the precise-GC was 
painful to work with. sadly, this broke the JIT, and made it all a bit 
slower, and I have not (as of yet) fixed it (the interpreter is fast 
enough...). stuck with S-Expressions for the ASTs as well.


and, in early 2010, added a bunch of spiffy new FFI stuff (mostly to 
eliminate most of the boilerplate needed to call into C code...). the 
FFI is itself partly built on parts of the C compiler though.


late 2010/early 2011, tried to make a spiffy new VM and a new language 
(BGBScript2), but this effort fell on its face (too much effort and not 
getting working fast enough), and I later just reincorporated a lot of 
the planned features back into

Re: [fonc] Alternative Web programming models?

On May 31, 2011, at 7:30 AM, Alan Kay wrote:

Hi Cornelius

There are lots of egregiously wrong things in the web design. Perhaps one of
the simplest is that the browser folks have lacked the perspective to see
that the browser is not like an application, but like an OS. i.e. what it
really needs to do is to take in and run foreign code (including low level
code) safely and coordinate outputs to the screen (Google is just starting to
realize this with NaCl after much prodding and beating.)

I think everyone can see the implications of these two perspectives and what
they enable or block

Some of the implications, anyway. The benefits of the OS-perspective are
clear. Once it hits its stride, there will be no (technical) barriers to
deploying the sorts of systems that we talk about here
(Croquet-Worlds-Frank-OMeta-whatnot). Others will be doing their own cool
things, and there will be much creativity and innovation.

However, elsewhere in this thread it is noted that the HTML-web is
structured-enough to be indexable, mashupable, and so forth. It makes me
wonder: is there a risk that the searchability, etc. of the web will be
degraded by the appearance of a number of mutually-incompatible
better-than-HTML web technologies? Probably not... in the worst case, someone
who wants to be searchable can also publish in the legacy format.

However, can we do better than that? I guess the answer depends on which
aspect of the status quo we're trying to improve on (searchability, mashups,
etc). For search, there must be plenty of technologies that can improve on
HTML by decoupling search-metadata from presentation/interaction (such as
OpenSearch, mentioned elsewhere in this thread). Mashups seem harder... maybe
it needs to happen organically as some of the newly-possible systems find
themselves converging in some areas.

But I'm not writing because I know the answers, but rather the opposite. What
do you think?

Cheers,
Josh

Cheers,

Alan

From: Cornelius Toole cornelius.to...@gmail.com
To: Fundamentals of New Computing fonc@vpri.org
Sent: Tue, May 31, 2011 7:16:20 AM
Subject: Re: [fonc] Alternative Web programming models?

Thanks Merik,

I've read/watch the OOPSLA'97 keynote before, but hadn't seen the first
video.
I'm having problems with the first one(the talk at UIUC). Has anyone been
able to watch past the first hour. I get up to the point where Alex speaks
and it freezes.

I've just recently read Roy Fielding's dissertation on the architecture of
the Web. Two prominent features of web architecture are the (1) client-server
hierarchical style and (2) the layering abstraction style. My take away from
that is how all of abstraction layers of the web software stack get in the
way of the applications that want to use the machine. Style 1 is counter to
the notion of the 'no centers' principle and is very limiting when you
consider different classes of applications that might involve many entities
with ill-defined relationships. Style 2, provides for separation of concerns
and supports integration with legacy systems, but incurs so much overhead in
terms of structural complexity and performance. I think the stuff about web
sockets and what was discussed in the Erlang interview that Micheal linked to
in the 1st reply is relevant here. The web was designed for large grain
interaction between entities, but many application domain problems don't map
to that. Some people just want pipes or channels to exchange messages for
fine-grained interactions, but the layer cake doesn't allow it. This is where
you get the feeling that the architecture for rich web apps is
no-architecture, just piling big stones atop one another.

I think it would be very interesting for someone to take the same approach to
networked-based application as Gezira did with graphics (or the STEP project
in general) as far assessing what's needed in a modern Internet-scale
hypermedia architecture.

On Thu, May 26, 2011 at 4:53 PM, Merik Voswinkel a...@knoware.nl wrote:
Dr Alan Kay addressed the html design a number of times in his lectures and
keynotes. Here are two:

[1] Alan Kay, How Complex is Personal Computing?. Normal Considered
Harmful. October 22, 2009, Computer Science department at UIUC.
http://media.cs.uiuc.edu/seminars/StateFarm-Kay-2009-10-22b.asx
(also see http://www.smalltalk.org.br/movies/ )

[2] Alan Kay, The Computer Revolution Hasn't Happened Yet, October 7, 1997,
OOPSLA'97 Keynote.
Transcript
http://blog.moryton.net/2007/12/computer-revolution-hasnt-happened-yet.html
Video
http://ftp.squeak.org/Media/AlanKay/Alan%20Kay%20at%20OOPSLA%201997%20-%20The%20computer%20revolution%20hasnt%20happened%20yet.avi

(also see http://www.smalltalk.org.br/movies/ )

Merik

On May 26, 2011, at 8:38 PM, Cornelius Toole wrote:

All,
A criticism by Dr. Kay, has really stuck with me. I

Re: [fonc] Alternative Web programming models?

2011-06-09 Thread BGB


On 6/9/2011 12:56 AM, Josh Gargus wrote:


On May 31, 2011, at 7:30 AM, Alan Kay wrote:


Hi Cornelius

There are lots of egregiously wrong things in the web design. Perhaps 
one of the simplest is that the browser folks have lacked the 
perspective to see that the browser is not like an application, but 
like an OS. i.e. what it really needs to do is to take in and run 
foreign code (including low level code) safely and coordinate outputs 
to the screen (Google is just starting to realize this with NaCl 
after much prodding and beating.)


I think everyone can see the implications of these two perspectives 
and what they enable or block


Some of the implications, anyway.  The benefits of the OS-perspective 
are clear.  Once it hits its stride, there will be no (technical) 
barriers to deploying the sorts of systems that we talk about here 
(Croquet-Worlds-Frank-OMeta-whatnot).  Others will be doing their own 
cool things, and there will be much creativity and innovation.


However, elsewhere in this thread it is noted that the HTML-web is 
structured-enough to be indexable, mashupable, and so forth.  It makes 
me wonder: is there a risk that the searchability, etc. of the web 
will be degraded by the appearance of a number of 
mutually-incompatible better-than-HTML web technologies?  Probably 
not... in the worst case, someone who wants to be searchable can also 
publish in the legacy format.


However, can we do better than that?   I guess the answer depends on 
which aspect of the status quo we're trying to improve on 
(searchability, mashups, etc).  For search, there must be plenty of 
technologies that can improve on HTML by decoupling search-metadata 
from presentation/interaction (such as OpenSearch, mentioned elsewhere 
in this thread).  Mashups seem harder... maybe it needs to happen 
organically as some of the newly-possible systems find themselves 
converging in some areas.


But I'm not writing because I know the answers, but rather the 
opposite.  What do you think?




hmm... it is a mystery

actually, possibly a relevant question here, would be why Java applets 
largely fell on their face, but Flash largely took off (in all its uses 
from YouTube to Punch The Monkey...).


but, yeah, there is another downside to deploying ones' technology in a 
browser:

writing browser plug-ins...


and, for browser-as-OS, what exactly will this mean, technically?...
network-based filesystem and client-side binaries and virtual processes?...
like, say, if one runs a tiny sand-boxed Unix-like system inside the 
browser, then push or pull binary files, which are executed, and may 
perform tasks?...


could be interesting though, as then a tab can be either an open page 
or document, or a running application. hopefully, these could be nicer 
to target, and more capable, than either Flash or Java Applets, although 
probably would require some sort of VM.


NaCl is not a perfect solution, if anything, because, say, x86 NaCl 
apps don't work on x86-64 or ARM. nicer would be able to be able to run 
it natively, if possible, or JIT it to the native ISA if not.


I did my own x86-based VM before, which basically just ran x86 in an 
interpreted (via translation to threaded code) environment. technically, 
I just sort of did a basic POSIX-like architecture, albeit I used 
PE/COFF for binaries and libraries (compiled via MinGW...).
it was written in such a way that likely it wont care what the host 
architecture is (it was all plain C, with no real ASM or 
architecture-specific hacks...).


so, I guess, if something like this existed inside a browser, and was 
isolated from the host OS?...


in my case, I wrote the VM and soon realized I personally had no 
particular use for it...



and, meanwhile, for my own site, it is generally plain HTML...
I did basic CGI-scripts before as a test, but couldn't think up much to 
use them for (I don't personally really do much of anything that really 
needs CGI-scripts).


about the most I would likely do with it would be to perform simple 
surveys, say, a form that is like:

favorite programming language?, MBTI type?, ...
then I could analyze the results to conclude which types of personality 
are more associated with being a programmer, and which prefer which 
sorts of programming languages, ...


for example... how common are other xSTP (ISTP or ESTP) programmers, and 
how many like C?...



in general though, I use HTML for much of my documentation, but 
generally because it is currently one of the least-effort ways to 
provide structured and formatted documentation and have it be readily 
accessible (online or offline).


at least, currently I use SeaMonkey Composer, which is not that much 
more effort than using a word-processor, and IMO a little less silly in 
terms of how it behaves (vs Word or OpenOffice Writer which seem at 
times brain-damaged...). not that Composer is perfect either though.


for editing documentation, a WYSIWYG editor works fine, since ones'

Re: [fonc] Alternative Web programming models?

2011-06-09 Thread Julian Leviston


On 09/06/2011, at 5:56 PM, Josh Gargus wrote:

 However, can we do better than that?   I guess the answer depends on which 
 aspect of the status quo we're trying to improve on (searchability, mashups, 
 etc).  For search, there must be plenty of technologies that can improve on 
 HTML by decoupling search-metadata from presentation/interaction (such as 
 OpenSearch, mentioned elsewhere in this thread).  Mashups seem harder... 
 maybe it needs to happen organically as some of the newly-possible systems 
 find themselves converging in some areas.
 
 But I'm not writing because I know the answers, but rather the opposite.  
 What do you think?
 


I'm left wondering about the Adapter design pattern... could it be adapted to 
apply here? Can we take OMeta, which is basically the adapter pattern to end 
all adapter patterns and apply it to the web, and end up with two 
inter-communicable network protocols?

Julian.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-09 Thread Julian Leviston


On 09/06/2011, at 7:04 PM, BGB wrote:

 actually, possibly a relevant question here, would be why Java applets 
 largely fell on their face, but Flash largely took off (in all its uses from 
 YouTube to Punch The Monkey...).

My own opinion of this is the same reason that the iPad feels faster than a 
modern desktop operating system: it was quicker to get to the user interaction 
point.

Julian.


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-09 Thread Cornelius Toole

it hits its stride, there will be no (technical) barriers to
deploying the sorts of systems that we talk about here
(Croquet-Worlds-Frank-OMeta-whatnot). Others will be doing their own cool
things, and there will be much creativity and innovation.

However, elsewhere in this thread it is noted that the HTML-web is
structured-enough to be indexable, mashupable, and so forth. It makes me
wonder: is there a risk that the searchability, etc. of the web will be
degraded by the appearance of a number of mutually-incompatible
better-than-HTML web technologies? Probably not... in the worst case,
someone who wants to be searchable can also publish in the legacy format.

However, can we do better than that? I guess the answer depends on which
aspect of the status quo we're trying to improve on (searchability, mashups,
etc). For search, there must be plenty of technologies that can improve on
HTML by decoupling search-metadata from presentation/interaction (such as
OpenSearch, mentioned elsewhere in this thread). Mashups seem harder...
maybe it needs to happen organically as some of the newly-possible systems
find themselves converging in some areas.

But I'm not writing because I know the answers, but rather the opposite.
What do you think?

Cheers,
Josh

Cheers,

Alan

--
*From:* Cornelius Toole cornelius.to...@gmail.com
*To:* Fundamentals of New Computing fonc@vpri.org
*Sent:* Tue, May 31, 2011 7:16:20 AM
*Subject:* Re: [fonc] Alternative Web programming models?

Thanks Merik,

I've just recently read Roy Fielding's dissertation on the architecture of
the Web. Two prominent features of web architecture are the (1)
client-server hierarchical style and (2) the layering abstraction style. My
take away from that is how all of abstraction layers of the web software
stack get in the way of the applications that want to use the machine. Style
1 is counter to the notion of the 'no centers' principle and is very
limiting when you consider different classes of applications that might
involve many entities with ill-defined relationships. Style 2, provides for
separation of concerns and supports integration with legacy systems, but
incurs so much overhead in terms of structural complexity and performance. I
think the stuff about web sockets and what was discussed in the Erlang
interview that Micheal linked to in the 1st reply is relevant here. The web
was designed for large grain interaction between entities, but many
application domain problems don't map to that. Some people just want pipes
or channels to exchange messages for fine-grained interactions, but the
layer cake doesn't allow it. This is where you get the feeling that the
architecture for rich web apps is no-architecture, just piling big stones
atop one another.

I think it would be very interesting for someone to take the same approach
to networked-based application as Gezira did with graphics (or the STEP
project in general) as far assessing what's needed in a modern
Internet-scale hypermedia architecture.

On Thu, May 26, 2011 at 4:53 PM, Merik Voswinkel a...@knoware.nl wrote:

Dr Alan Kay addressed the html design a number of times in his lectures
and keynotes. Here are two:

[2] Alan Kay, The Computer Revolution Hasn't Happened Yet, October 7,
1997, OOPSLA'97 Keynote.
Transcript
http://blog.moryton.net/2007/12/computer-revolution-hasnt-happened-yet.html

Video
http://ftp.squeak.org/Media/AlanKay/Alan%20Kay%20at%20OOPSLA%201997%20-%20The%20computer%20revolution%20hasnt%20happened%20yet.avi

(also see http://www.smalltalk.org.br/movies/ )

Merik

On May 26, 2011, at 8:38 PM, Cornelius Toole wrote:

All,
A criticism by Dr. Kay, has really stuck with me. I can't remember the
specific criticism and where it's from, but I recall it being about the how
wrong the web programming model is. I imagine he was referring to how
disjointed, resource inefficient it is and how it only exposes a fraction of
the power and capability inherent in the average personal computer.

So Alan, anyone else,
what's wrong with the web programming mode and application architecture?
What programming model would work for a global-scale hypermedia system? What
prior research or commercial systems have any of these properties?

The web is about the closest we've seen to a ubiquitous deployment
platform for software, but the confluence of market forces and technical

Re: [fonc] Alternative Web programming models?


On Jun 9, 2011, at 2:04 AM, BGB wrote:

 On 6/9/2011 12:56 AM, Josh Gargus wrote:
 
 
 On May 31, 2011, at 7:30 AM, Alan Kay wrote:
 
 Hi Cornelius
 
 There are lots of egregiously wrong things in the web design. Perhaps one 
 of the simplest is that the browser folks have lacked the perspective to 
 see that the browser is not like an application, but like an OS. i.e. what 
 it really needs to do is to take in and run foreign code (including low 
 level code) safely and coordinate outputs to the screen (Google is just 
 starting to realize this with NaCl after much prodding and beating.)
 
 I think everyone can see the implications of these two perspectives and 
 what they enable or block
 
 Some of the implications, anyway.  The benefits of the OS-perspective are 
 clear.  Once it hits its stride, there will be no (technical) barriers to 
 deploying the sorts of systems that we talk about here 
 (Croquet-Worlds-Frank-OMeta-whatnot).  Others will be doing their own cool 
 things, and there will be much creativity and innovation.
 
 However, elsewhere in this thread it is noted that the HTML-web is 
 structured-enough to be indexable, mashupable, and so forth.  It makes me 
 wonder: is there a risk that the searchability, etc. of the web will be 
 degraded by the appearance of a number of mutually-incompatible 
 better-than-HTML web technologies?  Probably not... in the worst case, 
 someone who wants to be searchable can also publish in the legacy format.
 
 However, can we do better than that?   I guess the answer depends on which 
 aspect of the status quo we're trying to improve on (searchability, mashups, 
 etc).  For search, there must be plenty of technologies that can improve on 
 HTML by decoupling search-metadata from presentation/interaction (such as 
 OpenSearch, mentioned elsewhere in this thread).  Mashups seem harder... 
 maybe it needs to happen organically as some of the newly-possible systems 
 find themselves converging in some areas.
 
 But I'm not writing because I know the answers, but rather the opposite.  
 What do you think?
 
 
 hmm... it is a mystery
 
 actually, possibly a relevant question here, would be why Java applets 
 largely fell on their face, but Flash largely took off (in all its uses from 
 YouTube to Punch The Monkey...).
 
 but, yeah, there is another downside to deploying ones' technology in a 
 browser:
 writing browser plug-ins...
 
 
 and, for browser-as-OS, what exactly will this mean, technically?...
 network-based filesystem and client-side binaries and virtual processes?...
 like, say, if one runs a tiny sand-boxed Unix-like system inside the browser, 
 then push or pull binary files, which are executed, and may perform tasks?...


This isn't quite what I had in mind.  Perhaps hypervisor is better than OS 
to describe what I'm talking about, and I believe Alan too: a thin-as-possible 
platform that provides access to computing resources such as end-user I/O 
(mouse, multitouch, speakers, display, webcam, etc.), CPU/GPU, local persistant 
storage, and network.  Just enough to enable others to run OSes on top of this 
hypervisor.  

If it tickles you fancy, then by all means use it to run a sand-boxed Unix.  
Undoubtedly someone will; witness the cool hack to run Linux in the browser, 
accomplished by writing an x86 emulator in Javascript 
(http://bellard.org/jslinux/).

However, such a hypervisor will also host more ambitious OSes, for example, 
platforms for persistent capability-secure peer-to-peer real-time collaborative 
end-use-scriptable augmented-reality environments.  (again, trying to use 
word-associations to roughly sketch what I'm referring to, as I did earlier 
with Croquet-Worlds-Frank-OMeta-whatnot).

Does this make my original question clearer?

Cheers,
Josh




___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?

2011-06-09 Thread Toby Watson

How about _recursive_ VM/JITs *beneath* the level that HTML/JS is implemented.

So the browser that ships only supports this recursive VM.

HTML is an application of this that can be evolved by open source at
internet scale / time. Web pages can point at a specific HTML
implementation or a general redirector like google apis to get the
commonly agreed standard version.

Other containers/'plugins', Squeak, Flash, Java run as VMs, can run
their native bytecode/images but also, potentially, expose the VM
interface up again. Nesting VMs is useful also. Though you won't spare
the use-case any love, Flash video players often load multiple ads
SDKs, an arrangement that could benefit from isolation, i.e.
browser-more-like-OS.

If the top and bottom VM interfaces are the same then we can stack
them (as well as nesting them).

Base VM would have exokernel / NaCL like exposure of the native
capabilities of the device. Exokernel  FluxOS have some nifty tricks
to punch through layers so performance is not so impacted by stacking.

An intermediate VM layer could provide ISA / hardware abstraction so
that everything above that looks the same.

I re-read history of Smalltalk recently and was reminded of this from Alan,

'Bob Barton, the main designer of the B5000 and a professor at Utah
had said in one of his talks a few days earlier: The basic principal
of recursive design is to make the parts have the same power as the
whole. For the first time I thought of the whole as the entire
computer and wondered why anyone would want to divide it up into
weaker things called data structures and procedures. Why not divide it
up into little computers, as time sharing was starting to? But not in
dozens. Why not thousands of them, each simulating a useful
structure?'

Toby

On 9 June 2011 10:25, Josh Gargus j...@schwa.ca wrote:

 On Jun 9, 2011, at 2:04 AM, BGB wrote:

 On 6/9/2011 12:56 AM, Josh Gargus wrote:


 On May 31, 2011, at 7:30 AM, Alan Kay wrote:

 Hi Cornelius

 There are lots of egregiously wrong things in the web design. Perhaps one 
 of the simplest is that the browser folks have lacked the perspective to 
 see that the browser is not like an application, but like an OS. i.e. what 
 it really needs to do is to take in and run foreign code (including low 
 level code) safely and coordinate outputs to the screen (Google is just 
 starting to realize this with NaCl after much prodding and beating.)

 I think everyone can see the implications of these two perspectives and 
 what they enable or block

 Some of the implications, anyway.  The benefits of the OS-perspective are 
 clear.  Once it hits its stride, there will be no (technical) barriers to 
 deploying the sorts of systems that we talk about here 
 (Croquet-Worlds-Frank-OMeta-whatnot).  Others will be doing their own cool 
 things, and there will be much creativity and innovation.

 However, elsewhere in this thread it is noted that the HTML-web is 
 structured-enough to be indexable, mashupable, and so forth.  It makes me 
 wonder: is there a risk that the searchability, etc. of the web will be 
 degraded by the appearance of a number of mutually-incompatible 
 better-than-HTML web technologies?  Probably not... in the worst case, 
 someone who wants to be searchable can also publish in the legacy format.

 However, can we do better than that?   I guess the answer depends on which 
 aspect of the status quo we're trying to improve on (searchability, 
 mashups, etc).  For search, there must be plenty of technologies that can 
 improve on HTML by decoupling search-metadata from presentation/interaction 
 (such as OpenSearch, mentioned elsewhere in this thread).  Mashups seem 
 harder... maybe it needs to happen organically as some of the 
 newly-possible systems find themselves converging in some areas.

 But I'm not writing because I know the answers, but rather the opposite.  
 What do you think?


 hmm... it is a mystery

 actually, possibly a relevant question here, would be why Java applets 
 largely fell on their face, but Flash largely took off (in all its uses from 
 YouTube to Punch The Monkey...).

 but, yeah, there is another downside to deploying ones' technology in a 
 browser:
 writing browser plug-ins...


 and, for browser-as-OS, what exactly will this mean, technically?...
 network-based filesystem and client-side binaries and virtual processes?...
 like, say, if one runs a tiny sand-boxed Unix-like system inside the 
 browser, then push or pull binary files, which are executed, and may perform 
 tasks?...


 This isn't quite what I had in mind.  Perhaps hypervisor is better than 
 OS to describe what I'm talking about, and I believe Alan too: a 
 thin-as-possible platform that provides access to computing resources such as 
 end-user I/O (mouse, multitouch, speakers, display, webcam, etc.), CPU/GPU, 
 local persistant storage, and network.  Just enough to enable others to run 
 OSes on top of this hypervisor.

 If it tickles you fancy, then by

Re: [fonc] Alternative Web programming models?

. Perhaps a theme of the developments around HTML5 is evolving the 
 Web architecture to better support connecting applications. But because the 
 Web was designed for exchanging representations of application state 
 (basically large-grained data), so many applications won't fit this model. 
 Imagine trying to run a high-frequency equity trading network atop the FedEx 
 air freight network, or worse the US Postal Service (or chose your local 
 postal service). Add to the fact of a client-server hierarchy and now you 
 have to deal with bottlenecks at those endpoints. Many web-based applications 
 are designed around this bottleneck, and so I see us running into conceptual 
 and structural scaling issues.

Agreed.  It appears that I was re-asking a variant of your original question.

Cheers,
Josh



 
 
 
 
 
  
 
 On Thu, Jun 9, 2011 at 2:56 AM, Josh Gargus j...@schwa.ca wrote:
 
 On May 31, 2011, at 7:30 AM, Alan Kay wrote:
 
 Hi Cornelius
 
 There are lots of egregiously wrong things in the web design. Perhaps one of 
 the simplest is that the browser folks have lacked the perspective to see 
 that the browser is not like an application, but like an OS. i.e. what it 
 really needs to do is to take in and run foreign code (including low level 
 code) safely and coordinate outputs to the screen (Google is just starting 
 to realize this with NaCl after much prodding and beating.)
 
 I think everyone can see the implications of these two perspectives and what 
 they enable or block
 
 Some of the implications, anyway.  The benefits of the OS-perspective are 
 clear.  Once it hits its stride, there will be no (technical) barriers to 
 deploying the sorts of systems that we talk about here 
 (Croquet-Worlds-Frank-OMeta-whatnot).  Others will be doing their own cool 
 things, and there will be much creativity and innovation.
 
 However, elsewhere in this thread it is noted that the HTML-web is 
 structured-enough to be indexable, mashupable, and so forth.  It makes me 
 wonder: is there a risk that the searchability, etc. of the web will be 
 degraded by the appearance of a number of mutually-incompatible 
 better-than-HTML web technologies?  Probably not... in the worst case, 
 someone who wants to be searchable can also publish in the legacy format.
 
 However, can we do better than that?   I guess the answer depends on which 
 aspect of the status quo we're trying to improve on (searchability, mashups, 
 etc).  For search, there must be plenty of technologies that can improve on 
 HTML by decoupling search-metadata from presentation/interaction (such as 
 OpenSearch, mentioned elsewhere in this thread).  Mashups seem harder... 
 maybe it needs to happen organically as some of the newly-possible systems 
 find themselves converging in some areas.
 
 But I'm not writing because I know the answers, but rather the opposite.  
 What do you think?
 
 Cheers,
 Josh
 
 
 
 
 
 
 Cheers,
 
 Alan
 
 From: Cornelius Toole cornelius.to...@gmail.com
 To: Fundamentals of New Computing fonc@vpri.org
 Sent: Tue, May 31, 2011 7:16:20 AM
 Subject: Re: [fonc] Alternative Web programming models?
 
 Thanks Merik,
 
 I've read/watch the OOPSLA'97 keynote before, but hadn't seen the first 
 video. 
 I'm having problems with the first one(the talk at UIUC). Has anyone been 
 able to watch past the first hour. I get up to the point where Alex speaks 
 and it freezes.
 
 I've just recently read Roy Fielding's dissertation on the architecture of 
 the Web. Two prominent features of web architecture are the (1) 
 client-server hierarchical style and (2) the layering abstraction style. My 
 take away from that is how all of abstraction layers of the web software 
 stack get in the way of the applications that want to use the machine. Style 
 1 is counter to the notion of the 'no centers' principle and is very 
 limiting when you consider different classes of applications that might 
 involve many entities with ill-defined relationships. Style 2, provides for 
 separation of concerns and supports integration with legacy systems, but 
 incurs so much overhead in terms of structural complexity and performance. I 
 think the stuff about web sockets and what was discussed in the Erlang 
 interview that Micheal linked to in the 1st reply is relevant here. The web 
 was designed for large grain interaction between entities, but many 
 application domain problems don't map to that. Some people just want pipes 
 or channels to exchange messages for fine-grained interactions, but the 
 layer cake doesn't allow it. This is where you get the feeling that the 
 architecture for rich web apps is no-architecture, just piling big stones 
 atop one another.
 
 I think it would be very interesting for someone to take the same approach 
 to networked-based application as Gezira did with graphics (or the STEP 
 project in general) as far assessing what's needed in a modern 
 Internet-scale hypermedia architecture. 
 
 
 
 On Thu, May 26, 2011 at 4:53 PM

Re: [fonc] Alternative Web programming models?

That all sounds very cool.

However, I don't think that it's feasible to try to ship something like this as 
standard in all browsers, if only for political reasons.  It would be 
impossible to get Mozilla, Google, Apple, and Microsoft to agree on it.

That's what's cool about NaCl.  It's minimal enough to be a feasible candidate 
for universal adoption.  If it's adopted, then an ecosystem springs up with 
people inventing recursive exokernels to run in the browser.  

Cheers,
Josh



On Jun 9, 2011, at 10:56 AM, Toby Watson wrote:

 How about _recursive_ VM/JITs *beneath* the level that HTML/JS is implemented.
 
 So the browser that ships only supports this recursive VM.
 
 HTML is an application of this that can be evolved by open source at
 internet scale / time. Web pages can point at a specific HTML
 implementation or a general redirector like google apis to get the
 commonly agreed standard version.
 
 Other containers/'plugins', Squeak, Flash, Java run as VMs, can run
 their native bytecode/images but also, potentially, expose the VM
 interface up again. Nesting VMs is useful also. Though you won't spare
 the use-case any love, Flash video players often load multiple ads
 SDKs, an arrangement that could benefit from isolation, i.e.
 browser-more-like-OS.
 
 If the top and bottom VM interfaces are the same then we can stack
 them (as well as nesting them).
 
 Base VM would have exokernel / NaCL like exposure of the native
 capabilities of the device. Exokernel  FluxOS have some nifty tricks
 to punch through layers so performance is not so impacted by stacking.
 
 An intermediate VM layer could provide ISA / hardware abstraction so
 that everything above that looks the same.
 
 I re-read history of Smalltalk recently and was reminded of this from Alan,
 
 'Bob Barton, the main designer of the B5000 and a professor at Utah
 had said in one of his talks a few days earlier: The basic principal
 of recursive design is to make the parts have the same power as the
 whole. For the first time I thought of the whole as the entire
 computer and wondered why anyone would want to divide it up into
 weaker things called data structures and procedures. Why not divide it
 up into little computers, as time sharing was starting to? But not in
 dozens. Why not thousands of them, each simulating a useful
 structure?'
 
 Toby
 
 On 9 June 2011 10:25, Josh Gargus j...@schwa.ca wrote:
 
 On Jun 9, 2011, at 2:04 AM, BGB wrote:
 
 On 6/9/2011 12:56 AM, Josh Gargus wrote:
 
 
 On May 31, 2011, at 7:30 AM, Alan Kay wrote:
 
 Hi Cornelius
 
 There are lots of egregiously wrong things in the web design. Perhaps one 
 of the simplest is that the browser folks have lacked the perspective to 
 see that the browser is not like an application, but like an OS. i.e. 
 what it really needs to do is to take in and run foreign code (including 
 low level code) safely and coordinate outputs to the screen (Google is 
 just starting to realize this with NaCl after much prodding and beating.)
 
 I think everyone can see the implications of these two perspectives and 
 what they enable or block
 
 Some of the implications, anyway.  The benefits of the OS-perspective are 
 clear.  Once it hits its stride, there will be no (technical) barriers to 
 deploying the sorts of systems that we talk about here 
 (Croquet-Worlds-Frank-OMeta-whatnot).  Others will be doing their own cool 
 things, and there will be much creativity and innovation.
 
 However, elsewhere in this thread it is noted that the HTML-web is 
 structured-enough to be indexable, mashupable, and so forth.  It makes me 
 wonder: is there a risk that the searchability, etc. of the web will be 
 degraded by the appearance of a number of mutually-incompatible 
 better-than-HTML web technologies?  Probably not... in the worst case, 
 someone who wants to be searchable can also publish in the legacy format.
 
 However, can we do better than that?   I guess the answer depends on which 
 aspect of the status quo we're trying to improve on (searchability, 
 mashups, etc).  For search, there must be plenty of technologies that can 
 improve on HTML by decoupling search-metadata from 
 presentation/interaction (such as OpenSearch, mentioned elsewhere in this 
 thread).  Mashups seem harder... maybe it needs to happen organically as 
 some of the newly-possible systems find themselves converging in some 
 areas.
 
 But I'm not writing because I know the answers, but rather the opposite.  
 What do you think?
 
 
 hmm... it is a mystery
 
 actually, possibly a relevant question here, would be why Java applets 
 largely fell on their face, but Flash largely took off (in all its uses 
 from YouTube to Punch The Monkey...).
 
 but, yeah, there is another downside to deploying ones' technology in a 
 browser:
 writing browser plug-ins...
 
 
 and, for browser-as-OS, what exactly will this mean, technically?...
 network-based filesystem and client-side binaries and virtual processes?...
 like,

Re: [fonc] Alternative Web programming models?


On Jun 9, 2011, at 11:42 AM, BGB wrote:
  OSes on top of this hypervisor.
 
 If it tickles you fancy, then by all means use it to run a sand-boxed Unix.  
 Undoubtedly someone will; witness the cool hack to run Linux in the browser, 
 accomplished by writing an x86 emulator in Javascript 
 (http://bellard.org/jslinux/).
 
 
 interesting...
 less painfully slow than I would have expected from the description...
 
 I wasn't thinking exactly like run an emulator, run OS in emulator, but 
 more like, a browser plugin which looked and acted similar to a small Unix 
 (with processes and so on, and a POSIX-like API, and a filesystem), but would 
 likely be different in that it would mount content from the website as part 
 of its local filesystem (probably read-only by default), and possibly each 
 process could have its own local VFS.
 

I know.  I was just saying that if someone has written a Javascript x86 
emulator to run Linux in the browser, that it's a near-certainty that someone 
will eventually use NaCl to host a POSIX-like environment in the browser.

Cheers,
Josh___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?