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


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

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



(I got sidetracked and forgot to answer earlier...).


but, well, I consider them as different, as they serve different roles...

filesystems serve a very narrowly defined role, so possible variation is 
limited before one risks compromising compatibility with existing 
software (both WRT removing features, or adding too many fundamentally 
new ones). compromising this compatibility would also severely 
compromise the general usability of the system.



however, one could argue that filesystems are probably a fairly narrowly 
defined subset of databases, so in this sense there is overlap.


for example, humans are mammals, but not all mammals are humans (tigers 
aren't hosting TV shows, there are no cities of bears, elephants aren't 
doing construction work, ...).


so, it seems a similar level of difference...



___
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

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?)

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 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 6/20/2011 1:00 AM, Steve Dekorte wrote:

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.


yeah...

meanwhile, making flowcharts is slow and tedious, but people never let 
them go away it seems...


decided to leave out a big chunk of me being solidly unimpressed by the 
courses I have seen thus far in my pursuit of a CS degree...


is it more sad that the courses are lame?... or that so many of the 
students struggle?...



for 3D stuff, I generally do any 3D modeling/animating related parts in 
3D tools;
however, "assembling" the model (putting together the base-model, 
skeleton, and animation sequences) is generally done by editing text 
files at present.


also, most other tasks, like setting up the models and character 
behaviors in-game, ... are all basically done by writing out code (good 
old text-editor once again).


most in-program controls are either:
direct-action (click/drag with mouse, use arrow keys, ...);
keyboard-shortcuts (most generic commands: setting active tool, 
performing various actions, gets a bit Emacs-like as 3 or 4 key 
shortcuts are more common than ideal, like CTRL+SHIFT+whatever, ...);

context menu (mostly for if one forgets the keyboard shortcut...);
some special-purpose forms (load/save, select texture/shader, ...);
console (mostly just for esoteric stuff at present, more used with 3D 
engine).



as-is, since my 3D game engine is mostly an outgrowth of my mapper, and 
due to technical reasons, its present initial start-up settings are very 
un-FPS like, so startup is a ritual like:

load up program;
enter console, type in "map whatever" to load up a map;
wait for it to load (slow... mostly apparently due to texture loading);
exit console;
enter a long string of keyboard shortcuts to basically switch to an 
FPS-like control scheme and set up renderer settings and similar (sort 
of like a magical incantation of sorts on the keyboard, which itself 
partly sets up the mouse and keyboard, puts the camera under the control 
of the game physics and disables "noclip", turns on lighting, ...).


after this point, it looks and behaves much more like an FPS...


later, I may add something similar to the "autoexec.cfg" in the Quake 
series, or maybe load and execute a BGBScript program 
"scripts/engine/e_init.bs" or similar, or some combination thereof...



but, yeah, lots and lots of text...


no high-level / abstract GUI anywhere...
well, unless one considers keyboard-shortcuts to be an abstraction...

well, it is abstract in that I don't clutter the screen with GUI 
elements or buttons or toolbars or similar, and reverse-clicking is 
needed to summon the menu. rest is shortcuts...


summoning the console is also a keyboard shortcut (CTRL+~).

...


___
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 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?

___
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?)

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: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?)

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?)

2011-06-19 Thread Julian Leviston

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?)

2011-06-19 Thread BGB

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,

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

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 le

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: 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  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: 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 7:43 PM, Steve Wart wrote:

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

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/

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.

> 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 :-)

I understand about the magic tricks. My son wanted me to help him get 
Raphael.js to mask images with arbitrary paths tonight. Fortunately, there was 
an undocumented technique (Google saves the day!).

Besides, my eyes glaze over at C code too ;-)

--Dethe
___
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

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  wrote:
> On 2011-06-15, at 3:42 PM, Dale Schumacher wrote:
>
>> On Wed, Jun 15, 2011 at 8:30 AM, Dethe Elza  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: 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  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 Dale Schumacher

On Wed, Jun 15, 2011 at 8:30 AM, Dethe Elza  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.

___
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 BGB


On 6/15/2011 6:30 AM, Dethe Elza wrote:

On 2011-06-15, at 3:22 AM, BGB wrote:


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

Nothing wrong with that, we learn to write better, tighter code and get rid of 
the old cruft. Some of the best code I've seen has been written with the delete 
key...



a lot of it in my case seems to be factoring things out.

say, one replaces a big glob of code with a function call (the function 
then does the same task). then the big glob of code becomes an "#if 0 
... #endif" block (this has happened a lot in my script VM recently, 
there are a large number of these blocks).


