Re: [fonc] Alternative Web programming models?
On 12/06/2011, at 1:00 PM, BGB wrote: image-based systems have their own sets of drawbacks though... dynamic reload could be a good enough compromise IMO, if done well... I don't follow this train of thought. Everything runs in an image. That's to say, the source code directly relates to some piece of running code in the system at some point. Smalltalk, Self and the like simply let you interact with the running code in the same place as the artefacts that create the running code. It's akin to programming in a debugger that saves the contents of memory constantly as the source. As it's 2011, surely we can come to a point where we can synthesise these two apparently orthogonal concerns? I think the main issue with smalltalk-like image systems is that the system doesn't as easily let you start from blank like text-file source-code style coding does... thats to say, yes, it's possible to start new worlds, but it's not very easy to reference bits of your worlds from each other... and essentially, that's what text-file coding (ie editing offline code) does for us... because things are in files, it's easy to include a file as one packaged unit, or a group of file, or a package... and then that package can be referred to... separately, and even maintained by someone else, and it's not a COPY of the package, it's a reference to it... you know? This is incredibly powerful. The equivalent in a smalltalk system would need to be some kind of amazing version control system that can version worlds at certain points, and package code in a recursive encapsulation process. Having a global namespace is kind of retarded... because context is everything... ... that's to say, when and as context yields meaning (as I believe it does from my fairly deep ponderings), no token that yields meaning in a given context holds its meaning when decontextualised in the same way, therefore names (as these tokens) are deeply important IN CONTEXT. What kind of relevance, therefore, has a global namespace got? Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On 6/13/2011 1:33 AM, Julian Leviston wrote: On 12/06/2011, at 1:00 PM, BGB wrote: image-based systems have their own sets of drawbacks though... dynamic reload could be a good enough compromise IMO, if done well... I don't follow this train of thought. Everything runs in an image. That's to say, the source code directly relates to some piece of running code in the system at some point. Smalltalk, Self and the like simply let you interact with the running code in the same place as the artefacts that create the running code. It's akin to programming in a debugger that saves the contents of memory constantly as the source. except, that traditional source-files have a concrete representation as so many files, and, beyond these files, there is nothing really of relevance (at least, conceptually, a person could print a program to paper, re-type it somewhere else, and expect the result to work). does it rebuild from source? does the rebuilt program work on the target systems of interest? if so, then everything is good. an image based system, OTOH, often means having to drag around the image instead, which may include a bunch of other stuff beyond just the raw text of the program, and may couple the program and the particular development environment used to create it. this coupling may be somewhat undesirable, and it is preferable to have the source as files, so then one can rebuild from source whenever this is needed. also, another risk is of the development image becoming polluted as a result of prior actions or code, which may risk compromising a project. granted, the one major drawback of traditional files-based development is its traditional dependency on the edit/compile/run cycle. scripting languages can often make this cycle a little faster, but don't necessarily eliminate it. however, dynamic reload can stay with using plain text files (thus allowing restarting clean if/when needed), and preserving familiar aspects of the coding process (namely, having ones' code organized into a tree of source files), but allows some of the merits of live-system coding, such as the ability to quickly load their changes back into the app, without having to exit and restart the program... in this case, the currently running program image is partially malleable, and so is subject to hot-patching (within sane limits), so changes to the source can be reflected more immediately (no app restart). however, unlike full image-based development, the app will generally forget everything that was going on once it is exited and restarted. by analogy, it is like running programs in Windows: one can open/close/run programs, edit things, ... in Windows, and so long as it is running, it will remember all this; but, if/when Windows is rebooted, it will forget, and one starts again with a clean slate of sorts (an empty desktop with only their icons and start-up programs to greet them...). but, the merit of rebooting Windows is that it keeps the system clean, as running Windows continuously is prone to cause it to degrade over time, and without an occasional reboot will begin to manifest lots of buggy behavior and eventually crash (IME, much worse in Vista and Win7 than in XP...). As it's 2011, surely we can come to a point where we can synthesise these two apparently orthogonal concerns? I think the main issue with smalltalk-like image systems is that the system doesn't as easily let you start from blank like text-file source-code style coding does... thats to say, yes, it's possible to start new worlds, but it's not very easy to reference bits of your worlds from each other... yes. for many types of project though, this is a potential deal-breaker. another part of the matter may be that of dealing with different libraries being updated independently by different developers. I am not certain how well either image-based development would map to traditional team-based development practices (say, where 5 or 10 people are assigned to work on a particular component, and 5 or 10 others working mostly independently are assigned to an adjacent component, ...). granted, I may be wrong here, as I haven't done a whole lot of development with image-based systems. and essentially, that's what text-file coding (ie editing offline code) does for us... because things are in files, it's easy to include a file as one packaged unit, or a group of file, or a package... and then that package can be referred to... separately, and even maintained by someone else, and it's not a COPY of the package, it's a reference to it... you know? This is incredibly powerful. yep. I am generally mostly in favor of using files. The equivalent in a smalltalk system would need to be some kind of amazing version control system that can version worlds at certain points, and package code in a recursive encapsulation process. Having a global namespace is kind of retarded...
Re: [fonc] Alternative Web programming models?
On 13/06/2011, at 7:50 PM, BGB wrote: On 6/13/2011 1:33 AM, Julian Leviston wrote: On 12/06/2011, at 1:00 PM, BGB wrote: image-based systems have their own sets of drawbacks though... dynamic reload could be a good enough compromise IMO, if done well... I don't follow this train of thought. Everything runs in an image. That's to say, the source code directly relates to some piece of running code in the system at some point. Smalltalk, Self and the like simply let you interact with the running code in the same place as the artefacts that create the running code. It's akin to programming in a debugger that saves the contents of memory constantly as the source. except, that traditional source-files have a concrete representation as so many files, and, beyond these files, there is nothing really of relevance (at least, conceptually, a person could print a program to paper, re-type it somewhere else, and expect the result to work). does it rebuild from source? does the rebuilt program work on the target systems of interest? if so, then everything is good. an image based system, OTOH, often means having to drag around the image instead, which may include a bunch of other stuff beyond just the raw text of the program, and may couple the program and the particular development environment used to create it. [SNIP] or such... This brings up an interesting point for me. Source is an interesting word, isn't it? :) Source of what, exactly? Intention, right? The real code is surely the electricity inside the computer in its various configurations which represent numbers in binary. This is not textual streams, it's binary numbers. The representation is the interesting thing as are the abstractions that we derive from them. I don't think computer programs being represented as text is very appropriate, useful or even interesting. in fact, I'd suffice to say that it's a definite hate/love relationship. I *love* typography, text and typing, but this has little or naught to do with programming. Programming is simply done in this way by me at the moment, begrudgingly because I have nothing better yet. Consider what it'd be like if we didn't represent code as text... and represented it maybe as series of ideograms or icons (TileScript nod). Syntax errors don't really crop up any more, do they? Given a slightly nicer User Interface than tilescript, you could still type your code, (ie use the keyboard to fast-select tokens), but the computer won't validate any input that isn't in its dictionary of known possible syntactically correct items given whatever context you're in. By the way, SmallTalk and Self are perfectly representable in textual forms... (file out nod) just like JVM bytecode is perfectly representable in textual form, or assembler... but text probably isn't the most useful way to interact with these things... just as to edit your text you most likely use some form of IDE (and yes, I'd class VIM or EMACS as an IDE). Do I need to represent here just how idiotic I think compilation is as a process? It's a series of text stream processors that aim at building an artefact that has little or nothing to do with a world that exists entirely in text. TEXT!!! It's a bad way to represent the internal world of computers, in my opinion. It'd be nice to use a system which represents things a few layers closer to what's actually going on, and surely the FoNC project is aimed at a pedagogical direction intending to strip away layers of cruft between the image inside the head of a user ( or programmer) that they have representing how it works, and how it actually works... Mind you, I think human language is fairly silly, too... we communicate using mental bubbles of non-language based patterns, rendered into language, formed into text. It's well retarded... but this might be considered a little out there, so I'll end here. If I'm providing too much noise for the list, please anyone, let me know, and I'll be quiet. Julian.___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
Am 13.06.2011 11:50, schrieb BGB: an image based system, OTOH, often means having to drag around the image instead, which may include a bunch of other stuff beyond just the raw text of the program, and may couple the program and the particular development environment used to create it. this coupling may be somewhat undesirable, and it is preferable to have the source as files, so then one can rebuild from source whenever this is needed. also, another risk is of the development image becoming polluted as a result of prior actions or code, which may risk compromising a project. Just some quick comments from a long-time Smalltalker (25 years): Of course rebuilding from source is desirable at certain points in time. For example, in the project I'm currently working on, every production build is created from a clean image into which the application's source code is loaded. This is a single-click process, just like building a traditional program from source files (except that we use VAST, where the source code is held in an ENVY repository for version and configuration control instead of plain files). However, in the development process we rarely rebuild images from scratch. It's not that we depend on image artefacts created long ago, but we prefer to keep our personal selection of tools and debugging aids. Using ENVY, it's very simple to sync our actual application source with the newest version while keeping all the tools intact. I normally rebuild my development image only when we switch to a completely new base software version, or when I've accidentally damaged it to a point where self-repair is not possible anymore (extremely rare, I've done that maybe 3-4 times during the project's lifetime of about 12 years). So, the risk associated with image-based development is mostly a theoretical one. In practice, it can be controlled just as well as with file-based development, and you get all the advantages of the image on top :-) Cheers, Hans-Martin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On Mon, Jun 13, 2011 at 4:50 AM, BGB cr88...@gmail.com wrote: however, unlike full image-based development, the app will generally forget everything that was going on once it is exited and restarted. I think this is one of the most annoying features of our current computer systems. If I have a project (or 10 or 20 projects) spread out on my workbench, and I leave to have something to eat, or go to sleep, when I return everything is still (more or less) in the state I left it. by analogy, it is like running programs in Windows: one can open/close/run programs, edit things, ... in Windows, and so long as it is running, it will remember all this; but, if/when Windows is rebooted, it will forget, and one starts again with a clean slate of sorts (an empty desktop with only their icons and start-up programs to greet them...). but, the merit of rebooting Windows is that it keeps the system clean, as running Windows continuously is prone to cause it to degrade over time, and without an occasional reboot will begin to manifest lots of buggy behavior and eventually crash (IME, much worse in Vista and Win7 than in XP...). Long-running stability and continuous upgrading (WITHOUT rebooting) should be the norm. There should be no such thing as a boot process. A system should remain stable (and running) throughout a lifetime of gradual evolution/mutation. Of course, we also need a way to branch/fork/clone/version and even start-from-embryo, to build new systems. The next step is to consider how the system (or parts of it) can migrate, or become mobile, among hosts. and essentially, that's what text-file coding (ie editing offline code) does for us... because things are in files, it's easy to include a file as one packaged unit, or a group of file, or a package... and then that package can be referred to... separately, and even maintained by someone else, and it's not a COPY of the package, it's a reference to it... you know? This is incredibly powerful. yep. I am generally mostly in favor of using files. Naming is certainly important, as is contextual reference, but I'm not convinced that files are a necessary part of providing that mechanism. Consider, as a possible alternative, the idea of parametrizing a module with its dependencies. This is just the principle of applying abstractions to allow local naming (aliasing) of externally provided objects. my_module(something_i_need, ...) = ... module specification using something_i_need ... create my_module(provider_of_service, ...) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On Monday 13 Jun 2011 2:03:29 PM Julian Leviston wrote: I think the main issue with smalltalk-like image systems is that the system doesn't as easily let you start from blank like text-file source-code style coding does... thats to say, yes, it's possible to start new worlds, but it's not very easy to reference bits of your worlds from each other... The pre-req for this is a tool to diff two images to generate a delta that can be applied to one to produce another. This is easy to do with line-oriented text files or non-linear xml files but difficult to do with blobs like images. Tools like xdelta operate only at bit level and not object level. Of course, if there was a (normalized) way to transcode .image into .xml and vice versa then xmldiff can be used for that purpose. Subbu ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On 14/06/2011, at 1:17 AM, Alan Kay wrote: It would be great if everyone on this list would think deeply about how to have an eternal system, and only be amplified by it. Hi Alan, You might need to elucidate a little more on this for me to personally understand you. Not sure how others feel, but the Worlds work seems to be just a description of a versioning pattern applied to running program state. Why is it especially interesting? In the Ruby community, we have gem which is a package manager and also bundler, the two of which handle dependency management and sets of bundles of dependencies in context and situ elegantly and beautifully. Depending on your requirements when writing code, you can point to a version of a gem, the latest version, or say things like versions greater than 2.3. It works really well. It also fits very neatly with your idea of (Alexander's? ;-)) the arch and biological cellular structure being a scalable system: this system is working in practice extremely well. (Mind you, there's a global namespace, so it will eventually get crowded I'm sure ;-)) What do you mean by an eternal system? Do you mean a system which lasts forever? and what do you mean by amplified? Do you mean amplified as in our energy around this topic, or something else? Sorry for not understanding you straight away, Regards, Julian.___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On Jun 13, 2011, at 9:35 AM, Julian Leviston wrote: On 14/06/2011, at 1:17 AM, Alan Kay wrote: It would be great if everyone on this list would think deeply about how to have an eternal system, and only be amplified by it. Hi Alan, You might need to elucidate a little more on this for me to personally understand you. Not sure how others feel, but the Worlds work seems to be just a description of a versioning pattern applied to running program state. It seems like much more than that to me. Why is it especially interesting? In the Ruby community, we have gem which is a package manager and also bundler, the two of which handle dependency management and sets of bundles of dependencies in context and situ elegantly and beautifully. Depending on your requirements when writing code, you can point to a version of a gem, the latest version, or say things like versions greater than 2.3. It works really well. It also fits very neatly with your idea of (Alexander's? ;-)) the arch and biological cellular structure being a scalable system: this system is working in practice extremely well. (Mind you, there's a global namespace, so it will eventually get crowded I'm sure ;-)) Consider that in a Squeak image, the compiled methods are reified as objects. With Worlds, you can make exploratory changes to code in a *complex running system*, and then back out effortlessly if it doesn't work. You just throw away the World containing the modified code as well as the objects that were modified as a side-effect of running the modified code. What do you mean by an eternal system? Do you mean a system which lasts forever? Yes, I believe that's what Alan means. One things that Worlds do are fill in a gap that prevents Smalltalk-80 from being an eternal system. The problem with Smalltalk is that, although it is is possible to make code changes in a running image, it is also possible to easily trash the image by making the wrong code changes. Furthermore, the more complicated the system that you're building, the easier it is to trash the image. To successfully build complex systems in Smalltalk, the typical approach is to periodically bootstrap the system by loading code into a fresh image, and running initialization scripts to bring the image up to a start-state. We employed this approach at Qwaq/Teleplace. Worlds provides a way (or at least points in a direction) to never need to shut down the running system. Any changes made to the system can safely and easily be reverted. I don't know how familiar you are with Croquet, but when I consider this capability in the context of replicated Islands of objects (including code), I find the potential to be breathtaking. and what do you mean by amplified? Do you mean amplified as in our energy around this topic, or something else? I'm not sure that I understood this, either. Cheers, Josh Sorry for not understanding you straight away, Regards, Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
Amplification: if I wagered a guess, I'd go with of human reach or of potential leverage. I also have one amp that goes up to 11, which is really nice because sometimes I like a touch of extra kick for the solo. On Jun 13, 2011, at 9:35 AM, Julian Leviston jul...@leviston.net wrote: On 14/06/2011, at 1:17 AM, Alan Kay wrote: It would be great if everyone on this list would think deeply about how to have an eternal system, and only be amplified by it. Hi Alan, You might need to elucidate a little more on this for me to personally understand you. Not sure how others feel, but the Worlds work seems to be just a description of a versioning pattern applied to running program state. Why is it especially interesting? In the Ruby community, we have gem which is a package manager and also bundler, the two of which handle dependency management and sets of bundles of dependencies in context and situ elegantly and beautifully. Depending on your requirements when writing code, you can point to a version of a gem, the latest version, or say things like versions greater than 2.3. It works really well. It also fits very neatly with your idea of (Alexander's? ;-)) the arch and biological cellular structure being a scalable system: this system is working in practice extremely well. (Mind you, there's a global namespace, so it will eventually get crowded I'm sure ;-)) What do you mean by an eternal system? Do you mean a system which lasts forever? and what do you mean by amplified? Do you mean amplified as in our energy around this topic, or something else? Sorry for not understanding you straight away, Regards, Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On 14/06/2011, at 4:07 AM, Josh Gargus wrote: On Jun 13, 2011, at 9:35 AM, Julian Leviston wrote: On 14/06/2011, at 1:17 AM, Alan Kay wrote: It would be great if everyone on this list would think deeply about how to have an eternal system, and only be amplified by it. Hi Alan, You might need to elucidate a little more on this for me to personally understand you. Not sure how others feel, but the Worlds work seems to be just a description of a versioning pattern applied to running program state. It seems like much more than that to me. Cool :) I'm not saying it doesn't have interesting ramifications ;-) Why is it especially interesting? In the Ruby community, we have gem which is a package manager and also bundler, the two of which handle dependency management and sets of bundles of dependencies in context and situ elegantly and beautifully. Depending on your requirements when writing code, you can point to a version of a gem, the latest version, or say things like versions greater than 2.3. It works really well. It also fits very neatly with your idea of (Alexander's? ;-)) the arch and biological cellular structure being a scalable system: this system is working in practice extremely well. (Mind you, there's a global namespace, so it will eventually get crowded I'm sure ;-)) Consider that in a Squeak image, the compiled methods are reified as objects. With Worlds, you can make exploratory changes to code in a *complex running system*, and then back out effortlessly if it doesn't work. You just throw away the World containing the modified code as well as the objects that were modified as a side-effect of running the modified code. Yes, I've considered this. One of the things that crops up, though, is what about data? That is to say, what if one of the world experimentations one ends up doing involves experimenting with modifying some of the model of a particular piece of code... and this necessarily involve mutating a data type (ie model parent object or class implementation)... how does the idea/system apply to this, especially when considering things from the point of view of concurrent simultaneous users... where one person may mutate the state in the discussed manner, but another person is using a different world (a previous one with a different data structure in place)... yet they both still need to use the same data (ie imagine an address book application where one person is mutating the model layer live, and both people are using it live and inputting new data)... ... the idea of published / unpublished (ie published being a particular world that is being pointed to as the current live one) seems to serve well here. ... also, the idea of modelling change ITSELF is an appealing one in this context, and all changes including data entry etc being simply represented as a log of mutations using the command pattern. Thus the data represented in the first world would be mutated and propagated to the new world (actually more like the view of it filtered or some-such) according to the new rules, and the inverse would apply as well... ... of course, the question of irreversible transactions (ie destructive or creationist commands) arises... what to do about when adding or destroying structure inside a data structure when involving those worlds? (in other words, the second, experimental world perhaps has added a title field to a person, and then the second world user adds a new person, with the title field... what does the first world user see?, etc. This is a superficially simple illustration - add some code to the second world which would break if things aren't set up in a particular structure, such as a requirement on the title for a person, and then the first world entry not actually having a title, and we get a bit stickier - this particular example falls apart rather easily, but you get the gist, hopefully?) The worlds idea seems to ignore the fact that the only way to really get the feel for something is to use it... so an experiment (ie a child world) would need to be using real, live data... so a user or programmer would end up with the painful situation of having to migrate their created application objects - the data - back into the parent world but not migrate the code back if the experiment failed... *or* they would have to treat the experimental world as experimental only and not real, but doing this wouldn't actually allow one to know whether the experiment was working or not... *or* they'd have to use two worlds simultaneously - the first, un-experimental world to just use their application, and the second world to test things out until they were happy that it would work as they anticipated (ie the experiment worked). Either way, it could bear more thinking... Julian. ___ fonc mailing list fonc@vpri.org
Re: [fonc] Alternative Web programming models?
I wrote this without reading the very latest http://www.vpri.org/pdf/tr2011001_final_worlds.pdf so if I say anything that is obviously missing that understanding, please bear with me :) I'll read it shortly. Julian. On 14/06/2011, at 5:26 AM, Julian Leviston wrote: On 14/06/2011, at 4:07 AM, Josh Gargus wrote: On Jun 13, 2011, at 9:35 AM, Julian Leviston wrote: On 14/06/2011, at 1:17 AM, Alan Kay wrote: It would be great if everyone on this list would think deeply about how to have an eternal system, and only be amplified by it. Hi Alan, You might need to elucidate a little more on this for me to personally understand you. Not sure how others feel, but the Worlds work seems to be just a description of a versioning pattern applied to running program state. It seems like much more than that to me. Cool :) I'm not saying it doesn't have interesting ramifications ;-) Why is it especially interesting? In the Ruby community, we have gem which is a package manager and also bundler, the two of which handle dependency management and sets of bundles of dependencies in context and situ elegantly and beautifully. Depending on your requirements when writing code, you can point to a version of a gem, the latest version, or say things like versions greater than 2.3. It works really well. It also fits very neatly with your idea of (Alexander's? ;-)) the arch and biological cellular structure being a scalable system: this system is working in practice extremely well. (Mind you, there's a global namespace, so it will eventually get crowded I'm sure ;-)) Consider that in a Squeak image, the compiled methods are reified as objects. With Worlds, you can make exploratory changes to code in a *complex running system*, and then back out effortlessly if it doesn't work. You just throw away the World containing the modified code as well as the objects that were modified as a side-effect of running the modified code. Yes, I've considered this. One of the things that crops up, though, is what about data? That is to say, what if one of the world experimentations one ends up doing involves experimenting with modifying some of the model of a particular piece of code... and this necessarily involve mutating a data type (ie model parent object or class implementation)... how does the idea/system apply to this, especially when considering things from the point of view of concurrent simultaneous users... where one person may mutate the state in the discussed manner, but another person is using a different world (a previous one with a different data structure in place)... yet they both still need to use the same data (ie imagine an address book application where one person is mutating the model layer live, and both people are using it live and inputting new data)... ... the idea of published / unpublished (ie published being a particular world that is being pointed to as the current live one) seems to serve well here. ... also, the idea of modelling change ITSELF is an appealing one in this context, and all changes including data entry etc being simply represented as a log of mutations using the command pattern. Thus the data represented in the first world would be mutated and propagated to the new world (actually more like the view of it filtered or some-such) according to the new rules, and the inverse would apply as well... ... of course, the question of irreversible transactions (ie destructive or creationist commands) arises... what to do about when adding or destroying structure inside a data structure when involving those worlds? (in other words, the second, experimental world perhaps has added a title field to a person, and then the second world user adds a new person, with the title field... what does the first world user see?, etc. This is a superficially simple illustration - add some code to the second world which would break if things aren't set up in a particular structure, such as a requirement on the title for a person, and then the first world entry not actually having a title, and we get a bit stickier - this particular example falls apart rather easily, but you get the gist, hopefully?) The worlds idea seems to ignore the fact that the only way to really get the feel for something is to use it... so an experiment (ie a child world) would need to be using real, live data... so a user or programmer would end up with the painful situation of having to migrate their created application objects - the data - back into the parent world but not migrate the code back if the experiment failed... *or* they would have to treat the experimental world as experimental only and not real, but doing this wouldn't actually allow one to know whether the experiment was working or not... *or* they'd have to use two worlds simultaneously - the first, un-experimental world
Re: [fonc] Alternative Web programming models?
On Mon, Jun 13, 2011 at 9:31 PM, Julian Leviston jul...@leviston.netwrote: I wrote this without reading the very latest http://www.vpri.org/pdf/tr2011001_final_worlds.pdf so if I say anything that is obviously missing that understanding, please bear with me :) I'll read it shortly. I got wondering about commit failure and cases where you needed certain objects in the world child anyway. Or two different worlds merging. Will that be possible ? NB! A link in document http://www.vpri.org/pdf/tr2011001_final_worlds.pdf didnt work http://www.tinlizzie.org/%CB%9Cawarth/worlds this works http://www.tinlizzie.org/~awarth/worlds/ Karl Julian. On 14/06/2011, at 5:26 AM, Julian Leviston wrote: On 14/06/2011, at 4:07 AM, Josh Gargus wrote: On Jun 13, 2011, at 9:35 AM, Julian Leviston wrote: On 14/06/2011, at 1:17 AM, Alan Kay wrote: It would be great if everyone on this list would think deeply about how to have an eternal system, and only be amplified by it. Hi Alan, You might need to elucidate a little more on this for me to personally understand you. Not sure how others feel, but the Worlds work seems to be just a description of a versioning pattern applied to running program state. It seems like much more than that to me. Cool :) I'm not saying it doesn't have interesting ramifications ;-) Why is it especially interesting? In the Ruby community, we have gem which is a package manager and also bundler, the two of which handle dependency management and sets of bundles of dependencies in context and situ elegantly and beautifully. Depending on your requirements when writing code, you can point to a version of a gem, the latest version, or say things like versions greater than 2.3. It works really well. It also fits very neatly with your idea of (Alexander's? ;-)) the arch and biological cellular structure being a scalable system: this system is working in practice extremely well. (Mind you, there's a global namespace, so it will eventually get crowded I'm sure ;-)) Consider that in a Squeak image, the compiled methods are reified as objects. With Worlds, you can make exploratory changes to code in a *complex running system*, and then back out effortlessly if it doesn't work. You just throw away the World containing the modified code as well as the objects that were modified as a side-effect of running the modified code. Yes, I've considered this. One of the things that crops up, though, is what about data? That is to say, what if one of the world experimentations one ends up doing involves experimenting with modifying some of the model of a particular piece of code... and this necessarily involve mutating a data type (ie model parent object or class implementation)... how does the idea/system apply to this, especially when considering things from the point of view of concurrent simultaneous users... where one person may mutate the state in the discussed manner, but another person is using a different world (a previous one with a different data structure in place)... yet they both still need to use the same data (ie imagine an address book application where one person is mutating the model layer live, and both people are using it live and inputting new data)... ... the idea of published / unpublished (ie published being a particular world that is being pointed to as the current live one) seems to serve well here. ... also, the idea of modelling change ITSELF is an appealing one in this context, and all changes including data entry etc being simply represented as a log of mutations using the command pattern. Thus the data represented in the first world would be mutated and propagated to the new world (actually more like the view of it filtered or some-such) according to the new rules, and the inverse would apply as well... ... of course, the question of irreversible transactions (ie destructive or creationist commands) arises... what to do about when adding or destroying structure inside a data structure when involving those worlds? (in other words, the second, experimental world perhaps has added a title field to a person, and then the second world user adds a new person, with the title field... what does the first world user see?, etc. This is a superficially simple illustration - add some code to the second world which would break if things aren't set up in a particular structure, such as a requirement on the title for a person, and then the first world entry not actually having a title, and we get a bit stickier - this particular example falls apart rather easily, but you get the gist, hopefully?) The worlds idea seems to ignore the fact that the only way to really get the feel for something is to use it... so an experiment (ie a child world) would need to be using real, live data... so a user or programmer would end up with the painful situation of having to migrate their created application objects - the data
Re: Persistence and the Great Horse Trade (was Re: [fonc] Alternative Web programming models?)
On Mon, Jun 13, 2011 at 2:21 PM, Casey Ransberger casey.obrie...@gmail.com wrote: Comments below. On Jun 13, 2011, at 6:00 AM, Dale Schumacher dale.schumac...@gmail.com wrote: On Mon, Jun 13, 2011 at 4:50 AM, BGB cr88...@gmail.com wrote: however, unlike full image-based development, the app will generally forget everything that was going on once it is exited and restarted. I think this is one of the most annoying features of our current computer systems. If I have a project (or 10 or 20 projects) spread out on my workbench, and I leave to have something to eat, or go to sleep, when I return everything is still (more or less) in the state I left it. Dale, when read this it wasn't clear to me what you meant to convey. Are you saying it's annoying that when I come back to my bench, I have to swim all the way back to the context I was in before or are you saying when I return to my bench, it's annoying to have to close all of that stuff because what I usually want is a new context anyway? I'm most definitely saying that I prefer the eternal (as Alan said) system, with persistent state. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On 6/13/2011 3:19 AM, Julian Leviston wrote: On 13/06/2011, at 7:50 PM, BGB wrote: On 6/13/2011 1:33 AM, Julian Leviston wrote: On 12/06/2011, at 1:00 PM, BGB wrote: image-based systems have their own sets of drawbacks though... dynamic reload could be a good enough compromise IMO, if done well... I don't follow this train of thought. Everything runs in an image. That's to say, the source code directly relates to some piece of running code in the system at some point. Smalltalk, Self and the like simply let you interact with the running code in the same place as the artefacts that create the running code. It's akin to programming in a debugger that saves the contents of memory constantly as the source. except, that traditional source-files have a concrete representation as so many files, and, beyond these files, there is nothing really of relevance (at least, conceptually, a person could print a program to paper, re-type it somewhere else, and expect the result to work). does it rebuild from source? does the rebuilt program work on the target systems of interest? if so, then everything is good. an image based system, OTOH, often means having to drag around the image instead, which may include a bunch of other stuff beyond just the raw text of the program, and may couple the program and the particular development environment used to create it. [SNIP] or such... This brings up an interesting point for me. Source is an interesting word, isn't it? :) Source of what, exactly? Intention, right? The real code is surely the electricity inside the computer in its various configurations which represent numbers in binary. This is not textual streams, it's binary numbers. The representation is the interesting thing as are the abstractions that we derive from them. yes, but as a general rule, this is irrelevant... the OS is responsible for keeping the filesystem intact, and generally does a good enough job, and there one can backups and hard-copies in-case things don't work out (say, a good hard crash, and the OS goes and mince-meats the filesystem...). as far as the user/developer can be concerned, it is all text. more so, it is all ASCII text, given some of the inherent drawbacks of using non-ASCII characters in ones' code... I don't think computer programs being represented as text is very appropriate, useful or even interesting. in fact, I'd suffice to say that it's a definite hate/love relationship. I *love* typography, text and typing, but this has little or naught to do with programming. Programming is simply done in this way by me at the moment, begrudgingly because I have nothing better yet. well, the issue is of course, that there is nothing obviously better. Consider what it'd be like if we didn't represent code as text... and represented it maybe as series of ideograms or icons (TileScript nod). Syntax errors don't really crop up any more, do they? Given a slightly nicer User Interface than tilescript, you could still type your code, (ie use the keyboard to fast-select tokens), but the computer won't validate any input that isn't in its dictionary of known possible syntactically correct items given whatever context you're in. but, what would be the gain?... the major issue with most possible graphical representations, is that they are far less compact. hence, the common use of graphical presentations to represent a small amount in information in a compelling way (say, a bar-chart or line-graph which represents only a small number of data-points). apparently, even despite this, some people believe in things like UML diagrams, but given the time and effort required to produce them, combined with their exceedingly low informational density, and I don't really see the point. also, for most programming tasks, graphical presentation would not offer any real notable advantage over a textual representation. at best, one has a pictographic system with a person new to the system trying to figure out just what the hell all of these intuitive icons mean and do. at that rate, one may almost as well just go make a programming language based on the Chinese writing system. given that most non-Chinese can't read Chinese writing, despite that many of these characters do actually resemble crude line-art drawings of various things and ideas. and meanwhile, many Asian countries either have shifted to, or are in the process of shifting to, the use of phonetic writing systems (Koreans created Hangul, Kanji gradually erodes in favor of Hiragana, ...). even in some places in China (such as Canton) the traditional writing system is degrading, with many elements of their spoken dialect being incorporated into the written language. this could be taken as an indication that their may be some fundamental flaw with pictographic or ideographic systems. or, more directly: many people new to icons-only GUI designs spend some
Re: [fonc] Logo and Silicon
Inline and abridged. On Jun 13, 2011, at 1:03 PM, Jecel Assumpcao Jr. je...@merlintec.com wrote: Have you looked at the ALUs that kids have been making in Minecraft? You can _walk around_ in there. Inside the simulated microprocessor, and actually watch the electrons walk down the Redstone wire. And when you want the birds-eye, a simple server mod lets you fly way up and look down. I watched some movies of this and while very neat, it has some of the limitations of Visual6502. If I had actually played with it and had been able to choose what to look at, it might have been more undestandable. I'm not sure what they let you do with Minecraft currently without paying for it (it's pretty cheap anyway) but I know that at one point you could play single player for free, which is all you need. I ended up thinking it was the best creative game I'd seen since SimCity, so I just went ahead and bought it. Fortunately you pay once and you're done, which I think is a very respectable business model in today's age. You can fly around in maps and modify them, but not *run* them, using the map editor here: http://davidvierra.com/mcedit.html The Elements of Computing Systems seems to have influenced the Minecraft creative community -- I haven't read it myself. It kind of blows my mind that people have to patience to do computational stuff in-between letting fly arrows at Creepers (I hate those things.) You can get schematic data for various Redstone (read: cellular automata) projects here: http://www.mcschematics.com/index.php?board=79.0 It's worth noting that the default texture pack is not well suited to viewing this stuff. I ended up making my own. I hope this isn't too far off-topic, but I'm fascinated by anything that tricks the rest of us into programming of any kind. -- Jecel ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On Mon, Jun 13, 2011 at 4:02 PM, BGB cr88...@gmail.com wrote: Consider what it'd be like if we didn't represent code as text... and represented it maybe as series of ideograms or icons (TileScript nod). Syntax errors don't really crop up any more, do they? Given a slightly nicer User Interface than tilescript, you could still type your code, (ie use the keyboard to fast-select tokens), but the computer won't validate any input that isn't in its dictionary of known possible syntactically correct items given whatever context you're in. I think Tiles prevent syntax errors is a red herring. Sure, you can prevent stupid typos by offering only tiles with correctly spelled keywords, but that's not really a major problem in ordinary experience. The more pernicious errors aren't especially affected one way or the other by tile-based systems. (You could just as accurately say that strongly-typed systems prevent errors.) given that most non-Chinese can't read Chinese writing, despite that many of these characters do actually resemble crude line-art drawings of various things and ideas. It is a common linguistic misperception that there is some one-to-one correspondence between an ideogram and the idea it represents. The english letter A was originally a drawing of an ox-head. (http://en.wikipedia.org/wiki/A). It is as accurate to say that English letters resemble crude line-art drawings as to say that Chinese ideograms do. and meanwhile, many Asian countries either have shifted to, or are in the process of shifting to, the use of phonetic writing systems (Koreans created Hangul, Kanji gradually erodes in favor of Hiragana, ...). even in some places in China (such as Canton) the traditional writing system is degrading, with many elements of their spoken dialect being incorporated into the written language. This is also playing fast and loose with linguistics. Let's be wary of drawing analogies to fields where we are not expert. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Age and Language (was Re: [fonc] Alternative Web programming models?)
Below. On Jun 13, 2011, at 2:16 PM, C. Scott Ananian csc...@laptop.org wrote: On Mon, Jun 13, 2011 at 4:02 PM, BGB cr88...@gmail.com wrote: Consider what it'd be like if we didn't represent code as text... and represented it maybe as series of ideograms or icons (TileScript nod). Syntax errors don't really crop up any more, do they? Given a slightly nicer User Interface than tilescript, you could still type your code, (ie use the keyboard to fast-select tokens), but the computer won't validate any input that isn't in its dictionary of known possible syntactically correct items given whatever context you're in. I think Tiles prevent syntax errors is a red herring. Sure, you can prevent stupid typos by offering only tiles with correctly spelled keywords, but that's not really a major problem in ordinary experience. The more pernicious errors aren't especially affected one way or the other by tile-based systems. (You could just as accurately say that strongly-typed systems prevent errors.) Agreed, when we're talking about adults, and especially ones who've already learned to code. When it comes to kids and non-programming adults though, I do think that e.g. Scratch is really powerful. I don't have the cognitive science to back up the statement that I'm about to make, so I'm hoping folks will try to shoot some holes in it. Kids may not have the linguistic development out of the way that one needs to do serious programming. Adults who don't already code may find themselves short on some of the core concepts that conventional programming languages expect of the user. In both cases, I think visual systems can get useless syntactic hurdles out of the way, so that users can focus of developing a command of the core concepts at work. Inviting criticism! Fire away, ladies and gentlemen.___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On 14/06/2011, at 6:02 AM, BGB wrote: but, what would be the gain?... the major issue with most possible graphical representations, is that they are far less compact. hence, the common use of graphical presentations to represent a small amount in information in a compelling way (say, a bar-chart or line-graph which represents only a small number of data-points). If it gets longer than a page, something's gone wrong somewhere. ;-) Remember, most people on this list will think encapsulation and objects are good things ;-) (ie small bits of code). So you don't need the kind of compactness you're talking about. The gain is that a picture speaks a thousand words. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: Age and Language (was Re: [fonc] Alternative Web programming models?)
On 14/06/2011, at 7:33 AM, Casey Ransberger wrote: Kids may not have the linguistic development out of the way that one needs to do serious programming. Adults who don't already code may find themselves short on some of the core concepts that conventional programming languages expect of the user. In both cases, I think visual systems can get useless syntactic hurdles out of the way, so that users can focus of developing a command of the core concepts at work. In most parts of the world, Monks used to be the only people who could read and write, you know. ;-) Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On 14/06/2011, at 7:16 AM, C. Scott Ananian wrote: Consider what it'd be like if we didn't represent code as text... and represented it maybe as series of ideograms or icons (TileScript nod). Syntax errors don't really crop up any more, do they? Given a slightly nicer User Interface than tilescript, you could still type your code, (ie use the keyboard to fast-select tokens), but the computer won't validate any input that isn't in its dictionary of known possible syntactically correct items given whatever context you're in. I think Tiles prevent syntax errors is a red herring. Sure, you can prevent stupid typos by offering only tiles with correctly spelled keywords, but that's not really a major problem in ordinary experience. The more pernicious errors aren't especially affected one way or the other by tile-based systems. (You could just as accurately say that strongly-typed systems prevent errors.) When you're about to type the next tile, you're given options... anything outside of those options is impossible, so the computer doesn't put it in, because syntactically it wouldn't make sense. Do you see the power of options, here? :) It's another level of introspection for the programmer on the system that is possible if they need or want it. shrug some people like the computer to do things like highlight matching parenthesis, provide code syntax highlighting and colouring... others don't. (I'm not sure who doesn't). But we're kind of digressing from the point about the kinds of visual systems that I was originally talking about when mentioning TileScript. This isn't necessarily at all TileScript I'm talking about... it's about visual patterning languages (i'm using the term languages very loosely here). TileScript was simply a nod... If you've used any kind of visual math formula builder like the one that used to be present in Microsoft Word I think (and probably still is, I don't know), then you know what I'm talking about.. the syntax is visually patterned in front of you as soon as it becomes apparent to the computer that you're writing a certain kind of math, so you can see what's going on... this stuff is very useful, I'm not sure why you can't see the benefit of it... perhaps you're just too attached to text? :) As my memory recalls, Alan (and the entire VPRI crew I think) has said in the past, Math wins. Math is not written as a linear text per se, is it? Except, of course, where sequence is important ;-) Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
At Mon, 13 Jun 2011 21:55:54 +0200, karl ramberg wrote: I got wondering about commit failure and cases where you needed certain objects in the world child anyway. Or two different worlds merging. Will that be possible ? Yes. You catch an exception to keep the computation going: a := WPoint2 new x: 1; y: 0. w := WWorld2 thisWorld sprout. w eval: [a y: a y + 1]. a y: 666. [w commit] on: Error do: [:ex | ]. then you can say: b := WPoint2 new. b x: (w eval: [a x]). b y: (w eval: [a y]). to salvage the values of a in w into b in the top level world. There should be more first class operations allowed, and perhaps the serializability checks and commit logic should be customizable... -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On Mon, Jun 13, 2011 at 11:17 PM, Julian Leviston jul...@leviston.net wrote: I think Tiles prevent syntax errors is a red herring. Sure, you can prevent stupid typos by offering only tiles with correctly spelled keywords, but that's not really a major problem in ordinary experience. The more pernicious errors aren't especially affected one way or the other by tile-based systems. (You could just as accurately say that strongly-typed systems prevent errors.) When you're about to type the next tile, you're given options... anything outside of those options is impossible, so the computer doesn't put it in, because syntactically it wouldn't make sense. There's nothing specific to tiles in what you wrote. You could do the same just as easily with a keyboard-based system. This is what I mean when I say that tiles prevent syntax errors is not accurate; it's confusing two separate things. Again: more accurately you could say, strong typing can prevent syntax errors... tiles have nothing to do with it, really. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On 14/06/2011, at 1:50 PM, C. Scott Ananian wrote: When you're about to type the next tile, you're given options... anything outside of those options is impossible, so the computer doesn't put it in, because syntactically it wouldn't make sense. There's nothing specific to tiles in what you wrote. You could do the same just as easily with a keyboard-based system. This is what I mean when I say that tiles prevent syntax errors is not accurate; it's confusing two separate things. Again: more accurately you could say, strong typing can prevent syntax errors... tiles have nothing to do with it, really. Assuming a compile after composing type of system. If it's a running, live, system, then type is irrelevant because an object at the point of being talked to will provide its own semantic and therefore syntactic-appropriateness context (ie duck typing for want of a better term). Do you see why I think text-stream based systems are outmoded crappy systems yet? They're not real in the sense of first-level representational. It's the equivalent of me sending you this email by fax, and you running an OCR program across it so it can get into your computer, though obviously less error-prone. However... not to be rude, but you're potentially missing my larger point, which was underneath the two lines you quoted... and you're perhaps getting caught on my bad example of syntax in TileScript - I'm saying the possibilities and ramifications of programming a live system using non-text-stream representation are far greater than that of text-stream ones... either that, or we have to re-engineer the natural possibilities after the fact... (ie Eclipse Java IDE is an example of doing this... where the IDE knows a lot about the language, rather than asking real live objects about themselves). Instead of having actual one-level-linked instantiated objects AT THE POINT of programming, we use multi-layered deferred referencing (ie text-stream based codes which are later processed and further decoded into computer codes by another computer program many times). One of the troubles with computing is that there are so many layers between what's real and the user that we've forgotten how to deal directly with the real. We've forgotten what is happening when we use computers, and this is sad and needs to be addressed. It's the real that's exciting, interesting and impassion-ating... ... granted there will always be those who don't want to see the real, and for those people, we build layers on top (ie Apple products), but still allow the guts to be got at by those who wish it. Presently it's SO DIFFICULT to get at the guts and not because it's hard to fire up GCC... mostly it's the learning that gets in the way... (at least, that's my experience). The sheer amount of education one needs to get through before one can get to the point where one is a true systems expert on our current top-level systems is colossal, and this is mostly due to cruft, IMHO. Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Coding at the Speed of Touch
I think some recent work by Sean McDirmid may be of interest to the FoNC audience. Coding at the Speed of Touch http://lambda-the-ultimate.org/node/4257 This paper describes a programming language with a tile-based development environment designed for use in tablets. The 'type system', such as it exists, involves constraints on which tiles can peacefully coexist, and is used to achieve intelligent suggestions. The language itself is prototype-based and describes 'continuous' behaviors suitable for animating characters in a simulation or game. There's a lot of interesting variety for everyone. Abstract: With their mobility and support for direct touch input, tablets are increasingly becoming tools with which to create. Notably absent from tablets, however, are any capable programming experiences, which is unfortunate as programming is one of the most creative tasks one can do on a computer. This paper describes YinYang, a language that focuses on do-it-yourself game creation on tablets. Inspired by Kodu, YinYang's core syntactic and semantic units are game tiles that are easy to touch and pack densely on small screens. These tiles are augmented with a type system that first exposes the context needed to generate concise touch-friendly context menus, second makes tiles easier to discover for reuse, and third enables robust integration with native (C#) code. This paper details YinYang's design and evaluates our initial experience through a prototype that works on current tablet hardware. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On 6/13/2011 8:39 PM, Yoshiki Ohshima wrote: At Mon, 13 Jun 2011 17:16:10 -0400, C. Scott Ananian wrote: given that most non-Chinese can't read Chinese writing, despite that many of these characters do actually resemble crude line-art drawings of various things and ideas. It is a common linguistic misperception that there is some one-to-one correspondence between an ideogram and the idea it represents. The english letter A was originally a drawing of an ox-head. (http://en.wikipedia.org/wiki/A). It is as accurate to say that English letters resemble crude line-art drawings as to say that Chinese ideograms do. except that in the case of the Latin alphabet, all association with the original idea has long since gone away, and alphabetic characters have no real meaning in themselves, besides a loose association with a particular sound. the pictographs generally have meanings more closely associated with particular things and idea. like, a tree sort of resembles a tree, ... and meanwhile, many Asian countries either have shifted to, or are in the process of shifting to, the use of phonetic writing systems (Koreans created Hangul, Kanji gradually erodes in favor of Hiragana, ...). even in some places in China (such as Canton) the traditional writing system is degrading, with many elements of their spoken dialect being incorporated into the written language. This is also playing fast and loose with linguistics. Let's be wary of drawing analogies to fields where we are not expert. Yup. Such as this: http://pugs.blogs.com/audrey/2009/10/our-paroqial-fermament-one-tide-on-another.html is mainly in the context of # of characters, but also illustrates the area it requires to convey the same amount of information. (And yup, I can tell you Japanese aren't erodes in favor of Hiragana...) sorry... just I thought it was that originally nearly all of the writing was using Kanji, but over a long time (many centuries), the use of Kanji has lessened some, and Hiragana has become a larger portion of the text. admittedly, I don't really know Japanese either though... (besides what I can gain from watching lots of anime...). I have had some (limited) amount of personal experience interacting with Chinese people, but don't know Chinese either (can't really read/write/speak it, but can recognize a few of the basic characters...). by complaining about density previously, I wasn't thinking like traditional pictographs though, so much as people doing similar with icons, say 64x64 pixels or so (like, more like Windows icons), and so would lead to a larger portion of the screen being needed than with words, or with the tradition of assigning meaning to particular globs of ASCII characters (say, -, =, =, ++, ...). or, people using UML diagrams and flow charts, which use large amounts of screen or paper space, and often express less than could be stated with a few lines of text. and also, that I don't personally believe a pictographic system to be inherently more intuitive than an equivalent word-based system, and maybe less so, given the general tool tips experience (like, hover mouse to try to figure out just what a given icon on the toolbar is supposed to do...). or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
