Oliver Charles

I strongly recommend that you learn Haskell.

I have some reasons to back up my endorsement of Haskell.

First and foremost, Haskell is the best language to learn if you want to learn about functional programming. Why? Because Haskell is the quintessential functional programming language. It is approaching 30 years of age and was originally developed back when functional programming was nowhere to be found in production settings. A bunch of academics who were all working on separate functional programming languages got together and said, “hey, how about we all work together and make the ultimate FP language rather than reinventing the wheel on our own?” And that’s exactly what they did. The result today is a very mature, feature rich and programmer-friendly language. If you really want to delve into the history of Haskell, check out this paper or watch the video based on it:

https://www.microsoft.com/en-us/research/publication/a-history-of-haskell-being-lazy-with-class/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsimonpj%2Fpapers%2Fhistory-of-haskell%2F

The second reason to learn Haskell is that it is a great language for doing the things you want to do. A prominent Haskeller, Gabriel Gonzalez, estimates that Haskell is mature in the domain of server-side web development. Check out his view on the state of the Haskell ecosystem:

https://github.com/Gabriel439/post-rfc/blob/master/sotu.md#server-side-programming

Writing CLI programs is also rated…

I love haskell but I wish there was less blogging about why everyone else should use it and more building things that will make people want to use it.

The community is extraordinarily friendly to beginners, as long as you only count how they interact with beginners. If you count having resources that allow beginners to figure something out without having to ask then they are extraordinarily unfriendly.

If I find a potentially interesting library on hackage I'm no longer surprised to find it has no documentation at all, certainly no usage documentation or explanation of what it actually does or what it should be used for. Just code and autogenerated API docs. I'm surprised if there is anything that would allow me to actually use it. I'm not often surprised this way.

That and the wild west, "not invented here", multiple incompatible implementations of new ideas used in different important libraries (iteratees at the moment).

Not trying to throw blame around of course, but people probably don't need your "I have a new metaphor for monads" blog post or an argument for why it's worth learning. People need more posts like the 24 Days of Hackage(http://ocharles.org.uk/blog/) series and the Real World Haskell book and they need some brave person to try and convince those amazing library developers to standardize on an imperfect solution a little sooner and for a little longer (only in public of course).

Howdy!

I've been using https://github.com/jspahrsummers/ObjectiveHaskell/ as my bridge between the two worlds (with some modifications for iOS that I'll be posting soon). Haskell has a wonderful FFI that lets you easily call C/Objective-C from Haskell and vice versa.

There's also Manuel Chakravarty's extremely exciting "Inline Objective-C" project (coming soon) that allows you to embed Objective-C code directly into Haskell, which would make it nearly effortless to speak fluently with Apple's frameworks.
https://gist.github.com/mchakravarty/4632567

There are tons of awesome Haskell FRP implementations, from Netwire to Elerea to Reactive-Banana:
http://ocharles.org.uk/blog/posts/2013-08-18-asteroids-in-netwire.html

It would also be a lot of fun to get Helm running on iOS once they finish their OpenGL backend.
http://helm-engine.org

I definitely couldn't have pulled off my own project (SpaceTime, a multiplayer app engine for iOS; announcement soon) without Haskell. I've been using the development versions of GHC iOS to build it for over a year and it's been a joy.

> Putting too many functions that are relatively complex in the where clause is a bad idea, because you lose the explicit type signature…

Note that it’s possible to give type signatures for definitions in “where” clauses:

twice :: Int -> Int
twice x = two * x
where
two :: Int
two = 2

However, you may need the ScopedTypeVariables extension[1] in order to be able to express the correct type signature. (This extension will probably be standardised at some point.)

The biggest real problem I’ve found with large “where” clauses is that they tend to have a lot of implicit dependencies on variables from the enclosing scope. Sometimes you want that for convenience, readability, or performance, but lifting local definitions out into top-level definitions can also help make them more explicit and reusable.

[1]: https://ocharles.org.uk/blog/guest-posts/2014-12-20-scoped-type-variables.html

I'm curious about this as well so I did some searching.

Fay[1], a subset of Haskell that compiles to JavaScript, seems to be the primary choice. There are DOM and jquery bindings for it and this blog post[2] looks like a great introduction.

There are other options, this [3] article outlines a number of them as a greater overview of both server and client side programming with Haskell. I also found an intriguing article [4] on the Haskell site but it appears to be out of date, referencing libraries that are no longer in development.

[1]https://github.com/faylang/fay/wiki

[2]http://ocharles.org.uk/blog/posts/2013-12-23-24-days-of-hackage-fay.html

[3]http://www.stephendiehl.com/posts/haskell_web.html

[4]http://www.haskell.org/haskellwiki/Haskell_in_web_browser

I don't use Nix with Haskell myself yet, because I haven't been doing much Haskelling recently. But I do use it with Python and it's really excellent to use once you start to "get it." Skimming this guide, it seems to do a nice job of explaining Nix as applied to Haskell development[0]. And I'm sure there are many other resources, since it seems to have some traction in that community. I don't know much about the other options you mentioned, but one of the really nice things about Nix is that it's language-independent, which makes it just as easy to express Haskell package dependencies as it is to express any arbitrary dependency (e.g. a foreign library you're linking against).

[0]: https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html