I recently wrote my bachelor thesis about functional reactive programming. In the course of it I implemented a very simple scene with Yampa and an OpenGL binding for Haskell. The reason I chose Haskell was mainly because I never had a functional programming course in university and decided that I want to give it a try. (The code is at https://github.com/Joe-Z/yampa-programming if you are interested).
The problem, in my opinion, of so much of functional programming research is that the presented applications are most often developed only for the sake of one or two research papers and then stopped pursuing. This leads to various papers, scattered across the internet, which all hold some precious information, but are incredibly hard to put together and make real world things out of them (I remember, when I just recently had to search through 7 years of Yampa mailing list, to maybe find some information on a problem I had).
Which is why I decided to add some Yampa “Hello world”-like programs to the aforementioned repository, so lone wanderers through the field of FRP are not so lost after all.
[edit: should me more readable with paragraphs...]
For what's worth, from my perspective as someone fairly evenly split between theory and practice, FRP should still be seen as experimental and not ready for prime time. There are still some fundamental unresolved problems in theory, and I'm not seeing huge evidence that the practice is worked out either. I'm interested and it's worth keeping an eye on, but I do fear it's one of the better examples of some people on the academic side declaring they've got the One True Way to program when their One True Way can barely hold together in toy programs. I hope to see more good work come out of this field, though. I'm cautiously optimistic there's something there.
(On the other hand, I do also think that one of the problems FRP faces is in trying to bind to a very not-functional world. UI toolkits in particular are deeply, fundamentally imperative, and such massive endeavors that the idea of replacing one with a functional equivalent is laughable, because the resources aren't there, even though there aren't any fundamental blockers. Needing to hook up your FRP to such toolkits to get them to do anything is a huge up-front penalty to pay to even get one started.)
As I said, it's a massive undertaking. The minimal acceptable toolkit (to say nothing of competing with GTK or QT, just getting the minimal toolkit that users will tolerate) is an immense amount of work. Quite a lot of it is essential complexity, the things that textboxes do that are simply expected and are true representations of complexity, not accidental artifacts of the paradigm used. Functional programming may or may not help with accidental complexity but nothing can duck the essential complexity. I'd estimate that even a minimal toolkit would be on par with the time invested into GHC itself, and to seriously compete, tack a couple of orders of magnitude on there.
In a world where everybody implements MVC web framework in their favorite language, reimplements window managers in their favorite language, and reimplements all manner of other software simply because it wasn't in their favorite language... there's a reason all the communities just bind to GTK, QT, and wxWidgets and don't reimplement widget frameworks from scratch in their favorite language, even for languages much better funded and bigger than all the functional programming communities put together. Just the bindings can be major and in some cases unsustainable efforts for smaller communities.
Perhaps if you need a comprehensive toolkit that supports the various widgets and gestures in contemporary toolkits, it is a big undertaking (probably not that massive, IMO).
It is incomplete and non-comprehensive, but adding the nuances needed to make it more complete and comprehensive wouldn't be too much work (it's simply not our focus in the project).
I was citing the amount of work to create a minimal acceptable toolkit to a programmer on the street, the sort of toolkit you'd point a hostile Python programmer to to say "Yes, we have a native toolkit", not the toolkit that you'd use to convince an already-converted Haskell user. Bear in mind that Tk prior to their relatively recent theme work was not that toolkit either! And that was actually a pretty decent kit, with layout managers, a nice text widget, tabs, all the basic stuff you'd need, if not the fanciest ever.
* It is incomplete and non-comprehensive, but adding the nuances needed to make it more complete and comprehensive wouldn't be too much work*
So it's minimal AND incomplete. Not even minimal and complete. That's what the parent was saying. And it will likely stay that way (as it's not even your focus in the project), and be forgotten.
The problem, in my opinion, of so much of functional programming research is that the presented applications are most often developed only for the sake of one or two research papers and then stopped pursuing. This leads to various papers, scattered across the internet, which all hold some precious information, but are incredibly hard to put together and make real world things out of them (I remember, when I just recently had to search through 7 years of Yampa mailing list, to maybe find some information on a problem I had).
Which is why I decided to add some Yampa “Hello world”-like programs to the aforementioned repository, so lone wanderers through the field of FRP are not so lost after all.
[edit: should me more readable with paragraphs...]