Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
Still, databases and file systems are both based on concepts that predate electronic computers. When Windows and Macs came along the document metaphor became prevalent, but in practice this was always just a user friendly name for a file. The layers and layers of slightly broken metaphors never gets simpler. They interact in unpredictable and inconvenient ways that people adapt to, because people are far more adaptable than the machines we build. The rather intense focus on usability in recent years is probably the most powerful tool we have to sweep away all these partially implemented and poorly thought out concepts. User experience is even now the main driving force behind the evolution of programming environments. Even without auto-completion and fancy debuggers, there is a profound growth in the use of dynamic languages. The millions of hours of development that have gone into the tools the major computer vendors have been using to lock people into their platforms are no match. What matters for developers is quick turnaround for debugging problems and code that expresses its intention in a concise and elegant manner. This is a profound change in the past 5 years. So how can you make simple languages simple to use? Developers have been rejecting complex GUIs in favour of plain text. If Google and Apple are right, every program component isn't a file on a disk, but rather some network accessible resource. On the other hand, a cynical person would say that the cloud is just another broken metaphor to pile onto the heap, because all this stuff is going to be built on top of the concepts we are already stuck with. Virtual environments might also be a good way to keep the detritus of the past from cluttering the future, but a cynic might have some opinions about that too :-) Cheers Steve On Tue, Jun 21, 2011 at 7:30 PM, Julian Leviston jul...@leviston.net wrote: Yeah I've been using this DBMS on and off for years. I have a copy of it installed on my machine. It's INCREDIBLY fast. The interesting thing for me recently was that they've built an implementation of Ruby on top of it, and called it MagLev, and it's now possible to have persisted, fast, pure object-oriented data store in Ruby and/or Rails applications... and as we know, there's an implementation of O/Meta for Ruby... ;-) Julian. On 22/06/2011, at 4:58 AM, Steve Wart wrote: Also of interest might be GemStone/S, an ODBMS that is still heavily used in at least two large Investment Banks (JP Morgan and UBS), as well as several large shipping companies (OOCL, Coscon, and NYK). Marketing blurb here http://seaside.gemstone.com/docs/OOCL_SuccessStory.pdf Basically it's an environment that replaces the limitations of SQL with the limitations of Smalltalk. It's interesting that the debate about O/R mapping is still stuck in the same place it was in 1990. After all these years I still think it would be easier to implement relational semantics on top of this sort of environment than vice-versa, but last time I checked Oracle and Microsoft weren't taking my calls. This paper is kind of old, but it describes the implementation of a DBMS inspired by the description of Smalltalk in the famous 1981 issue of Byte magazine. http://portal.acm.org/citation.cfm?id=602300 Making smalltalk a database system To overcome limitations in the modeling power of existing database systems and provide a better tool for database application programming, Servio Logic Corporation is developing a computer system to support a set-theoretic data model in an object-oriented programming environment We recount the problems with existing models and database systems We then show how features of Smalltalk, such such as operational semantics, its type hierarchy, entity identity and the merging of programming and data language, solve many of those problems Nest we consider what Smalltalk lacks as a database system secondary storage management, a declarative semantics, concurrency, past states To address these shortcomings, we needed a formal data model We introduce the GemStone data model, and show how it helps to define path expressions, a declarative semantics and object history in the OPAL language We summarize similar approaches, and give a brief overview of the GemStone system implementation Cheers, Steve On Tue, Jun 21, 2011 at 11:38 AM, Max OrHai max.or...@gmail.com wrote: There are certainly practical differences between conventional relational databases and hierarchical filesystems, without having to get into implementation details. I'm sure at least a few people on this list are familiar with the BeOS filesystem, which acted much more like a relational DBMS than most filesystems do... over a decade later, we've now got hacked-on DBMS-like functionality in the form of (e.g.) Spotlight, but most users are stuck with the little walled-off databases presented by their media library and email application
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 6/22/2011 5:08 PM, Steve Wart wrote:
Still, databases and file systems are both based on concepts that
predate electronic computers.
When Windows and Macs came along the document metaphor became
prevalent, but in practice this was always just a user friendly name
for a file. The layers and layers of slightly broken metaphors never
gets simpler. They interact in unpredictable and inconvenient ways
that people adapt to, because people are far more adaptable than the
machines we build.
I personally consider documents+folders and files+directories to be
equivalent.
ideally, one could discard the metaphors, but if this involves the names
as well, then what does one call them?... lumps and nodes?...
it comes up as a thought that an HDB and a filesystem could be,
potentially, unified, however doing so could create a complicated
interface, as both are traditionally accessed differently (unless one
effectively eliminates the concept of opening/closing files as well).
an example of the later would be replacing, say, file
open/close/read/write, say, with a handle to the file, and treating the
file, for example, like a large byte array.
hmm, say:
var f=File.getFileAsArray(~/foo.bin);
var c;
c=f;
while(!c.eof)
{
printf(%d , *c);//print byte
printf(%d , *(c.asWord));//print word (16-bit LE unsigned short)
printf(%d\n, *(c.asDWord));//print dword (32-bit LE unsigned int)
c++; //step to next byte
}
where asWord/asDWord would coerce the array to a virtual word or
dword array.
maybe there are ways the interface can be made nicer, and is ideally
without being horridly inefficient (such as the hair in the above if
the FileAsArray is to behave like a proper array type). for example,
if every FileAsArray+Integer - new FileAsArray, although this could
work, it would spew garbage and be slow in the above (whereas in-place
mutation has its own costs). a partial trick (used in implementing array
iteration) was to generally use a pointer into the array body as the
index, but this would require memory-mapping the file (and thus not work
well with large files on 32-bit systems).
VM-level value-types are another option, but these are a relatively
costly feature in general (as they are allocated/copied/freed
more-or-less continuously in the present VM).
all this would likely mean having to use file-arithmetic sparingly, and
instead mostly access array-like files by index.
for(i=0; ic.length; i++)
printf(%d , c[i]);
but, in any case, could offer an alternative to the traditional
read/write/seek interface.
hmm...
The rather intense focus on usability in recent years is probably the
most powerful tool we have to sweep away all these partially
implemented and poorly thought out concepts.
User experience is even now the main driving force behind the
evolution of programming environments. Even without auto-completion
and fancy debuggers, there is a profound growth in the use of dynamic
languages. The millions of hours of development that have gone into
the tools the major computer vendors have been using to lock people
into their platforms are no match. What matters for developers is
quick turnaround for debugging problems and code that expresses its
intention in a concise and elegant manner. This is a profound change
in the past 5 years.
potentially, but there are limits, and the target is still relatively
stable/slow-moving, at least going by TIOBE and similar.
meanwhile, trying to balance being conservative and practical with
trying out possibilities is difficult.
So how can you make simple languages simple to use? Developers have
been rejecting complex GUIs in favour of plain text. If Google and
Apple are right, every program component isn't a file on a disk, but
rather some network accessible resource. On the other hand, a cynical
person would say that the cloud is just another broken metaphor to
pile onto the heap, because all this stuff is going to be built on top
of the concepts we are already stuck with.
cloud == HTTP, CIFS, WebDav, ...
have some servers, and pile together a bunch of assorted stuff (network
file-sharing, running virtualized Linux instances in VMware or QEMU,
...) and suddenly from this a cloud emerges...
although, maybe it is a good thing, or a cloud emerging from a big
burning pile of crap, and service-providers blowing the smoke up... well...
I would much rather keep most of the disk/memory/CPU/... on the
client-side, or use a hybrid model. say, where for ones' low-power
mobile devices, a lot of the raw power is provided, say, by a PC they
have running at their house, as then one has no obligation to pay a
service provider for their storage and CPU usage.
about the only real place it really makes sense IMO is for things like
high-volume web-servers / ..., where a service provider can probably
provide the resources (processing power and bandwidth) in a more
cost-effective manner than, say, getting a
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 23/06/2011, at 10:08 AM, Steve Wart wrote: So how can you make simple languages simple to use? Developers have been rejecting complex GUIs in favour of plain text. If Google and Apple are right, every program component isn't a file on a disk, but rather some network accessible resource. On the other hand, a cynical person would say that the cloud is just another broken metaphor to pile onto the heap, because all this stuff is going to be built on top of the concepts we are already stuck with. I find the simplest thing is actually nothing at all. It's there before you start. As the Rubinius guys' adage goes: (There is) no code (that) is faster than (having) no code (at all). (Brackets added by me, for understanding purposes, because I find the way they usually write that to be too simple to aide understanding). Thus... (my real point here)... the fact that we call this stuff code or language is at fault in my opinion. If something is codified, there's something wrong. Things need to be immediately obvious when you observe them. Easy to say, hard to implement. Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
The emergence of ubiquitous internet media and the distribution architecture we've built around it has shifted attention to the communication needs of people. Many are employed in the Web industry and others unemployed... market forces come into play. It's all possible because of established (and apparently very persistent!) protocols, like IPv4 and HTTP. Any technology that is fluent in these can potentially survive in the marketplace. If it does other, more important things better than its competitors, it may even thrive. Of course, these protocols can have serious defects, but even so they are somewhat liberating. In the realm of programming, they are things like plain text and language specifications. People who want a small language should be prepared to be somewhat idiosyncratic, if they want to express big or complex programs. I mean 'language' here not just in terms of a programming language definition but rather to mean all constructs (or, more fundamentally, concepts and conventions) which are shared, which belong in some sense to a culture rather than an individual. If they don't enlarge the language (usually via some library) they enlarge their personal idiom instead, which may not be as portable. Progress depends on the ability of individuals to nonetheless communicate these new ideas 'uphill' so to speak, but more immediately on the ability to make them, so as to make them better. Some leverage here may be available through improvements in the notion of expressivity itself. There is a wonderfully large number of experiments being done in dynamic language design these days, from Ruby to REBOL... If more of them would take what I'd say is the major lesson of Smalltalk and become fully integrated personal computing environments, rather than living off the previous generation's operating systems, perhaps they might be able to move some of the uncomfortable fixed points of usability and complexity, as well as gain more user-programmers altogether. I think FONC is, at least, a pointer in the right direction; a reminder that there's plenty of room out there beyond the familiar. -- Max On Wed, Jun 22, 2011 at 5:08 PM, Steve Wart st...@wart.ca wrote: Still, databases and file systems are both based on concepts that predate electronic computers. When Windows and Macs came along the document metaphor became prevalent, but in practice this was always just a user friendly name for a file. The layers and layers of slightly broken metaphors never gets simpler. They interact in unpredictable and inconvenient ways that people adapt to, because people are far more adaptable than the machines we build. The rather intense focus on usability in recent years is probably the most powerful tool we have to sweep away all these partially implemented and poorly thought out concepts. User experience is even now the main driving force behind the evolution of programming environments. Even without auto-completion and fancy debuggers, there is a profound growth in the use of dynamic languages. The millions of hours of development that have gone into the tools the major computer vendors have been using to lock people into their platforms are no match. What matters for developers is quick turnaround for debugging problems and code that expresses its intention in a concise and elegant manner. This is a profound change in the past 5 years. So how can you make simple languages simple to use? Developers have been rejecting complex GUIs in favour of plain text. If Google and Apple are right, every program component isn't a file on a disk, but rather some network accessible resource. On the other hand, a cynical person would say that the cloud is just another broken metaphor to pile onto the heap, because all this stuff is going to be built on top of the concepts we are already stuck with. Virtual environments might also be a good way to keep the detritus of the past from cluttering the future, but a cynic might have some opinions about that too :-) Cheers Steve On Tue, Jun 21, 2011 at 7:30 PM, Julian Leviston jul...@leviston.net wrote: Yeah I've been using this DBMS on and off for years. I have a copy of it installed on my machine. It's INCREDIBLY fast. The interesting thing for me recently was that they've built an implementation of Ruby on top of it, and called it MagLev, and it's now possible to have persisted, fast, pure object-oriented data store in Ruby and/or Rails applications... and as we know, there's an implementation of O/Meta for Ruby... ;-) Julian. On 22/06/2011, at 4:58 AM, Steve Wart wrote: Also of interest might be GemStone/S, an ODBMS that is still heavily used in at least two large Investment Banks (JP Morgan and UBS), as well as several large shipping companies (OOCL, Coscon, and NYK). Marketing blurb here http://seaside.gemstone.com/docs/OOCL_SuccessStory.pdf Basically it's an environment that replaces the limitations of SQL
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 23/06/2011, at 12:35 PM, Max OrHai wrote: People who want a small language should be prepared to be somewhat idiosyncratic, if they want to express big or complex programs. I mean 'language' here not just in terms of a programming language definition but rather to mean all constructs (or, more fundamentally, concepts and conventions) which are shared, which belong in some sense to a culture rather than an individual. If they don't enlarge the language (usually via some library) they enlarge their personal idiom instead, which may not be as portable. Progress depends on the ability of individuals to nonetheless communicate these new ideas 'uphill' so to speak, but more immediately on the ability to make them, so as to make them better. Some leverage here may be available through improvements in the notion of expressivity itself. There is a wonderfully large number of experiments being done in dynamic language design these days, from Ruby to REBOL... If more of them would take what I'd say is the major lesson of Smalltalk and become fully integrated personal computing environments, rather than living off the previous generation's operating systems, perhaps they might be able to move some of the uncomfortable fixed points of usability and complexity, as well as gain more user-programmers altogether. I think FONC is, at least, a pointer in the right direction; a reminder that there's plenty of room out there beyond the familiar. So, by that reasoning, GNU SmallTalk doesn't exhibit what you'd express as being the major lesson from SmallTalk? Interestingly, one of the most irritating things for me was the User Interface when I first came to Squeak, having programmed in GemStone SmallTalk for a number of years (which we were programming via snippets plugged into HTML, and sometimes via GemStone/J, on a mac natively, not inside a SmallTalk environment at all). At that point I had experience in AmigaDOS, MacOS (pre X), Windows 95, NT and GEOS (commodore 64 based GUI) would you believe... Squeak was supremely irritating for two reasons: Firstly, the UI was completely different without having any easy way to say hey, I'm a n00b, turn on n00b mode so I can learn this thing, and second it seemed far too easy to make irreparable damage, or even lose what I was doing... (probably due to point 1). So I'd be very much against your build the whole world so you can express the language philosophy. Potentially, though, I'd say having the idea of a SmallTalk-like image loaded into a fully graphical interface AS AN OPTION is awesome... I'd love to have a visual debugger for my Ruby code the likes of the SmallTalk ones... (to a degree, MagLev kind of allows this as a possibility). My issue seems to be that if you change the language at a base level while in one of those environments, you kind of break everything... don't you? They don't really lead to experimentation very well. Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
I wish that emacs / vi, GBD, and the Unix shell had anything close to the n00b mode provided by Squeak in terms of inline documentation, tool tips, menus etc.. But, yeah, Squeak has serious problems, and you're absolutely right that it's too hard to tinker with the core of it, just like every other computing system on the planet. When you hack your kernel, should you be free enough to do so, you *expect* to break everything... don't you? You'll notice we've been discussing things like Worlds, which might be one way to address this particular issue. Pioneering isn't for everyone, but the conventional roads don't lead where I want to go. My daily software environment has been over-engineered to solve too many problems I don't have. I'd like to be able to shed some of the excess complexity of a conventional OS while retaining the media capabilities and increasing the overall expressive power. I don't mind giving up the comfort of familiar habits, and I don't give a whit about delivering a product to anyone. That's why I read this list. -- Max On Wed, Jun 22, 2011 at 8:21 PM, Julian Leviston jul...@leviston.netwrote: On 23/06/2011, at 12:35 PM, Max OrHai wrote: People who want a small language should be prepared to be somewhat idiosyncratic, if they want to express big or complex programs. I mean 'language' here not just in terms of a programming language definition but rather to mean all constructs (or, more fundamentally, concepts and conventions) which are shared, which belong in some sense to a culture rather than an individual. If they don't enlarge the language (usually via some library) they enlarge their personal idiom instead, which may not be as portable. Progress depends on the ability of individuals to nonetheless communicate these new ideas 'uphill' so to speak, but more immediately on the ability to make them, so as to make them better. Some leverage here may be available through improvements in the notion of expressivity itself. There is a wonderfully large number of experiments being done in dynamic language design these days, from Ruby to REBOL... If more of them would take what I'd say is the major lesson of Smalltalk and become fully integrated personal computing environments, rather than living off the previous generation's operating systems, perhaps they might be able to move some of the uncomfortable fixed points of usability and complexity, as well as gain more user-programmers altogether. I think FONC is, at least, a pointer in the right direction; a reminder that there's plenty of room out there beyond the familiar. So, by that reasoning, GNU SmallTalk doesn't exhibit what you'd express as being the major lesson from SmallTalk? Interestingly, one of the most irritating things for me was the User Interface when I first came to Squeak, having programmed in GemStone SmallTalk for a number of years (which we were programming via snippets plugged into HTML, and sometimes via GemStone/J, on a mac natively, not inside a SmallTalk environment at all). At that point I had experience in AmigaDOS, MacOS (pre X), Windows 95, NT and GEOS (commodore 64 based GUI) would you believe... Squeak was supremely irritating for two reasons: Firstly, the UI was completely different without having any easy way to say hey, I'm a n00b, turn on n00b mode so I can learn this thing, and second it seemed far too easy to make irreparable damage, or even lose what I was doing... (probably due to point 1). So I'd be very much against your build the whole world so you can express the language philosophy. Potentially, though, I'd say having the idea of a SmallTalk-like image loaded into a fully graphical interface AS AN OPTION is awesome... I'd love to have a visual debugger for my Ruby code the likes of the SmallTalk ones... (to a degree, MagLev kind of allows this as a possibility). My issue seems to be that if you change the language at a base level while in one of those environments, you kind of break everything... don't you? They don't really lead to experimentation very well. 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: Age and Language (was Re: [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?)
There are certainly practical differences between conventional relational databases and hierarchical filesystems, without having to get into implementation details. I'm sure at least a few people on this list are familiar with the BeOS filesystem, which acted much more like a relational DBMS than most filesystems do... over a decade later, we've now got hacked-on DBMS-like functionality in the form of (e.g.) Spotlight, but most users are stuck with the little walled-off databases presented by their media library and email application software. Once again, it's not a technical issue so much as a matter of perspective. http://www.theregister.co.uk/2002/03/29/windows_on_a_database_sliced/ -- Max On Mon, Jun 20, 2011 at 11:31 PM, BGB cr88...@gmail.com wrote: 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/fonchttp://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
Also of interest might be GemStone/S, an ODBMS that is still heavily used in at least two large Investment Banks (JP Morgan and UBS), as well as several large shipping companies (OOCL, Coscon, and NYK). Marketing blurb here http://seaside.gemstone.com/docs/OOCL_SuccessStory.pdf Basically it's an environment that replaces the limitations of SQL with the limitations of Smalltalk. It's interesting that the debate about O/R mapping is still stuck in the same place it was in 1990. After all these years I still think it would be easier to implement relational semantics on top of this sort of environment than vice-versa, but last time I checked Oracle and Microsoft weren't taking my calls. This paper is kind of old, but it describes the implementation of a DBMS inspired by the description of Smalltalk in the famous 1981 issue of Byte magazine. http://portal.acm.org/citation.cfm?id=602300 Making smalltalk a database system To overcome limitations in the modeling power of existing database systems and provide a better tool for database application programming, Servio Logic Corporation is developing a computer system to support a set-theoretic data model in an object-oriented programming environment We recount the problems with existing models and database systems We then show how features of Smalltalk, such such as operational semantics, its type hierarchy, entity identity and the merging of programming and data language, solve many of those problems Nest we consider what Smalltalk lacks as a database system secondary storage management, a declarative semantics, concurrency, past states To address these shortcomings, we needed a formal data model We introduce the GemStone data model, and show how it helps to define path expressions, a declarative semantics and object history in the OPAL language We summarize similar approaches, and give a brief overview of the GemStone system implementation Cheers, Steve On Tue, Jun 21, 2011 at 11:38 AM, Max OrHai max.or...@gmail.com wrote: There are certainly practical differences between conventional relational databases and hierarchical filesystems, without having to get into implementation details. I'm sure at least a few people on this list are familiar with the BeOS filesystem, which acted much more like a relational DBMS than most filesystems do... over a decade later, we've now got hacked-on DBMS-like functionality in the form of (e.g.) Spotlight, but most users are stuck with the little walled-off databases presented by their media library and email application software. Once again, it's not a technical issue so much as a matter of perspective. http://www.theregister.co.uk/2002/03/29/windows_on_a_database_sliced/ -- Max On Mon, Jun 20, 2011 at 11:31 PM, BGB cr88...@gmail.com wrote: 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 ___ 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: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 6/19/2011 9:49 PM, Julian Leviston wrote: On 20/06/2011, at 2:33 PM, BGB wrote: in a sense, the metaphor no longer works, and should likely itself be left to fall into the recycle-bin of history. worse yet is having to read stuff written by people who actually take this metaphor seriously. Given the historical perspective, it was appropriate at the time. These days, our computers are so vastly scaled beyond the original intention of the file metaphor that it's getting silly, I'd grant you that. yep. It's not really any surprise, then, that Apple's trying to get rid of the file system, is it? :) Mind you, I think the app metaphor is just as crappy, personally. I like the idea of workflows much more, and combining a few small simple tools together to get some particular job done. interestingly, I don't believe in getting rid of the file-system, per-se, as technically it works fairly well and is a proven piece of technology. but, mostly, I just want the filing-cabinet metaphor to go away, if anything, so that people making stupid computer/filing-cabinet analogies will go away, or worse yet, talking about computers implying that they themselves are subject to the same sort of limitations as filing cabinets, or describing technical limitations WRT computers and data storage which haven't really been the case since maybe the 70s or 80s... (such as claiming that files are simply collections of fixed-format records and are unable to store heterogeneous data, leaving me to think WTF?...). if I could make any notable change to how filesystems worked, it would be likely to introduce user-defined VFS systems as an OS-level facility. this would mean one of several things: ability to more easily introduce user-defined virtual directories as a part of the host operating file-system (as is, on both Windows and Linux, it is a little nasty...); ability to run apps (and parts of apps) inside of custom VFS's (more like finer-grained chroot); potentially a virtual mount facility, where an app can locally mount/unmount volumes it has rights to, and can choose whether or not they are visible to the external OS (say, an app might mount its own data-files as volumes, and choose that only itself can see them); ... as-is, it is generally less nasty to do this within the app, essentially having the app provide its own VFS and drivers (for example, my project can mount zip-files as volumes, including for random read/write, albeit with a few limitations...). going more extreme, one could begin to blur the line between files and in-program objects and code (say, packages, functions/methods/variables, ... could be potentially visible as part of the VFS). implementation-wise, there is likely to be a layer of separation above the true filesystem (this would introduce a huge number of tiny files which would not map effectively onto most existing filesystems, and so it would seem better to introduce this as a virtual mount). another possible idea could be to go from a traditional mount/unmount/fstab style system, to possibly supporting a mechanism partway between mounts and symlinks (one doesn't mount a volume, they link to it...). I am partly imagining links partway between Unix-style symlinks, and the links supported by Windows, but with more features (such as ability to mount something via accessing a link, or redirect to a network resource such as a CIFS/HTTP/WebDav/FTP share). and, for something like the prior concept, they can create a link from a directory into a program, allowing the program to fill a role partway between being an application, an FS driver, and an OS service. taken further, this could also potentially be partly used as an alternative to traditional DLL/shared-library and IPC/RPC mechanics as well (could get hairy, primarily if C/C++ and data sharing are involved, potentially limiting to high-level managed types, which may either be copied or passed as handles...). worst case for the above, probably can't be too much worse than MS's COM system (COM / COM+ / DCOM). a proper HLL could probably mostly hide the underlying mechanisms. trivia: in a much-older version of my projects, it was possible to open network sockets purely via a VFS vffopen() operation, but this feature later died with a rewrite of my VFS mechanism some years back (I may eventually re-add it, possibly among several other VFS features, namely cached HTTP mounts and ability to support virtual file encryption). basically, the rewrite partly broke my ability to route network sockets over the local VFS (in general), as well as several other things. my code also generally works within a local VFS, rather than directly using the OS provided FS facilities. the VFS is actually one of the oldest parts of my codebase (dating to sometime around the late 90s...). For example, when web programming on a specific web app, I use a web browser, a text editor, a
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 20/06/2011, at 4:33 PM, BGB wrote: interestingly, I don't believe in getting rid of the file-system, per-se, as technically it works fairly well and is a proven piece of technology. Interestingly, I disagree entirely. Finding things is a pain for most people (including myself). Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 20/06/2011, at 4:33 PM, BGB wrote: For example, when web programming on a specific web app, I use a web browser, a text editor, a database management program, a command line, and a couple other tools. It'd be nice to be able to fit these tools together into a pseudo-app and then build documents for this pseudo-app... that were accessible within the pseudo-app (ie not the file system) to use Apple's idea, and that could simply do all the things I generally need to do... (there are only a few tasks I generally do and none of them correlate directly into any one particular application). I love the way I edit text in my one particular text editor. Why do I have to use a different editor to edit my email text? lol... it makes little sense. well, mostly I am using Windows Explorer and the shell (both CMD and Bash) for managing things on Windows, and this setup works adequately. admittedly, I am not entirely sure how the idea you are describing will work, so maybe it can be described in more detail? (like, what parts it may contain and how they may fit together...). Perhaps you might take a look at Panic's Coda http://www.panic.com/coda/ This is *one instance* of what I'm talking about generally... it does for most web developers what I was describing... but I'm talking about having a more modular approach in that you should be able to build a tool that incorporates other things, too (for example, I might decide I want a particular colour-picker in there, or a specific interactive language reference or API reference, or perhaps I'd like to have some form of rudimentary image editing, because I do that in my work). You get me? Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 6/19/2011 11:54 PM, Julian Leviston wrote: On 20/06/2011, at 4:33 PM, BGB wrote: interestingly, I don't believe in getting rid of the file-system, per-se, as technically it works fairly well and is a proven piece of technology. Interestingly, I disagree entirely. Finding things is a pain for most people (including myself). a relevant distinction can be made though: for the user; or, for programs... it is like, for programs, systems with a structure similar to the Windows System Registry are very useful, but for users, they can become hopelessly confused, and naive changes risk irreparably breaking the OS... (one of my first personal major encounters with the System Registry had, at the time, rendered the computer unable to boot...). Unix-style single-root-mount systems are IMO most convenient from a software-development perspective, albeit they have a few present severe limitations (mostly that it is nearly impossible to keep applications and the OS separate), as apparently Unix and Linux were designed with it in mind that apparently of course, user applications and data will go in /usr/bin and /usr/var and similar, and system applications and data in /bin and /var a few features I sort of wish Linux had: ~/bin, ~/var, ~/etc, ... (or: ~/.usr/bin, ~/.usr/var, ~/.usr/etc, ...), which would be used for per-user programs and settings (vs the current mess that ~ tends to become); a shared-object system which looked up SO's more like Windows does DLLs (largely eliminating the need for rpath and similar); ... a Unix-style organization for a VFS is fairly helpful though. for users, it is different: MS partly does the whole My Documents thing, I guess as an effort to simplify things for newbies (albeit, IMO, they did it poorly). one possibility would be organizing the filesystem differently for the user and for the OS. ... in my case, I have a personal file-management system which mostly prevents me losing stuff, but is technically a fairly complex/bureaucratic process (would be difficult to really elaborate on). OTOH, my dad just sort of naively organizes things in a deep hierarchy based on associations, and so tends to loose stuff fairly often. or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 2011-06-19 Sun, at 09:33 PM, BGB wrote: .. which mappings are more natural and under which circumstances seems to be the important question and one, AFAICS, that may not well answered by simply replacing words with ideograms and expressions with boxes and arrows. agreed... I really don't believe graphical solutions are necessarily ideal. but, at the same time, there is also the matter of finding the right tool for the job. for example, code works great for expression program logic, but falls flat for many other tasks: creating a graphical image; creating a 3D model or scene; ... in these cases, having more specialized tools tends to be far more effective. I agree and notice that none of the good solutions we have for those involve ideograms and... boxes and arrows. It's as if compsci culture is unable to let go of flow charts, even if they aren't used for constructing complex circuits anymore which (AFAIK) was the inspiration for their use. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 6/19/2011 11:58 PM, Julian Leviston wrote: On 20/06/2011, at 4:33 PM, BGB wrote: For example, when web programming on a specific web app, I use a web browser, a text editor, a database management program, a command line, and a couple other tools. It'd be nice to be able to fit these tools together into a pseudo-app and then build documents for this pseudo-app... that were accessible within the pseudo-app (ie not the file system) to use Apple's idea, and that could simply do all the things I generally need to do... (there are only a few tasks I generally do and none of them correlate directly into any one particular application). I love the way I edit text in my one particular text editor. Why do I have to use a different editor to edit my email text? lol... it makes little sense. well, mostly I am using Windows Explorer and the shell (both CMD and Bash) for managing things on Windows, and this setup works adequately. admittedly, I am not entirely sure how the idea you are describing will work, so maybe it can be described in more detail? (like, what parts it may contain and how they may fit together...). Perhaps you might take a look at Panic's Coda http://www.panic.com/coda/ This is *one instance* of what I'm talking about generally... it does for most web developers what I was describing... but I'm talking about having a more modular approach in that you should be able to build a tool that incorporates other things, too (for example, I might decide I want a particular colour-picker in there, or a specific interactive language reference or API reference, or perhaps I'd like to have some form of rudimentary image editing, because I do that in my work). You get me? errm, the modular part sort of sounds like what OLE and COM were meant to be (although presumably without all the MS or the suck, and ideally without big security holes like putting virus-laden ActiveX controls in emails...). the linked-to site sort of sounds like an IDE or something... I am not certain I follow how this would get rid of file-systems though... I am not aware of any good alternative to the filesystem which is generally better than the filesystem (can effectively manage huge numbers of files and multiple TB of disk space, can effectively multiplex between a large number of apps, and still is accessible to mere humans, ...). also, the vast majority of existing software would break if no FS were available. although, there are things which are lacking with traditional OS-level filesystems: ability to have localized and customized filesystems (usually done via app-local VFS's); ability to easily sandbox or virtualize the filesystem (apart from fairly heavy-handed/costly mechanisms, such as chroot); ability to see into app-internal data (can be handled via FUSE on Linux, but AFAIK there is no good analogue for Windows); generally require jerkoff to access network resources (although GVFS does this, but the Linux VFS requires mounts, and Windows requires mount as drive letter or using Win32 API calls to be able to access UNC files, which for who-knows-what-reason don't seem to work with fopen/fclose or open/close last I checked, and instead require using OpenFile or such...); ... sadly, the least nasty (IMO) option is essentially to just have ones' program provide and use its own VFS internally... actually, Steam also does this (for one who wants their apps to work with GCF files) but sadly the process of connecting to the Steam VFS is ... nasty... hence, even then, one still needs their own VFS... or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 6/20/2011 2:19 AM, Julian Leviston wrote: On 20/06/2011, at 6:33 PM, BGB wrote: I am not certain I follow how this would get rid of file-systems though... I am not aware of any good alternative to the filesystem which is generally better than the filesystem (can effectively manage huge numbers of files and multiple TB of disk space, can effectively multiplex between a large number of apps, and still is accessible to mere humans, ...). Really? So you don't like the idea of an application managing its own content? Effectively saying hey, let's store our data with our code... which is the encapsulation pattern of OOP isn't it? I missed wherever this was mentioned... but, no, this is not generally ideal either IMO. if an image-based strategy, it is my personal belief that these are unlikely to (in themselves) be a general-purpose workable strategy (if contrasted with a file-based, or file-backed strategy). databases are sort of a compromise IMO, as then one can store their data in a database, and fetch it back out. IMO, this is better with hierarchical (registry-like databases) though, as IMO most generic data-storage tasks are a poor match for an RDBMS (since it is generally a pain to put data into or get it out of an RDBMS), but an HDB usually matches a little more closely with application data-storage tasks IME. in the case of my BGBScript language, the HDB actually forms a fairly important part of the underlying structure of the VM. but, a database is still stored as files... I guess XML is also possible/popular, but I am not aware of any particularly scalable way to access/query/... lots of XML-based data (and a DB which quickly bogs down is not exactly ideal...). also, by itself, XML isn't terribly easy to work with either... hmm... S-Expression database?... sort of like a hybrid between a database and a persistent store. or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 20/06/2011, at 8:06 PM, BGB wrote: hmm... S-Expression database?... sort of like a hybrid between a database and a persistent store. or such... I'd like to know if you think there's a difference between a filesystem and a database... conceptually... or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 6/20/2011 3:22 AM, Julian Leviston wrote: On 20/06/2011, at 8:06 PM, BGB wrote: hmm... S-Expression database?... sort of like a hybrid between a database and a persistent store. or such... I'd like to know if you think there's a difference between a filesystem and a database... conceptually... or such... interesting thought... well, filesystems are generally hierarchical, don't generally support user-defined fields, and store all data as large binary globs. some filesystems (such as HFS/HFS+ and NTFS) allow multiple forks per file, others don't (FAT32 / EXT* / ...). generally, filesystems store data in terms of disk-blocks, and often make little/no provision for tiny files (partial exception being EXT* and ReiserFS, the former supporting inlining the contents of small files into the inode, the latter supporting the storage of sub-block files into B+Tree leaves). databases may come in any number of varieties, and generally store structured or semi-structured information; the contents of a database are generally individual datums, rather than binary globs; typically, databases store contents according to user-defined structures; typically, databases are stored using structures such as B+Trees; ... for example, the HDB used for my VM framework has a structure like: each node is identified by a path, generally with a POSIX-style name foo/bar/baz; each node may contain a number of key/value pairs, with a special null/default key internally named '_', and the key is identified following ':', and sometimes key indices are used following a '.', ... stored values are generally untyped, and treated as if they were strings. foo/bar/baz:name node: foo/bar/baz key: name foo/bar/baz:item.3 node: foo/bar/baz key: item index: 3 the index allows treating the key like a small array. possible, but not currently supported (at least not efficiently) would be to apply an index to a node, allowing treating the node as a makeshift indexed table: foo/bar/baz.59:name the optimization would be to transform the above into a key-index: foo/bar/baz:name.59, allowing for storing the values as arrays. however, in this case, table-like nodes would not allow for indexed keys: foo/bar/baz.59:item.5 since this would require double-indexing, but the keys are presently only defined as 1D arrays. at present, this will work, as the node index would just store multiple nodes with dotted names (baz.59 will simply be interpreted as a nodes' name). as-is, node names may also begin with '.', however these nodes are treated as volatile and effectively will not be saved back into the database (this mechanism is generally used for storing volatile information, namely information about things like environment variables, which libraries or modules are currently loaded, ...). so .var/foo:name is volatile, as neither .var nor any of its children will be saved to disk. note: the present system does not allow for non-trivial queries (besides ?next, ?prev, ...), but interestingly, for most uses of this system, one doesn't generally need to perform queries (much like, for the most part, application code doesn't really need readdir either, since its main use is mostly for presenting directory listings to the user). it is worth noting that the design of this system was originally partly inspired by the Windows Registry, but there are differences (the nodes being untyped, and the use of '/' rather than '\', and the present lack of hives albeit a similar mechanism may be needed for other reasons, and may need to be retrofitted on, that or supporting in-database mounts and links...). the external serialized database format somewhat resembles '.reg' files (albeit, technically if .reg and .ini files hybridized). unlike more proper databases, the current implementation uses AVL trees rather than B+Trees internally. the main reason for AVL trees was that they were less effort to implement (actually, it is a tree of AVL trees, as each node-level starts a new AVL tree). the internal structure of the code for managing the HDB is a bit nasty, luckily, nearly all access is via named path-strings (the path-key then is its canonical structure, and all of the mucking around with AVL trees/... is hidden behind the API). as I think noted previously, the main reason I chose an HDB style design (rather than an RDB / Relational Database) was because an HDB is generally much easier to work with via a programmatic interface, whereas working with relational databases is a bit more painful, as nearly every operation will involve queries and having to work with tables or similar... or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
Hi... (see below)... On 21/06/2011, at 3:42 AM, BGB wrote: On 6/20/2011 3:22 AM, Julian Leviston wrote: On 20/06/2011, at 8:06 PM, BGB wrote: hmm... S-Expression database?... sort of like a hybrid between a database and a persistent store. or such... I'd like to know if you think there's a difference between a filesystem and a database... conceptually... or such... interesting thought... Note that I asked if you think there's a difference not how they differ. I'd be surprised if there were any people on this list who didn't know how they differed. I don't consider there to be much of a difference between the two, conceptually - they are both concerned with the retrieval and storage of data (I'm using the term 'data' here to mean any form of raw information at all, useful or otherwise, including programs). well, filesystems are generally hierarchical, don't generally support user-defined fields, and store all data as large binary globs. some filesystems (such as HFS/HFS+ and NTFS) allow multiple forks per file, others don't (FAT32 / EXT* / ...). generally, filesystems store data in terms of disk-blocks, and often make little/no provision for tiny files (partial exception being EXT* and ReiserFS, the former supporting inlining the contents of small files into the inode, the latter supporting the storage of sub-block files into B+Tree leaves). databases may come in any number of varieties, and generally store structured or semi-structured information; the contents of a database are generally individual datums, rather than binary globs; typically, databases store contents according to user-defined structures; typically, databases are stored using structures such as B+Trees; ... for example, the HDB used for my VM framework has a structure like: each node is identified by a path, generally with a POSIX-style name foo/bar/baz; each node may contain a number of key/value pairs, with a special null/default key internally named '_', and the key is identified following ':', and sometimes key indices are used following a '.', ... stored values are generally untyped, and treated as if they were strings. foo/bar/baz:name node: foo/bar/baz key: name foo/bar/baz:item.3 node: foo/bar/baz key: item index: 3 the index allows treating the key like a small array. possible, but not currently supported (at least not efficiently) would be to apply an index to a node, allowing treating the node as a makeshift indexed table: foo/bar/baz.59:name the optimization would be to transform the above into a key-index: foo/bar/baz:name.59, allowing for storing the values as arrays. however, in this case, table-like nodes would not allow for indexed keys: foo/bar/baz.59:item.5 since this would require double-indexing, but the keys are presently only defined as 1D arrays. at present, this will work, as the node index would just store multiple nodes with dotted names (baz.59 will simply be interpreted as a nodes' name). as-is, node names may also begin with '.', however these nodes are treated as volatile and effectively will not be saved back into the database (this mechanism is generally used for storing volatile information, namely information about things like environment variables, which libraries or modules are currently loaded, ...). so .var/foo:name is volatile, as neither .var nor any of its children will be saved to disk. note: the present system does not allow for non-trivial queries (besides ?next, ?prev, ...), but interestingly, for most uses of this system, one doesn't generally need to perform queries (much like, for the most part, application code doesn't really need readdir either, since its main use is mostly for presenting directory listings to the user). it is worth noting that the design of this system was originally partly inspired by the Windows Registry, but there are differences (the nodes being untyped, and the use of '/' rather than '\', and the present lack of hives albeit a similar mechanism may be needed for other reasons, and may need to be retrofitted on, that or supporting in-database mounts and links...). the external serialized database format somewhat resembles '.reg' files (albeit, technically if .reg and .ini files hybridized). unlike more proper databases, the current implementation uses AVL trees rather than B+Trees internally. the main reason for AVL trees was that they were less effort to implement (actually, it is a tree of AVL trees, as each node-level starts a new AVL tree). the internal structure of the code for managing the HDB is a bit nasty, luckily, nearly all access is via named path-strings (the path-key then is its canonical structure, and all of the mucking around with AVL trees/... is hidden behind the API). as I think noted previously, the main reason I chose an HDB style design (rather than
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 2011-06-14 Tue, at 09:36 PM, Julian Leviston wrote: The thing that irritates me about this attitude of don't consider kids as equal is that we DO consider them as equal in other frames... we expect so much of them in terms of linguistic and cognitive development... and actually the abstractions (zero-th order abstraction) capable of and exhibited by a 5 year old are used when in the activity called programming all the time... so much so we as adult programmers rarely think about them. I agree. People seem to define smart as something like things I can't do easily. So, for example, if they can use a keyboard, well someone like a child who can't must not be smart and this is why people were surprised when the mouse and graphical UIs allowed toddlers to use the Mac or touch screens allowed near infants to use iPads today. All along it was an issue of unnatural conceptual mapping (like asking a right handed person to throw with their left hand) that was the problem, not a lack of smarts. From this perspective we could see the history of programming as one of finding ever more natural mappings between how our minds work and how we can get machines to do what we want - just as steering wheel and floor pedals map between our bodies and our vehicles. If so, which mappings are more natural and under which circumstances seems to be the important question and one, AFAICS, that may not well answered by simply replacing words with ideograms and expressions with boxes and arrows. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 20/06/2011, at 12:20 PM, Steve Dekorte wrote: From this perspective we could see the history of programming as one of finding ever more natural mappings between how our minds work and how we can get machines to do what we want - just as steering wheel and floor pedals map between our bodies and our vehicles. If so, which mappings are more natural and under which circumstances seems to be the important question and one, AFAICS, that may not well answered by simply replacing words with ideograms and expressions with boxes and arrows. Or even - might I proffer - that mapping are fairly arbitrary by their very nature, and therefore perhaps the mappings should be able to be inspected, translated between, and even completely reworked or added to as deemed fit. One of the issues that immediately springs from this is that as programmers of incredibly large (in terms of complexity) computers which don't offer physical switches, it's almost impossible to escape this abstract mapping, because the tools used to deal even directly with what makes up a computer involve a large amount of mapping (always at least two). It's not like we can switch switches anymore! In other words, the programming interfaces are virtual. We're always modelling. We need to also be CONTEXTUALLY EXPLAINING what the models are as we're modelling (ie baked into the modelling process, even) them so that people trying to understand the models (artefacts of our processes) can hold them in the right contextual frame. (Holding something in the right contextual frame is another name for understanding). What I'm stipulating, is not replacing words with ideograms and expressions with boxes and arrows, but building a representation (a visual mapping) such that it's immediately obvious what the intent of the objects in a system are doing. For example, if you have two numbers, then the numbers get visually transformed each to a set of dots with a perimeter (border) around them, and they're animated towards each other and the border becomes one border, and the dots all join into the one set... and then that set is animated into the sum of the two original numbers, this is *A* visual representation of addition. (note that there are definitely many others - there are many methods to doing something just as there are in other places in computing, and just as there are many styles to learning. If I didn't understand that representation of addition, then I pick another one, and interact with or watch that). Note that addition is a very low level concept used thousands of times a day in computer programming, so most likely most of *us* as fairly complex programmers wouldn't ever use this particular pedagogical tool... unless we wanted to explain addition to our kids... we might replace the dots with 3d oranges... and then a tiny child could understand the concept in seconds... Note also that the only thing I'm really interested in proposing here is that knowledge be inlined... that is... as I'm writing code, my intention is written down too... or to put another way... if I'm drawing a terrain map THAT I INCLUDE THE KEY FOR THE MAP WITH THE MAP ITSELF... so that later, someone can interpret what it means. This removes the need for documentation, and also allows it to be generated easily if it's required... but also, hopefully doesn't let people build things they don't understand... so that in the end if someone doesn't understand how something in particular works, well then the learning of it is in the environment where the object is itself... Note that this seems SO RIDICULOUSLY OBVIOUS to me that it's not even funny... it also makes explaining computer to people incredibly saddening, because to someone with the requisite knowledge, computing is incredibly easy, but getting the requisite bits of knowledge into the right parts of a person is often so frustrating for the person in question. One thing I liked about Self and to a lesser degree SmallTalk (especially Squeak) is that if you want to work out how something works, you yank it out, or build an example of it, and inspect it... and you can go on ad infinitum... inspecting... seeing how things are composed. There's still a HUGE amount of assumed and required knowledge in there in order to use the system, but the idea is what I mean... where there's a totally uniform interface that can be inspected to learn about it, up to the point that the original programmer decides to allow you to see inside it. I should be able to inspect to the degree of machine code... if I want to... to find out how my large sum addition is clothed in machine code on my particular computer... and perhaps even lower - see the particular way that byte-size integer addition happens on my particular machine if there's a pedagogical model in place to see it. I know for a fact that young inquisitive kids will find this fascinating, and when there's less stuff
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 6/19/2011 7:20 PM, Steve Dekorte wrote: On 2011-06-14 Tue, at 09:36 PM, Julian Leviston wrote: The thing that irritates me about this attitude of don't consider kids as equal is that we DO consider them as equal in other frames... we expect so much of them in terms of linguistic and cognitive development... and actually the abstractions (zero-th order abstraction) capable of and exhibited by a 5 year old are used when in the activity called programming all the time... so much so we as adult programmers rarely think about them. I agree. People seem to define smart as something like things I can't do easily. So, for example, if they can use a keyboard, well someone like a child who can't must not be smart and this is why people were surprised when the mouse and graphical UIs allowed toddlers to use the Mac or touch screens allowed near infants to use iPads today. All along it was an issue of unnatural conceptual mapping (like asking a right handed person to throw with their left hand) that was the problem, not a lack of smarts. also, mouse or touch-screen are relatively direct-feedback, rather than requiring high-levels of abstract thought to work with. part of the problem may be that of preexisting knowledge... sometimes, knowledge can help people understand things easier; often, existing knowledge will lead to very nasty conceptual kludges. an example of the above I think is the ever-persistent file-cabinet metaphor: people very often portray things like files/... by making references back to this metaphor. the assumption (I guess) is that people will be more familiar with filing cabinets or find them more intuitive or similar. but, from the POV of someone who has never really used them for their intended purpose, or worked with piles of paper documents, the analogy doesn't really seem to work, as filing cabinets and filing systems really seem very much like unrelated concepts... at best, the terminology has been overloaded, and the new concept of file (a hierarchical tree of directories containing files each containing some number of bytes) has almost entirely subsumed the file-cabinet concept on which the original metaphor was based. in a sense, the metaphor no longer works, and should likely itself be left to fall into the recycle-bin of history. worse yet is having to read stuff written by people who actually take this metaphor seriously. granted, there are other annoying metaphors, but most others are not used nearly so offensively... a young child though will probably see things more how they are, and not likely build their thinking around metaphors which are borderline absurd: that a computer is a filing cabinet in an office residing on the surface of a giant desk for which a man in a robe will pop out just as soon as one pokes at it... (and where one is honestly expected to take advice from an anthropomorphic paper-clip...). yet, at the same time, it seems far more the case that society in general disregards people, and tries to force them into their particular mindset and worldview. one is not then really allowed to see the world as it is, but expected to deal with it in terms of layers of intellectual and ideological cruft. granted, maybe not everyone will come into the same reality, but maybe this is ok as well. it is a curious observation that so many people, living in essentially the same world and often from the same culture and geographic area, will come to have a number of different worldviews. (but, going more into this topic goes into some rather awkward issues...). From this perspective we could see the history of programming as one of finding ever more natural mappings between how our minds work and how we can get machines to do what we want - just as steering wheel and floor pedals map between our bodies and our vehicles. If so, which mappings are more natural and under which circumstances seems to be the important question and one, AFAICS, that may not well answered by simply replacing words with ideograms and expressions with boxes and arrows. agreed... I really don't believe graphical solutions are necessarily ideal. but, at the same time, there is also the matter of finding the right tool for the job. for example, code works great for expression program logic, but falls flat for many other tasks: creating a graphical image; creating a 3D model or scene; ... in these cases, having more specialized tools tends to be far more effective. for example, for editing a photo, one summons up a tool like GIMP. and, for making a 3D model, or working on its animations, one will generally summon up a dedicated 3D tool. picking the right sort of tool can notably reduce the effort required to complete a given task. in the above cases, a graphical tool is generally the best solution, but graphics are not best for all tasks either. a partial issue may then be battling a more subtle problem: it is very common
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
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?)
On 6/14/2011 9:50 PM, Dethe Elza wrote: 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. not much experience interacting with kids (don't have kids, never married, don't have a significant other either, as things just never seem to go anywhere...). but, yeah... being young, time seems to go by very slowly, and just sitting around fiddling with something, one accomplishes a lot of stuff in a relatively short period of time. as one gets older though, time goes by ever faster, and one can observe that less and less happens in a given period of time. then one sees many older people, and what one sees doesn't look all that promising. sadly, as is seemingly the case that a lot of potentially ones' potentially most productive years are squandered away doing things like schoolwork and similar, and by the time one generally gets done with all this, ones' mind has already become somewhat dulled due to age. it is like, me noting that several years ago, I was dealing with a personal-project codebase expansion of around +120 kloc/yr or so (and a few cases of breaking 1 kloc/day, usually in bursts), but more recently, my codebase has actually been shrinking (seemingly defying common sense...). granted, it is a question of how big of a codebase can be reasonably developed and maintained by a single developer though. also, maybe the underlying forces behind codebase expansion and shrinking, where positive effort and adding functionality doesn't necessarily always make ones' code get bigger, ... it leaves something to ponder. granted, at the time I was pulling off high output rates: I wrote an x86 assembler/linker, pulling off around 10 kloc in 3 days or something; when writing a C compiler, which turned out very large, and a bug-ridden mess; writing an x86 interpreter, which itself was like 40 kloc in around a 2 weeks or similar; ... granted, these sorts of efforts are relatively rare. scary would be if someone else could (actually) pull off consistent output at this rate (and emit code consistently at approx 1Mloc/yr...). and, meanwhile, recent output has been net negative... hmm... One problem is immersion. They learn language amazingly fast (in large part) because they are immersed in it constantly. Seymour Papert's book, Mindstorms is one of the best reads I've ever had about software, and he discusses creating worlds for math, physics, and other subjects on the computer so that children can be as immersed in those worlds as they are naturally in the world of language. That was one of the guiding ideas behind the creation of Logo. yes, but it is also notable that they learn language, being exposed to it in its full complexity. it is like, kids don't learn from a watered-down subset of the language, they just learn the language from hearing others use it. hence, a large portion of immersion may be more due to availability and them having a personal interest or reason. Some of the structural patterns that a small child already has at least some mastership of are connection, fitting, representation, indirection, context, mood, physical relationship. These are all used in simple programming. Perhaps they don't have the meta-words, but that's okay - that can come later at about 12 when they begin their next level of abstract cognitive development (ie proper abstract thought). My flatmate's 7 year old daughter is in the process of mastering addition, subtraction, multiplication and division. These things are quite abstract. My flatmate's THREE year old (!!) understands in a non-verbal way the idea of a pointer and mouse connection. Do you realise how advanced that idea is? Consider that he's only really begun to talk in sentences properly in the last 6 to 8 weeks. It's very simple in terms of our usage of computers, but it's an incredibly complex structural pattern, really... it's representation and indirection... you move this thing, and it represents this other thing, and we can use it to manipulate yet more things... of course the child doesn't realise that the things on the screen aren't real that they're simply further representations... but you get the gist... the capacity is there... and the ENERGY that
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
but, yeah... being young, time seems to go by very slowly, and just sitting around fiddling with something, one accomplishes a lot of stuff in a relatively short period of time. as one gets older though, time goes by ever faster, and one can observe that less and less happens in a given period of time. then one sees many older people, and what one sees doesn't look all that promising. sadly, as is seemingly the case that a lot of potentially ones' potentially most productive years are squandered away doing things like schoolwork and similar, and by the time one generally gets done with all this, ones' mind has already become somewhat dulled due to age. From the insights into how the human neocortex learns information gained from the research (not mine) in Hierarchical Temporal Memory (HTM) machine learning model, I would contest the idea that less happens in a give period of time as you get older. If you explore HTM, it illustrates that as inputs are generated, they are evaluated in the context of the predictions that the network is making at any given time. As a young person, the neocortex knows nothing, so all the predictions are most often wrong. When there is dissonance between prediction and input, a sort of *interrupt* happens ( which gives us awareness of time ) and learning of a new pattern eventually occurs. As we get older, less and less of the world becomes *novel*, so our neocortical predictions are more and more correct, generating less and less interrupts. One could argue that our perception of time is the number of these interrupts occurring in an interval of proper time. The concept of *flow* for example, when one loses track of time being fully immersed in a problem, could be simply the fact that you are so engaged and knowledgable in an area that your mind is able to successfully isolate itself from interrupt generating input and process information at peak efficiency. I would go even as far as saying that the productivity described in productive years is more of an exposure to novel input than actual productivity. Perhaps another way of stating what you're perceiving could be that you have more and more *friction* of learned patterns to overcome as you try to adapt to novel input as you get older. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Waterbear announcement (was Re: Age and Language (was Re: [fonc] Alternative Web programming models?))
On 2011-06-15, at 3:42 PM, Dale Schumacher wrote: On Wed, Jun 15, 2011 at 8:30 AM, Dethe Elza de...@livingcode.org wrote: In fact, I'm interested enough in the block structure visualization that I've been porting just the blocks, without the Scratch semantics and runtime, to the web. You can use scratch-like blocks to write and output any language, provided a language plugin. As a demonstration, I'm writing a language plugin for Javascript (plus Raphael, for graphics) and Martyn Eggleton is working on a plugin for writing Arduino code. It is still early days, very alpha, but if anyone is interested there is more here: https://github.com/dethe/waterbear/wiki [info] https://github.com/dethe/waterbear/ [code] https://waterbearlang.com/ [Javascript demo] http://stretch.deedah.org/waterbear/ [Arduino demo] I've been meaning to share this with the group here, but wanting to get it roughed in a bit more, but here it is in all its half-baked glory. Feedback highly appreciated. --Dethe Very cool project. I'd like to see how easy it would be to use it for Humus programs. Thanks! I don't know how easy it would be to use with Humus, but I'd be happy to help explore it and find out. I'm just finishing up a couple of side projects so I can devote all my hobby coding time to Waterbear. One big refactoring is going to be control of (most of) the UI from a language plugin, and multiple language plugins supported from the same version (right now they are separate forks). --Dethe ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Waterbear announcement (was Re: Age and Language (was Re: [fonc] Alternative Web programming models?))
I like it. My son is very keen on Scratch (although he prefers Lua these days), but we picked up an Arduino kit last month, and I'm looking forward to playing with that. His eyes kind of glazed over looking at the C code, as simple as it is for Arduino. I got the impression he was just happy to have dad perform magic tricks for him :-) Cheers, Steve On Wed, Jun 15, 2011 at 3:49 PM, Dethe Elza de...@livingcode.org wrote: On 2011-06-15, at 3:42 PM, Dale Schumacher wrote: On Wed, Jun 15, 2011 at 8:30 AM, Dethe Elza de...@livingcode.org wrote: In fact, I'm interested enough in the block structure visualization that I've been porting just the blocks, without the Scratch semantics and runtime, to the web. You can use scratch-like blocks to write and output any language, provided a language plugin. As a demonstration, I'm writing a language plugin for Javascript (plus Raphael, for graphics) and Martyn Eggleton is working on a plugin for writing Arduino code. It is still early days, very alpha, but if anyone is interested there is more here: https://github.com/dethe/waterbear/wiki [info] https://github.com/dethe/waterbear/ [code] https://waterbearlang.com/ [Javascript demo] http://stretch.deedah.org/waterbear/ [Arduino demo] I've been meaning to share this with the group here, but wanting to get it roughed in a bit more, but here it is in all its half-baked glory. Feedback highly appreciated. --Dethe Very cool project. I'd like to see how easy it would be to use it for Humus programs. Thanks! I don't know how easy it would be to use with Humus, but I'd be happy to help explore it and find out. I'm just finishing up a couple of side projects so I can devote all my hobby coding time to Waterbear. One big refactoring is going to be control of (most of) the UI from a language plugin, and multiple language plugins supported from the same version (right now they are separate forks). --Dethe ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Waterbear announcement (was Re: Age and Language (was Re: [fonc] Alternative Web programming models?))
On Wed, Jun 15, 2011 at 8:16 PM, Dethe Elza de...@livingcode.org wrote: Glad you like it. How old is your son? Maybe we should organize a Vancouver Geek Kids, or meet up at Maker Faire next week. Or there is this: http://www.tedxkidsbc.com/ TEDx kids looks wonderful - thanks for that link. A Geek Kids meetup would be very popular; he's 13 and his sister is 12. They're up in Vancouver for the Summer, but unfortunately I'll be in San Jose with only a couple of very short trips back. We took them to the Maker's Faire in San Mateo last month and they were thrilled, especially with the hands-on labs, but it was too much to cover with the intense crowds and we missed a lot. The mini Faire should be a lot more manageable. I'll pass on that info and hopefully we can get them to go. I'm working to get the Arduino code merged in with the main fork. Also looking at options for wrapping the webapp in a native shell using Appcelerator Titanium or Mozilla Chromeless so we can access the serial port from Javascript. I'll have a look at the code this weekend. Other than a somewhat obsessive use of Minecraft as social media, things are quiet here :) Cheers, Steve ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: 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: Age and Language (was Re: [fonc] Alternative Web programming models?)
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: Age and Language (was Re: [fonc] Alternative Web programming models?)
I wonder if a thousand years ago the readers of the world thought that only certain people had an aptitude for reading. = As a professional coder and father of young children I find Dethe's anecdote of teaching his children to code/program at an early age has me thinking I need to take another stab at showing Scratch again to my children. On Tue, Jun 14, 2011 at 4:09 PM, Dethe Elza de...@livingcode.org wrote: On 2011-06-14, at 12:33 PM, BGB wrote: much younger, and it is doubtful people can do much of anything useful. can you teach programming to a kindergartner?... maybe not such a good idea, so, it is an issue for what a good lower-limit is for where to try. My kids learned to program around kindergarten/first grade. My son started with Scratch when he was six and is now teaching himself Javascript/Raphael and HTML/CSS at age 10. One advantage graphic tools like Scratch have for younger learners is that they don't have to know how to type, just read and write. Having the syntax enforced by the structure of the blocks helps too (no typos, no syntax errors, in addition to the aforementioned enforced strong typing). --Dethe ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
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?)
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?)
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
