[Haskell-cafe] [reactive] A pong and integrate

[Peter Verswyvelen]

Well, first of all, I did not make these PS3 visualization, my former
colleagues and I just made the editor, language and runtime that
allowed video game artists to do the job for us in a couple of weeks
time :-)

I wouldn't use Yampa, for performance reasons, and difficulty to get
it running on alien platforms (it is well known it performs relatively
badly, although the work done by Paul Liu and co on Causal Commutative
Arrows looks very promising, but does not support dynamic switching
yet). After all, Yampa models a synchronous dataflow language, and
compilers for these languages are relatively easy to make IMO.

My previous - now defunct -  company Anygma spent a lot of money on
trying to use Haskell and Reactive for game programming, which
unfortunately ended in some nasty GHC bugs popping up (see
http://www.haskell.org/haskellwiki/Unamb), and not all problems with
Reactive got fixed; it is amazing how difficult this all turned out to
be. The GHC bugs are now fixed, so it might be stable enough for
another adventure like that, but I don't think I would bet on it
again.

IMO Haskell is great for writing small clean prototypes, doing
interesting research, and maybe making some fun little games, but I
wouldn't use it for production reactive game coding, not yet at least.


On Tue, May 25, 2010 at 10:49 AM, Limestraël <limestrael at gmail.com> wrote:
> Wow... impressive...
>
> And now, with your experience, if you'd have to do this again, would you use
> Yampa or stick up with C#/C++ ?
>
> 2010/5/24 Peter Verswyvelen <bugfact at gmail.com>
>>
>> Yeah. Funny that we're still writing games in C++, while mission
>> critical and hard real time systems are written in much nicer
>> languages :)
>>
>> I made something similar to Lucid Synchrone for a game company I used
>> to work, but with the purpose of making reactive programming
>> accessible to computer artists. The integrated development environment
>> provided the typical boxes-and-links user interface, where the boxes
>> were signal functions. Signals itself were not exposed, like Yampa.
>> The system did type inference so artists never really had to deal with
>> types. Special nodes like feedback and delay where provided to allow
>> transferring values to the next frame. This actually was a great
>> success, digital artists could literally create little interactive
>> applications with it, without much  help from programmers. This
>> resulted in a Playstation 3 visual experience "Mesmerize"
>> (http://www.youtube.com/watch?v=rW7qGhBjwhY). This was before I knew
>> Haskell or functional programming, so it was hacked together in C# and
>> C++...
>>
>> I still believe that the reason why computers artists could work with
>> this environment and were not able to learn imperative programming is
>> functional programming itself: the system had all the goodies of FP:
>> type inference, referential transparancy, etc... But is also provided
>> the possibility to edit literals while the simulation was running,
>> providing zero turnaround times, which was equally important for quick
>> adoption of the software.
>>
>> So IMO Haskell and FRP systems have a huge potential for education of
>> a much broader audience than just computer scientists...
>>
>>
>>
>>
>>
>> On Mon, May 24, 2010 at 6:13 PM, Limestraël <limestrael at gmail.com> wrote:
>> > I assumed also that it was a field which was still under research,
>> > however,
>> > Lustre, again, is used "for critical control software in aircraft,
>> > helicopters, and nuclear power plants", according to wikipedia.
>
>