[fluxus] under the shade of abstraction

[Dave Griffiths]

>
>>> potentially interesting, possibly diversionary... .
>>>  http://www.cs.brown.edu/~sk/Publications/Papers/Published/mspk-abstract-shade-trees/
>>>
>>> abstract:
>>>
>>> As GPU-powered special effects become more sophisticated, it becomes
>>> harder to create and manage effect interaction using the fairly
>>> primitive
>>> shading languages. This difficulty also introduces a workflow problem:
>>> artists design effects but only programmers can implement them, making
>>> it
>>> impossible for them to work asynchronously.
>>>
>>
>> Always the assumption that the notion of a programming artist/artistic
>> programmer is abhorrent :)
> well, it is an admittedly small subset/intersection,. ... .
>
>> The type coercion is very clever stuff though, and I thought the graphs
>> were rendered and editable over the graphics, which would be very fluxus
>> :) but I'm not so sure on further reading
>
> i was hoping so too, and considering the authors, there is probably a
> scheme implementation of some of the code floating around somewhere.. . .

Shriram Krishnamurthi is Dr Scheme? :) I'm quite close to writing an
experimental MzScheme version of fluxus btw.

I've been wondering - a lot of the recent interest in lispy languages
seems to have come about due to parallel processing, eg google's MapReduce
algo etc etc. So would the massively parallel stateless GPU processing
lend itself to a lispy functional language?

cheers,

dave