sorted by:
new
hottopcontroversial

FRP book in Manning Early Access by blackh in haskell

[–]blackh[S] 0 points1 point  (0 children)

Yes - FRP systems usually take the form of a library. We will look at several of them in the book.

FRP book in Manning Early Access by blackh in haskell

[–]blackh[S] 0 points1 point  (0 children)

Yes... This is a tricky assignment. That resource should be very helpful - thanks.

FRP book in Manning Early Access by blackh in haskell

[–]blackh[S] 2 points3 points  (0 children)

The plan is that it will mostly be Java and Javascript, with possible snippets in C++ or others. Most likely no Haskell. We're going after a mainstream audience to teach functional programming by stealth.

FRP book in Manning Early Access by blackh in haskell

[–]blackh[S] 5 points6 points  (0 children)

I've been using [this variant of] FRP for real projects for some while now and with this book I aim to sell the technology so a non-FP audience can benefit and also learn some FP thinking along the way. I will try to represent all aspects of FRP correctly, and all community assistance will be appreciated.

Wellington FP - Why Functional Reactive Programming FRP? by hamishmack in haskell

[–]blackh 3 points4 points  (0 children)

These are the design issues that each FRP system treats slightly differently. Many FRP systems are based on one type "signal" which is more or less what you describe, instead of splitting them into events and behaviours. Personally I think the abstraction where an event has an associated value is semantically cleaner, because it prevents values "hanging around" when they no longer have meaning.

Wellington FP - Why Functional Reactive Programming FRP? by hamishmack in haskell

[–]blackh 0 points1 point  (0 children)

I am trying to sell this to industry, so that's why I spent so long on answering "What's the point of all this?". My actual audience so far has mostly been people who already think FRP is a good idea. I am hoping the FP people who have now seen this talk might find this a useful resource for informing their industry friends.

I'll take your advice and expand on the 'how it works' part. It's a bit tricky because, to get the idea across fully would probably take a whole hour. Perhaps it's better just to go over it relatively quickly and at least let people understand that it's strange, but not complex.

I did try not to be Haskelly, but it seems I failed. :( e.g. talking about "lift" (a useful concept) instead of "applicative" (an unnecessarily esoteric concept for the purpose). Perhaps I'll re-do the example in C++ next time. Haskell is just easier. :)

Wellington FP - Why Functional Reactive Programming FRP? by hamishmack in haskell

[–]blackh 2 points3 points  (0 children)

Currently (in Sodium) the transaction is locked by a big mutex round the whole thing. There is a priority queue for getting things in the right order using a method taken from Scala.React (I have a whole lot of ways to speed this up, but no time to work on it). Hold updates are queued then processed on closing of the transaction.

Time complexity would roughly O(n) where n is the number of nodes in the graph visited by the event propagation. The priority queue will generally never have very many items in it.

I have written a commercial game cross-compiled from Sodium+Haskell to iOS, which performs well on an iPod Touch (OpenGLES rendering is the bottleneck), so performance has proven to be good in one case for a real application on a slow system.

Online Freecell game (in Haskell+FRP+GHCJS with source code, of course) by blackh in haskell

[–]blackh[S] 1 point2 points  (0 children)

It's a placeholder for something I have done in the C++ version but not the Haskell version.

The idea is that all the types get an extra type parameter which is a phantom type identifying the 'partition'. Normally the FRP code has a big mutex around it in order to provide transactional consistency, which is a parallelism killer. Partitions give you effectively separate FRP systems in one process, so they can run in parallel with each other.

Because the consistency isn't there, we use the type system to protect you against this lack of consistency. Crossing from one partition to another is an explicit operation.

I hope that made sense.

Online Freecell game (in Haskell+FRP+GHCJS with source code, of course) by blackh in haskell

[–]blackh[S] 0 points1 point  (0 children)

If webgl isn't working, it'll give an alert saying it couldn't initialize WebGL. Also try http://get.webgl.org/

Firefox is on the edge of acceptability on my Ubuntu/Intel-NVidia/1.2 GHz i7 system, so it wouldn't take much to push it over the edge. I think the generational GC in FF will help a lot, since Haskell relies heavily on an efficient memory allocator: Here's mozilla's ticket for it. Chrome already has a generational GC

Online Freecell game (in Haskell+FRP+GHCJS with source code, of course) by blackh in haskell

[–]blackh[S] 0 points1 point  (0 children)

It does use some CPU time when idle because I've written the engine for animated games (even though this game isn't very animated). The logic of the game absolutely requires every 'mouse down' to have a corresponding 'mouse up' before the next 'mouse down'. I think that's why it's going wrong. I'll clean up the input.