then generally, sometime later, this "#if 0" block ends up being removed 
(once the code is confirmed no-longer-useful).
it seems that recently this factor has been outweighing the addition of 
new code.


in some other cases, some partially redundant systems (doing nearly the 
same thing in slightly different ways, or via a different interface) 
have been effectively merged, ...



the partial result (after removing 150 kloc of GPL code, dropping 
project size to around 1.05Mloc or so) was then my project going from 
around 1.05Mloc down to about 750 kloc (in approx 6 months).


so, a shrinkage of around 300 kloc in 6 months or so...

granted, there is some room for error here (I have better things to do 
than accurately catalog then when and where of the removal of code, or 
to keep a running log of the total project kloc at various moments in 
time). I just occasionally re-run line counters, and see what I see.




a mystery though is how generally "off putting" the school experience can be to 
people...
I generally remember these years of my life to be just plain dismal (I really 
don't know how people can find much enjoyment in all this...).

Don't get me started on how bad school can be for turning kids off from 
learning. No mystery to it, helping kids learn just really isn't part of what 
schools were designed for, despite using that as a story to sell them to the 
public.


fair enough...

for those of us without much of a social life, and not personally all 
that motivated by grades, ..., there is really not a lot to find 
enjoyable in all this.




One more point that is more on topic: Using the Scratch block-based visual 
programming, I saw that an eight year old was able to download, read, 
understand, and modify successfully (i.e., make the changes he 
desired/anticipated) pretty much any code he found on the Scratch site. Not too 
many languages I can say that for, even with adults. Not all of that can be 
attributed to the visual nature -- Scratch is also very tightly constrained and 
the limits can aid understanding too, as well as picking the right abstractions 
to represent with blocks, but it was impressive and I think the fact that the 
blocks show visually the structure and behaviour (sets of blocks tied to a 
specific sprite, blocks highlight as they are run) of the program does help 
considerably in being able to read, understand, and maintain someone else's 
code.

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.



fair enough, I will leave the above here, but don't have much time to 
look at or comment on it at the moment.



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

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:22 AM, BGB wrote:

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

Nothing wrong with that, we learn to write better, tighter code and get rid of 
the old cruft. Some of the best code I've seen has been written with the delete 
key...

> a mystery though is how generally "off putting" the school experience can be 
> to people...
> I generally remember these years of my life to be just plain dismal (I really 
> don't know how people can find much enjoyment in all this...).

Don't get me started on how bad school can be for turning kids off from 
learning. No mystery to it, helping kids learn just really isn't part of what 
schools were designed for, despite using that as a story to sell them to the 
public.

One more point that is more on topic: Using the Scratch block-based visual 
programming, I saw that an eight year old was able to download, read, 
understand, and modify successfully (i.e., make the changes he 
desired/anticipated) pretty much any code he found on the Scratch site. Not too 
many languages I can say that for, even with adults. Not all of that can be 
attributed to the visual nature -- Scratch is also very tightly constrained and 
the limits can aid understanding too, as well as picking the right abstractions 
to represent with blocks, but it was impressive and I think the fact that the 
blocks show visually the structure and behaviour (sets of blocks tied to a 
specific sprite, blocks highlight as they are run) of the program does help 
considerably in being able to read, understand, and maintain someone else's 
code.

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

___
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 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: 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 t

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: 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 Julian Leviston

On 15/06/2011, at 5:33 AM, BGB wrote:

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

Ponder this: What is the difference between using a computer and programming a 
computer?
Then this: What is playing a computer game? Is it using a computer? What if the 
parameters of the game were such that the objectives of the game were creating 
content of some kind?

... and by ponder, I mean hold the open question without trying to "arrive at" 
an answer for a while (ie don't "recover" from QUEST-ion straight away), but 
just considering it... holding your attention on it for a while... see what 
arises...

Graphics, when used properly in their own right and not moulded to the confines 
imposed by other systems,, can be an equally powerful method of interaction 
than text. Consider watching a film and reading a book... also consider what 
happened to the synthesizer when people stopped trying to make it behave like 
other instruments and allowed it to be just what it was, exactly...

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

Re: [fonc] Alternative Web programming models?

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

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

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 :
> On Tue, Jun 14, 2011 at 01:04:20PM -0700, BGB wrote:
>> On 6/14/2011 12:14 PM, Michael FIG wrote:
>> >Hi,
>> >
>> >John Nilsson  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 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 Nilsson  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]!='\\'
o<0
[process(o[1,o.size-2]),i]
end
def process(s)
o=""
i=0
while itmp2`

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

Re: [fonc] Alternative Web programming models?

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

Sent from my phone
Den 15 jun 2011 01:08 skrev "BGB" :
> 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 that applications can "extend" layers without necessarily
> needing to replace them outright.
>
>
> as noted before, in my VM:
> user-defined syntax and AST nodes are presently possible via plug-ins;
> an additional level of plug-ins could be plug-ins at the bytecode level
> (for example, handlers are added which extend the bytecoded ISA,
> although this "may" be limited to 3-byte opcodes, with 1 and 2 byte
> opcode ranges being generally reserved for the implementation).
>
> actually, the 1-byte space is pretty much full anyways, and my own
> efforts are using up the 2-byte space (but, the 2-byte space is much
> bigger than the 1-byte space).
>
> the 3-byte space allows around 768k opcodes.
>
>
> also relevant is also having a pluggable type-system, where most basic
> operations and operators can also be registered for new/custom types.
>
> currently this is possible, but has the slight drawback at the moment of
> only dealing with only exact type-matches, whereas predicate-based
> matching could be possibly more useful (as opposed to matching exact
> types, like say, "_myapp_foo_t" + "_fixint_t", one can match generic
> types, like say, "_foo_t"+dyrealp(), such that a single handler
> registration would cover all real types, or similar...).
>
> at least, it is a possible option...
>
>
> granted, yes, a plug-in system still has drawbacks, but could still be
> better than the present situation with many more mainstream languages,
> where apart from extensive work (often having to largely re-implement
> the thing, or result to nasty kludges) one has little or no
> customization ability...
>
>
> or such...
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Alternative Web programming models?


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 that applications can "extend" layers without necessarily 
needing to replace them outright.



as noted before, in my VM:
user-defined syntax and AST nodes are presently possible via plug-ins;
an additional level of plug-ins could be plug-ins at the bytecode level 
(for example, handlers are added which extend the bytecoded ISA, 
although this "may" be limited to 3-byte opcodes, with 1 and 2 byte 
opcode ranges being generally reserved for the implementation).


actually, the 1-byte space is pretty much full anyways, and my own 
efforts are using up the 2-byte space (but, the 2-byte space is much 
bigger than the 1-byte space).


the 3-byte space allows around 768k opcodes.


also relevant is also having a pluggable type-system, where most basic 
operations and operators can also be registered for new/custom types.


currently this is possible, but has the slight drawback at the moment of 
only dealing with only exact type-matches, whereas predicate-based 
matching could be possibly more useful (as opposed to matching exact 
types, like say, "_myapp_foo_t" + "_fixint_t", one can match generic 
types, like say, "_foo_t"+dyrealp(), such that a single handler 
registration would cover all real types, or similar...).


at least, it is a possible option...


granted, yes, a plug-in system still has drawbacks, but could still be 
better than the present situation with many more mainstream languages, 
where apart from extensive work (often having to largely re-implement 
the thing, or result to nasty kludges) one has little or no 
customization ability...



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

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" :
___
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 6/14/2011 12:14 PM, Michael FIG wrote:

Hi,

John Nilsson  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;
  }
}


granted, yes, this requires the ability to plug things into the parser 
and compiler, which isn't really possible with a standard Java compiler, 
but is not an inherent limitation of text IMO.


another person, elsewhere (Thomas Mertes, who endlessly flogs his 
"Seed7" language) is basically really into supporting stuff like this 
in-language (absent using compiler plug-ins).


in my case, usually a plugin would be registered with the parser and the 
compiler, where the parser plugin would detect and respond to a certain 
keyword, and the compiler plugin would respond to specific added AST 
node types.



some other things in my language is done via attributes and modifier 
blocks, but generally this is for things which don't otherwise change 
the basic syntax.


native {
... FFI related stuff ...
}

$[ifdef(FOO)] {
... conditionally compiled stuff...
}
...

yes, yes, my attribute syntax is nasty...


embedding things in comments technically works, but is IMO a nasty way 
to do extensions, in much the same way as is the "embed complex program 
logic in strings" strategy.


slightly less nasty (but still not really ideal IMO), is to use special 
purpose preprocessing, like how Objective-C and Objective-C++ work.


I can already do some of the above with C, via having a more "expanded" 
version of a C-style preprocessor, but generally don't do this sort of 
thing unless really necessary (I prefer strategies that can be done 
purely within the language, rather than those which would require more 
heavy-handed methods, when possible...).



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/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: [fonc] Alternative Web programming models?

2011-06-14 Thread Michael FIG

Hi,

John Nilsson  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  //\
   http://michael.fig.org/\//

___
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
 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 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?

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

BR,
John

Sent from my phone
Den 14 jun 2011 17:17 skrev "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?

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?

I'm not sure how OMeta would help. At a textual level it's just a
PEG-parser.

I can see how OMeta will make it easier to step away from parsing text
though. Which is precisly the point, text is a bad representation to work
in.

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

Sent from my phone
Den 14 jun 2011 16:24 skrev "Tristan Slominski" :
___
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?

On Mon, Jun 13, 2011 at 10:02 PM, 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).

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 Dale Schumacher

Perhaps I can help you avoid talking past each other.

On Mon, Jun 13, 2011 at 11:35 PM, Julian Leviston  wrote:
> 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?

The "strong typing" Scott is talking about is the equivalent of the
snap-together shapes on the tile edges.  Another equivalence is the
choice-list of options you may be presented in an IDE.  Both constrain
(or guide, in the case of code-completion) your options based on the
"type" of the interaction.  Without some kind of type information
there is no meaningful way to constrain the options, graphical or
otherwise.

Hopefully, I haven't misrepresented either of you, or added my own
confusion to the conversation.

[snip]
> 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 perspective on designing in solution-space is to visualize the
object (or actor) instances and their interactions during the
evolution of a computation.  For me, syntax follows structure.  That
is, I first think about the objects and their connections, both static
and dynamic, in a sort of general nodes-and-edges graph structure.
Then I try to map the graph into a linear textual representation.  The
result is often frustrating, since linear streams of characters make
some graph structures awkward to express.  I expect that direct
visualization of the object graph would be helpful here.  On the other
hand, I find that the behavior of the objects (actors) is easier to
grasp in a compact textual representation, even though the behavior
description has its own (fractal?) graph structure.

In any case, the graph structure carries no type information.  It is
just a reference/reachability graph, constraining potential
communication (a reference is required for interaction).  The content
(type) of the communication is not constrained.

___
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  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?

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?

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 C. Scott Ananian

On Mon, Jun 13, 2011 at 11:17 PM, Julian Leviston  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?

2011-06-13 Thread Yoshiki Ohshima

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

-- Yoshiki

___
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?

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.

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

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"  wrote:

> On Mon, Jun 13, 2011 at 4:02 PM, BGB  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?

2011-06-13 Thread C. Scott Ananian

On Mon, Jun 13, 2011 at 4:02 PM, BGB  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

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

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
 wrote:
> Comments below.
> On Jun 13, 2011, at 6:00 AM, Dale Schumacher 
> wrote:
>
> On Mon, Jun 13, 2011 at 4:50 AM, BGB  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 karl ramberg

On Mon, Jun 13, 2011 at 9:31 PM, Julian Leviston wrote:

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

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

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.

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

2011-06-13 Thread Casey Ransberger

Comments below.

On Jun 13, 2011, at 6:00 AM, Dale Schumacher  wrote:

> On Mon, Jun 13, 2011 at 4:50 AM, BGB  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"?

It seems that persistence of user experience is being naturally selected at the 
end of the day. Apple did it for iOS, and justified it by way of "users have to 
get the phone back into the pocket in a hurry sometimes." It seems to have 
worked well enough for them that they've added this to the Mac in Lion. Redmond 
has undoubtably noticed.

I've seen both arguments. At times I've wondered if it wasn't a matter of 
"learning style." I know that I'm definitely in the former camp.

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

+ 1

Another thing I'd like to see that I can do with images, but can't do with 
"dead code," is (easily) set up a server instance such that when it hits an 
unhanded exception, it saves off an image before it dies, with all of the state 
and context intact, and a source level debugger open. I want this because a 
great deal of my blackbox tester's time goes into identifying steps to 
reproduce. 

With the image, one needs to worry about repro steps a lot less, which frees 
these people up to spend their time on things like exploring systems with 
deeper probes and crossing the bridge into whitebox land, which is where I want 
them all to end up: reading the code and automating painful tasks as they test. ___
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  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?

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?

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 Alan Kay

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.

For example, take a look at Alex Warth's "Worlds" work (and paper) and see how 
that might be used to deal with larger problems of consistency and version 
control in a live system.

I also believe that we should advance things so that there are no hidden 
dependencies, and that dependencies are nailed semantically.

Time to move forward ...

Cheers,

Alan

From: K. K. Subramaniam 
To: fonc@vpri.org
Sent: Mon, June 13, 2011 8:10:53 AM
Subject: Re: [fonc] Alternative Web programming models?

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
___
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?

2011-06-13 Thread Dale Schumacher

On Mon, Jun 13, 2011 at 4:50 AM, BGB  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 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?

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

Re: [fonc] Alternative Web programming models?