Raffy's Karma [was Re: [ANN] Filtered functions]
in [Lisp]
|
Prev: NY Times
Next: complex symmetric matrices
From: Pascal Costanza on 10 Dec 2009 12:42 On 10/12/2009 17:05, Kenneth Tilton wrote: > Pascal Costanza wrote: >> Note how Kenny posts a whole article about dataflow programming under >> a subject about filtered functions, while he could have opened a new >> thread as well. > > Note that I changed the subject to Raffy's Karma. Sure. Why did dataflow programming enter this thread again in the first place? Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: w_a_x_man on 10 Dec 2009 16:07 On Dec 9, 12:50 am, Ron Garret <rNOSPA...(a)flownet.com> wrote: > "Jealousy is the feeling of anger or BITTERNESS which someone has when > they wish that they could have the qualities or possessions that another > person has." Bad grammar. Let's fix it. "Jealousy is the feeling of anger or BITTERNESS which someone has when he wishes that he could have the qualities or possessions that another person has." -- "A woman's place is in the home." --- Wise Old Saying
From: Kenneth Tilton on 10 Dec 2009 17:15 w_a_x_man wrote: > On Dec 9, 12:50 am, Ron Garret <rNOSPA...(a)flownet.com> wrote: > >> "Jealousy is the feeling of anger or BITTERNESS which someone has when >> they wish that they could have the qualities or possessions that another >> person has." > > > Bad grammar. Let's fix it. > > "Jealousy is the feeling of anger or BITTERNESS which someone has when > he wishes that he could have the qualities or possessions that another > person has." > > -- > "A woman's place is in the home." --- Wise Old Saying You wimp! "Jealousy is the feeling of anger or BITTERNESS which a man has when he wishes that he could have the qualities or possessions that another man has." Now if we're concerned about bad grammar, let's really fix it. "Jealousy is the feeling of anger or BITTERNESS a man has when he wishes he had the qualities or possessions of another." kt -- http://thelaughingstockatpngs.com/ http://www.facebook.com/pages/The-Laughingstock/115923141782?ref=nf
From: George Neuner on 11 Dec 2009 00:53 On Thu, 10 Dec 2009 13:36:43 +0100, Pascal Costanza <pc(a)p-cos.net> wrote: >On 10/12/2009 10:00, Nicolas Neuss wrote: >> Raffael Cavallaro<raffaelcavallaro(a)pas.espam.s.il.vous.plait.mac.com> >> writes: >> >>> On 2009-12-09 10:54:58 -0500, Kenneth Tilton<kentilton(a)gmail.com> said: >>> >>>> My OED still has just "resentful disparagement of something one cannot >>>> personnally acquire". >>> >>> And, for the 5th time now, that which you, ken tilton, cannot personally >>> acquire is acceptance of *your* library, cells, as a publication quality, >>> well documented, extension to clos. >>> >>> So when Pascal C. announces the release of a publication quality, well >>> documented, extension to clos, you disparage it as a "stupid clos trick," >>> i.e., being the author of an extension to clos is something not worth >>> having. >>> >>> This is sour grapes - you disparage something you can't have - >>> acceptance of your clos extension by the lisp community - as something not >>> worth having. >> >> I don't think that that you are wrong, but please note: >> >> 1. In contrast to Kenny Tilton, Pascal Costanza is (as an academic, >> arguably) paid for providing high-quality and well-documented code. >> Thus, IMO this comparison is very unfair. Thanks to Ken for >> providing Cells! >> >> 2. You omit that Ken may have a valid point in his rant. Although I >> like CLOS very much, I am in doubt if it would not be more profitable >> for me to learn using dataflow programming correctly (maybe even with >> Cells) compared with learning yet another CLOS enhancement. > >Without noticing it yourself, you're actually hinting here at an >underlying issue: There is no opposition between (variations of) >dataflow programming approaches and (variations of) object-oriented >programming approaches. The only reason why there seems to be an >opposition is because Kenny always shoots at CLOS whenever possible, and >abuses unrelated threads to push his particular dataflow programming >approach to the fore. If he wouldn't do that, there would never be a >discussion whether "either" is better than the other, or any such nonsense. I think the problem is that everyone is working with a different definition of "dataflow". Dataflow began as a hardware model for parallel speculative execution - a kind of parallel eager declarative model, but implemented below the ISA level so it was programming language neutral. I've been following dataflow since 1985 and I have yet to see widespread agreement on any particular software model as be representative of the concept. I know I'll take some kind of slap from Kenny for saying so, but I don't consider his favorite analogy - spreadsheets - to be representative of dataflow. I do consider that Cells itself is in the spirit of dataflow although, when I tried it, my opinion was that the programmer has to do too much manual fussing with the linkage web (which is also a problem in other attempts at dataflow languages like SISAL, Lucid, Oz, etc.). IMO, execution linkages should be determined automatically by the compiler. So far, I'm not impressed with any of the underlying runtime models - I think Oz generally is headed in the right direction (though I'm not crazy about the language itself). >I am offering filtered functions as a library, because people at my lab >and I myself found them useful in some contexts, and it seems that other >people find them useful as well. At least, I got a surprising number of >responses from people who want to try them. And let me add my congratulations ... I haven't looked at it yet (sorry!) but from the discussions here it sounds as if it may be a quite useful package. And I may be wrong here, but, also from the discussion, it appears that your package is oriented more toward reactive declarative programming than toward dataflow ... so I'm also a bit confused as to why Kenny is so upset. It doesn't seem like your package is a competitor to Cells. George
From: Kenneth Tilton on 11 Dec 2009 07:24
George Neuner wrote: > On Thu, 10 Dec 2009 13:36:43 +0100, Pascal Costanza <pc(a)p-cos.net> > wrote: > >> On 10/12/2009 10:00, Nicolas Neuss wrote: >>> Raffael Cavallaro<raffaelcavallaro(a)pas.espam.s.il.vous.plait.mac.com> >>> writes: >>> >>>> On 2009-12-09 10:54:58 -0500, Kenneth Tilton<kentilton(a)gmail.com> said: >>>> >>>>> My OED still has just "resentful disparagement of something one cannot >>>>> personnally acquire". >>>> And, for the 5th time now, that which you, ken tilton, cannot personally >>>> acquire is acceptance of *your* library, cells, as a publication quality, >>>> well documented, extension to clos. >>>> >>>> So when Pascal C. announces the release of a publication quality, well >>>> documented, extension to clos, you disparage it as a "stupid clos trick," >>>> i.e., being the author of an extension to clos is something not worth >>>> having. >>>> >>>> This is sour grapes - you disparage something you can't have - >>>> acceptance of your clos extension by the lisp community - as something not >>>> worth having. >>> I don't think that that you are wrong, but please note: >>> >>> 1. In contrast to Kenny Tilton, Pascal Costanza is (as an academic, >>> arguably) paid for providing high-quality and well-documented code. >>> Thus, IMO this comparison is very unfair. Thanks to Ken for >>> providing Cells! >>> >>> 2. You omit that Ken may have a valid point in his rant. Although I >>> like CLOS very much, I am in doubt if it would not be more profitable >>> for me to learn using dataflow programming correctly (maybe even with >>> Cells) compared with learning yet another CLOS enhancement. >> Without noticing it yourself, you're actually hinting here at an >> underlying issue: There is no opposition between (variations of) >> dataflow programming approaches and (variations of) object-oriented >> programming approaches. The only reason why there seems to be an >> opposition is because Kenny always shoots at CLOS whenever possible, and >> abuses unrelated threads to push his particular dataflow programming >> approach to the fore. If he wouldn't do that, there would never be a >> discussion whether "either" is better than the other, or any such nonsense. > > I think the problem is that everyone is working with a different > definition of "dataflow". Dataflow began as a hardware model for > parallel speculative execution - a kind of parallel eager declarative > model, but implemented below the ISA level so it was programming > language neutral. I've been following dataflow since 1985 and I have > yet to see widespread agreement on any particular software model as be > representative of the concept. Yeah, when I asked Fred Brooks if he had looked at dataflow programming as a possible silver bullet he said no but that he knew all about it from <x>, which IIRC turned out to be the hardware deal (rather unrelated). > > I know I'll take some kind of slap from Kenny for saying so, but I > don't consider his favorite analogy - spreadsheets - to be > representative of dataflow. Actually Mark Guliano (sp?) the COSI presenter at LUGM 99 preferred the same analogy. Where do you see it breaking down? I try to avoid it because almost everyone misses that it is an analogy and says something like, "Hunh? I do not want to write Lotus 1-2-3!" > I do consider that Cells itself is in the > spirit of dataflow although, when I tried it, my opinion was that the > programmer has to do too much manual fussing with the linkage web Really? There is not even a mechanism for manual fussing. Do you mean sometimes you created circularities and had to rethink your rules? One thing that gets crazy is doing a SETF to cell X in an observer on cell Y. It is not illegal, and it is useful in keeping big hairy applications efficient, but it does make for some harder thinking approaching "manual" in that one really needs to think about the dependency graph at hand. Still a net win, though. > (which is also a problem in other attempts at dataflow languages like > SISAL, Lucid, Oz, etc.). IMO, execution linkages should be determined > automatically by the compiler. No, linkages must be done at run-time because the dependency graph changes at run-time. And they /are/ determined automatically in Cells. Maybe you are thinking of some other package? > So far, I'm not impressed with any of > the underlying runtime models - I think Oz generally is headed in the > right direction (though I'm not crazy about the language itself). > > >> I am offering filtered functions as a library, because people at my lab >> and I myself found them useful in some contexts, and it seems that other >> people find them useful as well. At least, I got a surprising number of >> responses from people who want to try them. > > And let me add my congratulations ... I haven't looked at it yet > (sorry!) but from the discussions here it sounds as if it may be a > quite useful package. And I may be wrong here, but, also from the > discussion, it appears that your package is oriented more toward > reactive declarative programming than toward dataflow ... so I'm also > a bit confused as to why Kenny is so upset. Upset? I was expressing disdain for "even more convoluted GF dispatch" as a useful decomposition of code. Any ire arises from the backstory of the CLOS-heavy code I happen to be dealing with these days. No one's problem but mine. kt -- http://thelaughingstockatpngs.com/ http://www.facebook.com/pages/The-Laughingstock/115923141782?ref=nf |