Nikodemus Siivola wrote:
On Mon, Nov 10, 2003 at 12:16:46PM -0500, Kenny Tilton wrote:
More fun? Graphical output which would be much more recognizable. Handling mouse and keydown input.
Fair enough. Never having written a GUI app in my life I'm always left a bit cold by GUI examples, but basically they're fine.
Don't worry, I am not talking about doing a boring GUI example, I am talking about having neat visual effects and clear relationships thanks to the fact that I can draw pretty shapes on the screen that change as you tweak parameters from the repl. For example we can have a container with a fixed number of moles of a gas. we can manifest the temperature via color, moving gradually from blue to red to show gradations of increasing temperature. We'll use Boyle's Law in a rule somewhere, then let the size of the container be mediated by a cell-variable. Then we can setf that value from the repl, see the container get smaller, see the temperature increase. Then maybe we put a goofy thermometer above the box. That has a column of mercury which increases in length as the temperature below increases, but maybe we do that over time (using a new kind of synapse I think I have to invent <g>) or maybe I can do it as a drifter. I can also show how I position the thermometer over the container without calculating actual coordinates. Stuff like that.
Have you looked at the text-based examples?
Yes, comments below.
Hmmm, that would be a challenge. A text-only, real-world example on which to base a tutorial.
Almost any simulation would seem plausible.
Do me a favor, let me know everyone what you think of the text-based tutorials on Bill's blog and in my own 01-cell-basics.lisp (and there is
Looking at 01-cell-basics.lisp.
The terminology is somewhat confusing. For example:
"C? associates a rule with a cellular slot (or "cell", for short)."
Which really doesn't make sense to me: it doesn't seems to associate anything with anything, but rather (as far as I can tell so far) *creates* a rule that can then be associated with a cell.
True. I'll reword that.
Nowhere do I see a short explanation of the basic consepts: What are rules and cells? How do they relate to each other? It's easy enough to pick up the basics of "howto", but really hard to understand the "why".
Example: I look at an example on defmodel, and see how SELF seems to be bound by it for :default-initargs. Except that this bit of anaphora seems to be done by C?...
No, defmodel does not do anything like that, and any anaphoric SELF appears inside a rule. I also use self as parameter names a lot, but then there is no anaphoric mystery.
defmodel is just defclass, plus it writes macros ^slot and accessors slot and (setf slot).
A non-documentation-related nitpick: I find myself mentally skipping over C?, CV, &co constantly, since the names look like internal iteration or pattern matching variable names...
I'd personally prefer
(cell-lambda (foo) ...)
or equivalent over C? with implicit lexical bindings, and DEFINE-CELL-ECHO over DEF-C-ECHO, etc...
But I'm just funny that way. ,)=
Well I am a long-name freak myself, but when it comes down to something I will be using a lot I turn into an APL clone. Esp. because I will be using them a lot, there is no confusion. Meanwhile they do not take up a lot of space.
One answer might be to clean up something like the boiler example (fairly realistic, that) which already covers all the basics. Then do up a similar level of reference material for those who just want to dive in and have some place to see all the options.
Sounds sensible. Except that I'd prioritize that reference. Very often when reading a given tutorial I like to refer to an actual reference every once and a while to check if I'm understanding things correctly.
Probably once I sit down to do the reference I will scoot thru all the syntax at once. that is a lot easier than writing tutorials and worrying about whether the tutee is keeping up.
Even if one is /not/ doing a GUI, the complexity of this will be enough to see how Cells scale to big problems, and given the LW ubiquity, it would not really be an obstacle to anyone that I am using a proprietary tool (in freebie form).
True. Though I'm surprised if you really need to sell the scalability very hard. Especially since I think that if there are doubts about scalability they would/should be focused on huge nets and simulations, not interface.complexity... ;)
Well, there is scaling and there is scaling. Your example (many, many similar elements) gets at performance. Mine gets at what happens when a neat hack is asked to manage greater and greater varieties of things, and the functional dependencies become more and more semantically diverse.
Cells have overhead in tracking dependencies, so they do fine in the latter case (for which they were developed) where complexity arises from great variety amongst relatively few instances), but I imagine they will not be appropriate for something like the game of Life, where they add very little value (it's a pretty simple algorithm, with very clear dependencies and ways to identify on the fly said dependencies, zero variety (all Life cells work the same), and even change is completely simple: all cells get recalculated at the same time in one generational step.
Good input. Thanks.
kenny