Lisp and software architecture
in [Lisp]
|
Prev: cosx - sinx + 3x2
Next: the Modernization of Emacs
From: Tayssir John Gabbour on 10 Mar 2006 09:44 Ken Tilton wrote: > Cells support a declarative paradigm in which the motivating force > behind an application's overall behavior is dataflow through a > dependency graph maintained automatically by the system. The benefits > are several. Ironically enough, only this morning I looked at Cells. I suspect it may be genuinely useful. Seems the main use is to define constraints between things, and then simply forget about them, knowing that the constraints will be maintained without additional thought on your part. A good exposition is in Jim Veitch's paper [1] where he described a similar system for Boeing, for modelling planes. * Showed eager updating of parts of a plane when some other part affecting it changes. * Then converted it to lazy updating, so recalculations only happen when a) you look at the part and b) some other part which affects it was updated. [1] "A History and Description of CLOS". Took only few lines of code to illustrate the concept, though the guy actually uses DO* (ugh). Hmm, little surprise that the Cadence/Ltk guys seem to be poking around Cells, I guess, as they work on CAD systems too. > · Eliminates the class of bug in which program state is internally > inconsistent. > > · A corollary benefit: eliminates the housekeeping burden of keeping > consistent the state dependency graph implicit in any application. Maybe a problem is that sounds too technojargony. Tayssir
From: Ken Tilton on 10 Mar 2006 11:05 Tayssir John Gabbour wrote: > Ken Tilton wrote: > >>Cells support a declarative paradigm in which the motivating force >>behind an application's overall behavior is dataflow through a >>dependency graph maintained automatically by the system. The benefits >>are several. > > > Ironically enough, only this morning I looked at Cells. I suspect it > may be genuinely useful. > > Seems the main use is to define constraints between things, and then > simply forget about them, knowing that the constraints will be > maintained without additional thought on your part. Right. But the actual constraint languages included, inter alia, partial and multi-way constraints. I have not needed those so I have not played with those, tho Cells4 will likely support the non-deterministic thing that results. The problem is that the constraint languages proved nearly impossible to program. I am looking for a productivity aid in conventional programming, not to search large solution spaces ala the typical good constraint application. > > A good exposition is in Jim Veitch's paper [1] where he described a > similar system for Boeing, for modelling planes. The prior (and concurrent) art of Cells is vast. > > * Showed eager updating of parts of a plane when some other part > affecting it changes. > * Then converted it to lazy updating, so recalculations only happen > when a) you look at the part and b) some other part which affects it > was updated. > > > [1] "A History and Description of CLOS". Took only few lines of code to > illustrate the concept, though the guy actually uses DO* (ugh). Hmm, > little surprise that the Cadence/Ltk guys seem to be poking around > Cells, I guess, as they work on CAD systems too. > > > >>? Eliminates the class of bug in which program state is internally >>inconsistent. >> >>? A corollary benefit: eliminates the housekeeping burden of keeping >>consistent the state dependency graph implicit in any application. > > > Maybe a problem is that sounds too technojargony. How about "best thing since sliced bread!"? People get upset if one sounds like a carnival barker. Me and the COSI guyhave tried the spreadsheet metaphor, but listeners invariably respond "Oh, I use Excel, I do not need a spreadsheet." So it is a lot like Lisp. A few of us know about Lisp/Cells, and use it to program/managestate, and would not do it any other way given our druthers, but the rest just slog on ignorantly with Java/manualstatemanagement until the mindshare reaches a critical mass and it becomes OK to explore. kt
From: Pisin Bootvong on 10 Mar 2006 12:58 Let me talk about how Ruby's (and Smalltalk's) open class enable better object oriented design than that of Java/C++. One concept of OO is to "tell object to do something" instead of to "tell it how to do something". So instead of saying. cat.position.x = rat.position.x; cat.position.y = rat.position.y; You can do cat.catch(rat); But the problem with OO object like C++, Java and C# is that: "You cannot teach existing object new trick." In those close-object languages, If you don't have access to the class's source code, you cannot add method to that class. So if you want a person to be able to run you probably need to add helper class. class PersonTrick { static void run(Person p){ // Code to manipulate person to make him run via his public method. } } And the method call becomes awkward as PersonTrick.run(person); (Or you can teach this trick in subclass of Person, but that will only work if you control creation of the object). But with Ruby/Smalltalk you can add the trcik directly to the class as. class Person def run # code to make I run end end And you call it as person.run So you can see how code looks nicer and the method is where it really belongs. Since Common Lisp 's generic function is not tied to a single class, CLOS always support Open class design; you can always add generic function specialized on third party's class (The only quirk is that most standard function in CL is not generic function so you can not specialize those function with your own class).
From: goat_roperdillo on 10 Mar 2006 14:04 X-No-Archive:yes Ken Tilton wrote: > Peter Seibel wrote: > > Ken Tilton <kentilton(a)gmail.com> writes: > >>Too bad you gave up on Cells at the first backtrace. Cells simply fell > >>out of an attack on an application problem, turned into a paradigm, > >>took over the whole application. Would never have happened without > >>first-class functions, closures, macros, CLOS, untyped variables... > > > > Hey, that's not fair. I didn't give up because I couldn't get it to > > run--I gave up long before that, when I couldn't find anything that > > explained what it was and why I should care. ;-) I agree with Mr. Siebel. I visited your site and links over a period of 3 years. Semaphor/Cells was poorly documented; there seemed little reason to examine it further. > Oh, lord, that is easy. Go to the ActiveState site, they named the whole > frickin company after Cells functionality. http://www.google.com/search?hl=en&lr=&q=cells+SITE%3AActiveState.com&btnG=Search comes up empty, an extraordinary thing on Google!-) Please tell us what "Cells functionality" has to do with the ActiveState site. > I also find this tool to be a helpful, you might want to give it a try > for things like this: > http://www.google.com/ cf., above. > Try: > http://www.tilton-technology.com/cells-overview.pdf This document is great but was apparently posted on July 2, 2003: http://web.archive.org/web/*/http://www.tilton-technology.com/cells-overview.pdf But you were already posting about Semaphor/Cells (in one form or another) prior to October, 2000, e.g., http://groups.google.com/group/comp.lang.lisp/msg/0a1564e6719bbbce?dmode=source&hl=en There you called it "Semaphors". Later the name changed to "Cells": http://groups.google.com/group/comp.lang.lisp/msg/97297a72116fede6?dmode=source&hl=en So decent Cells documentation was slow to appear. Today your site links to a "Cells tutorial" at Bill Clementson's blog but the link is broken. It should probably be http://bc.tech.coop/blog/030911.html > You never looked at Cells, so i will tell you: Cells manage state. Hey, people looked! "Semaphor"/"Cells" documentation was poor to nonexistent. (BTW did you _pay_ someone else to write that PDF, above? The "author:" tag is blank!8-)) > Well, even with your father pitching it, it took you twenty years to > become a Lispnik: > http://wiki.alu.org/Peter_Seibel's_Road_to_Lisp > Should we look for a Road to Cells Switch Date of 2028? > :) Unfair (along with "code monkey" comment). Mr. Siebel surely deserves at least another 2 years (the time to post decent Cells documentation). > ps. Thanks for the fat pitch. :) Looked like a strike (swing and a miss) from here. G. Roper
From: bradb on 10 Mar 2006 23:24
Your energetic post got me interested in Cells, so I downloaded the tgz from http://common-lisp.net/project/cells/ & tried to follow the cells basic tutorial & Bill's tutorial. I have a problem though, no where in the cells source directory can I find a definition for the DEF-C-ECHO macro. Am I missing something blindingly obvious? Or is Cells ment to be installed someother way? ASDF-INSTALL failed (crashed) on a recentish SBCL. Should I try to install from CVS? Kenny, your post inspired me to look past the lack of documentation (examples and docs within the package acutally do look pretty good), but so far I've had no luck getting any traction well using cells. Cheers Brad |