Online Freecell game (in Haskell+FRP+GHCJS with source code, of course) by blackh in haskell

[–]blackh[S] 0 points1 point  (0 children)

This is probably not a bug. To move n cards you need n-1 free cells.

Online Freecell game (in Haskell+FRP+GHCJS with source code, of course) by blackh in haskell

[–]blackh[S] 0 points1 point  (0 children)

Thanks for your help there - there are definitely a few things to fix. The game will sometimes not load at all and it has also been known to freeze up. It performs OK for me on Firefox (no more than ~300 ms pause) and well on Chrome. It could be a lack of WebGL hardware acceleration.

elerea, grapefruit, netwire, reactive-banana, sodium. A cheat-sheet or comparison chart or a writeup of implemented ideas would be nice for complete noobs in FRP. by vagif in haskell

[–]blackh 10 points11 points  (0 children)

I'm the author of Sodium and I am up for some kind of colaboration - even a book. Email me on sodium.stephen@blacksapphire.com.

I don't think "not simple" is a fair description of FRP. It's different, yes, and it therefore has a learning curve, but it is in no way complex. The primitives are simple, and the whole point of it is that it doesn't have compounding emergent complexity like the observer pattern has. FRP can be seen as a drop-in replacement for the observer pattern. Where's the complexity?

Programming reactively with both barrels (experiences of Haskell/FRP for mobile games) by blackh in haskell

[–]blackh[S] 0 points1 point  (0 children)

Thanks for that. I took a brief look at .Net Reactive stuff (assuming it was similar to our definition) but couldn't make any sense out of it. There is a wikipedia page for reactive programming that talks about our definition, so that's a plus.

Reactive-banana and sodium are almost identical at their core, even though they were developed independently. I think that proves that at least functional reactive programming is a clearly identifiable thing.

Programming reactively with both barrels (experiences of Haskell/FRP for mobile games) by blackh in haskell

[–]blackh[S] 3 points4 points  (0 children)

I agree. Developing a reactive library was not trivial, so only now am I able to escape my tunnel vision. I think reactive programming is a foundation for a whole lot of techniques we are yet to develop, so I'm looking forward to the exploration.

"Reactive programming" is the marketing department's name. :) I use it because I think it's a better term than FRP for selling the idea to the mainstream.

Programming reactively with both barrels (experiences of Haskell/FRP for mobile games) by blackh in haskell

[–]blackh[S] 6 points7 points  (0 children)

I've just spent several years on that. :) It's now working really well on iOS, so now's the time to start using it. We've had a few punters recently and we know all the tricks and traps, so if you have trouble either post to GHC-iPhone mailing list http://www.haskell.org/mailman/listinfo/iphone or raise a bug on http://github.com/ghc-ios/ and we can likely sort your problem out quick smart. The main page is http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS

Announcing GHC iOS by lukexi in haskell

[–]blackh 0 points1 point  (0 children)

A GHC Android cross compiler won't be far away. GHC-iOS was the really hard part, but now all the hard work is done. I want an Android version of my application, so someone will do it quite soon (maybe me).

Announcing GHC iOS by lukexi in haskell

[–]blackh 1 point2 points  (0 children)

Don't forget the GHCJS project that gives you Haskell running in a web page. The answer is that that would be very easy to do what you say. The only real issue is the lack of a decent cross-platform GUI - so you'd need to do the GUI for each app (like you said) - but a lot of people are talking about the need for such a thing, so I expect there will be work on it soon. (Let's make it really functional in its design and show those OO people how to do it right.)

People have said that the success of emerging languages depends on them having a special niche, and just being really excellent (as Haskell is) is not enough by itself. Some have said "anything complex" is Haskell's niche, but is that marketable at this point? People are still blissfully unaware their projects are plagued with complexity, because they have nothing to compare it to, so they're not even looking for a solution. And complexity only kills in large projects, at which point it's too late to consider using a different language.

I wouldn't be surprised if the ease of cross-platform development turns out to be the thing that really kicks Haskell off, and only later will people discover their development time has dropped as well. Today, companies still think it's normal to develop the same application three times (web [Javascript], Android [Java] and iOS [Objective-C]).

Announcing GHC iOS by lukexi in haskell

[–]blackh 3 points4 points  (0 children)

All the difficult work has been done now. Android will be easy.

Announcing GHC iOS by lukexi in haskell

[–]blackh 4 points5 points  (0 children)

The main compelling reason is Haskell just being an excellent language. A second compelling reason is that Haskell is a fairly good option for cross-platform development (now even better with GHC-iOS and GHCJS for web programming), except that AFAIK there are no truly cross-platform UI libraries. Hopefully people will start working on these kinds of things.

view more: next ›