FP Complete Blog

Amazing survey.

Big fan of property testing.

A particularly big fan of Hedgehog.

I tried writing a Hedgehog-inspired library in Rust and realized how complex the underlying domain is.

For example, the RNG is "splittable" [1][2] which means you can take a deterministic seed and split it in two, e.g. for parallel generators to work independently but still deterministically. The effort that has gone into this feature level is a little numbing. I have an awe similar to that of the "fast inverse square root" hack when I see code like this:

-- | A predefined gamma value's needed for initializing the "root" instances of -- 'Seed'. That is, instances not produced by splitting an already existing -- instance. -- -- We choose: the odd integer closest to @2^64/φ@, where @φ = (1 + √5)/2@ is -- the golden ratio. -- goldenGamma :: Word64 goldenGamma = 0x9e3779b97f4a7c15 when realizing that those numbers don't come easily. [3]

[1]: https://hackage.haskell.org/package/hedgehog-1.4/docs/src/Hedgehog.Internal.Seed.html#Seed

[2]: https://gee.cs.oswego.edu/dl/papers/oopsla14.pdf

[3]: https://github.com/hedgehogqa/haskell-hedgehog/issues/191

Wonder why most property-testing libaries don't have features like this?

The libraries require training to use. And they're not that easy to write.

> the current state-of-the-art when it comes to property-based testing is stateful testing via a state machine model and reusing the same sequential state machine model…

> https://tech.fpcomplete.com/haskell/tutorial/operators/

You're a prime example of a person who reads a page on the Internet and takes it at a face value without understanding the meaning and the context behind the words:

> One of the most common operators, and source of initial confusion, is the $ operator. All this does is apply a function.

Did you miss the part that says "All this does is apply a function"?

Here's how you define (+) among other things: https://hackage.haskell.org/package/ghc-internal-9.1201.0/docs/src/GHC.Internal.Num.html#%2B

instance Num Int where I# x + I# y = I# (x +# y) whereas (+#) is defined as a bridge from unboxed ints provided by the runtime to their efficient low-level machine representation, accomodating all instances of a data type defined as `Int = I# Int#` (the left-hand side is the name of the type, the right-hand side is the name of a constructor that accepts a single value of type Int# - the low-level primitive provided by the GHC implementation).

The (+) in `I# x + I# y =` is a function definition in infix form. That's the same form you can use for any other infix function if you wish so:

ghci> a `iAmHelping` b = a b + b ghci> :t iAmHelping iAmHelping :: Num a => (a -> a) -> a -> a > Oh you mean the things that look like operator, behave like operators

Let me see your regular operators do the following, then we talk:

plus = (+) a = (2 +) c = (2 `plus`) c' = plus 2 d =…

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…

Even with Haskell you can still have deadlocks [1]. They give you the tools to write code that you can prove won't have them, but restricting the kinds of programs you can write. But it's an opt-in thing, it's not a promise of the language that you can't do it. Rust is trying to do a similar thing, but it's still also possible to write yourself into a corner with deadlocks if you work against the feature.

Another language I saw recently that has this promise was Pony which uses an actor and message passing model to try to accomplish this but it doesn't actually prevent you from hitting the case, instead it'll just kill a random actor until the deadlock is gone [2]. This can work but it needs to be up front that you MUST write your software to be ready to be killed at any time and continue to function.

It's really an impossible situation to completely "solve", given that doing so would require a solution to the halting problem. So it's always a fun place for me to start looking at any new language if they talk about locks and dead-locks. So far I think Haskell and Rust (and probably other ML family) have the best balance being struck since you can opt in to statically proving this if you restrict those parts of your program but you're not required to do so by the language itself.

[1] https://www.fpcomplete.com/blog/2018/05/pinpointing-deadlocks-in-haskell
[2] https://news.ycombinator.com/item?id=9485333

It's not just people at FP Complete `et al` who were frustrated with cabal-install. Cabal-hell was the number one problem with using Haskell for commercial projects, as a majority of people responded who took part in a FP Complete Haskell organized survey (this was before stack was officially released), https://www.fpcomplete.com/blog/2015/05/thousand-user-haskell-survey. I wrote that survey, if you want to discuss methodology I would be happy to. Anecdotally, after contacting by email most of the respondents, very few complained of a fragmentation the community by virtue of stack being released. We could argue all day over about arguments on reddit, but data suggests otherwise.

FP Complete is a commercial consulting firm now targeting life science companies. We use Haskell because we believe it is the best modern language for robust high-performance software. It is not our goal to own the Haskell ecosystem. It is our goal to promote Haskell use and to develop reliable tooling. Do people feel the same way about continuum analytics for releasing Anaconda and special versions of numpy?

The problem with packages and Haskell is well known; there are a few camps currently trying to solve the issue. Personally, (although the author went about things in a rather roundabout way) I can feel for the author. I LOVE Haskell, I cannot think of a better language for prototyping crazy ideas in and I work in it every chance that I get; that being said, its awful to get up and running with cabal. The suggestion which has been posed to me is "simply use cabal-dev", when I do this, I wind up with crazy huge project files because of repeat installs. I sincerely hope that someone much smarter than myself can come up with a solution for this; I think it is a primary reason why Haskell is not being more widely adopted.

References(for those who are interested)
http://www.yesodweb.com/blog/2012/04/replacing-cabal
http://www.yesodweb.com/blog/2012/03/cabal-nirvana

Hopefully the guys at FP complete will redirect some of their focus onto this (please oh please).
http://fpcomplete.com/