

Haskell at Front Row Education - mightybyte
https://github.com/commercialhaskell/commercialhaskell/blob/master/usage/frontrow.md

======
implicit
> The testing frameworks out there are still fairly spartan from the developer
> experience standpoint.

At IMVU, we built up a bit of scaffolding along these lines:
[https://gist.github.com/andyfriesen/43d886ce60927c69b3d1](https://gist.github.com/andyfriesen/43d886ce60927c69b3d1)

The basic premise is that all our business actions can either be run "for
real" through Yesod, or within a State-based framework that's part of our
standard testing scaffold.

The end result is that it's trivial to write tests that arrange for the
database, clock, sockets, and so forth to be in precisely the state we want
them to be for the test, and to sense everything afterward.

Running these tests as pure State actions has additional benefits:

Since State operates by making successive state copies for each "mutation",
test fixtures are easily effected by performing some actions and saving the
produced state. Individual tests can start from this state as many times as
desired. The state is immutable, so test interference is impossible.

Additionally, tests run without access to IO. This means that the compiler
rejects any test which could forseeably intermittently fail.

~~~
akurilin
Great, I'll need to mine that for ideas, thanks for sharing! Are IMVU web-
services also Yesod-based?

~~~
implicit
They are for now, but we've been whittling away at it.

We don't actually use any of Yesod's affordances except for its router. We're
aiming to eventually split that off and run on bare Warp.

~~~
akurilin
Any particular reason why Yesod isn't a good fit there? Is the team large
enough where it makes more sense for you to roll your own and not deal with
making it super generic?

~~~
implicit
Yesod provides a ton of functionality related to the larger problem of
building a website with Haskell, but we're only using Haskell for JSON
services.

All those extra bells and whistles are wasted on us. :)

~~~
axman6
Sounds like you need servant, i've found writing pretty minimal web services
in it really nice.

~~~
platz
or Airship [https://blog.helium.com/helium/2015/04/01/helium-
webmachine-...](https://blog.helium.com/helium/2015/04/01/helium-webmachine-
airship.html) which uses the webmachine model. Very nice for for APIs.

------
cies
A recent HN post was claiming JEE to be a "startup's secret weapon" (SSW), and
I commented that the article did not much to actually backup that statement.

This article explains nicely why Haskell _could_ be an SSW, and specifically
in what cases it might is more likely to be. It nicely walks through the
strengths and the weaknesses, and compares to the previous experiences with
clojure/ruby.

------
thinkpad20
> Build times, especially once the whole constellation of Yesod and Persistent
> packages are brought into the mix, are not insignificant. It still takes a
> good 5-10 min to build our larger web application on our beefiest machines.
> There are optimizations that can be made in this space which we haven't
> adopted yet, such as caching already build object files to avoid having to
> re-compile them every time, so I'm confident this will be a non-issue in the
> nearby future, but it's still worth being aware of. GHC works hard, you need
> to provide it with enough juice or time to let it do its job.

You hint at the solution to this problem when you mention caching, but I would
encourage you to look into the Nix package manager. It's platform and language
independent, and is excellent at dramatically speeding up builds by only
building anything once. It's gaining popularity in the Haskell community.

~~~
akurilin
Cool! Do you happen to have links to good "how to get started" guides for
nix+haskell? Right now it looks like it's a battle between halcyon, stackage-
cli and this. I don't quite know yet what fits our use-cases better.

~~~
thinkpad20
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-...](https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-
nixos.html)

------
akurilin
Hey folks, author here. Happy to answer any questions.

Shameless plug: we're hiring. If writing Haskell to improve education seems
like a good idea, check out the role at
[http://functionaljobs.com/jobs/8823-haskell-web-engineer-
at-...](http://functionaljobs.com/jobs/8823-haskell-web-engineer-at-front-row-
education)

~~~
wging
(EDIT:
[https://news.ycombinator.com/item?id=9521076](https://news.ycombinator.com/item?id=9521076)
answers this, sort of.)

Thanks for writing.

What was the CPU issue, and how did you solve it? I'm referring to the
"Strength in numbers" section
([https://github.com/commercialhaskell/commercialhaskell/blob/...](https://github.com/commercialhaskell/commercialhaskell/blob/master/usage/frontrow.md#strength-
in-numbers)).

~~~
akurilin
Check out this thread where I was investigating the issue, it has a lot more
information on it:
[https://groups.google.com/forum/#!topic/yesodweb/LU1r1ygMuOY](https://groups.google.com/forum/#!topic/yesodweb/LU1r1ygMuOY)

------
arocks
> ...the time-tested Real World Haskell is now fairly outdated, but the more
> recent Beginning Haskell is perfectly relevant.

Wow, I was not aware of this.

~~~
gtani
[http://www.amazon.com/Beginning-Haskell-Project-Based-
Approa...](http://www.amazon.com/Beginning-Haskell-Project-Based-Approach-
Apress/dp/1430262508)

Generally a good book, with some puzzling typos, IIRC (a year or so since i
read it), he refers to Platform when he shd be referring to GHC

______________________________________________________________

there's also recent books by Richard Bird and Simon Thompson, and the Haskell
School of Music, which was recently discussed:

[https://news.ycombinator.com/item?id=9487881](https://news.ycombinator.com/item?id=9487881)

[http://www.amazon.com/Thinking-Functionally-Haskell-
Richard-...](http://www.amazon.com/Thinking-Functionally-Haskell-Richard-
Bird/dp/1107452643/)

------
bgibson
Nice review, but don't leave us hanging, in the Strength In Numbers section
what was the root of the CPU utilization problem?

~~~
akurilin
Haven't found it yet. Nobody else is hitting this either apparently. Manually
limiting the # of cores on GHC pretty much removed the issue for us, although
it doesn't give me the sense of closure I was hoping for.

I'm vaguely suspecting some sort of resource contention issue. A good way to
figure that out would be to run a profiled build with that many cores,
assuming that's at all possible.

------
j_m_b
I am curious if anybody has experience using Haskell and clojure/core.typed
and could comment on the two. In the article the author states "You're writing
fewer bugs, you're reusing more code, new developers are causing less damage,
and you have more room to deal with technical debt before it bites you.", I
wonder if the same could be said of projects with core.typed.

~~~
akurilin
Some discussions on the subject:

[http://adambard.com/blog/core-typed-vs-
haskell/](http://adambard.com/blog/core-typed-vs-haskell/)

[http://www.reddit.com/r/Clojure/comments/2hql2h/why_is_coret...](http://www.reddit.com/r/Clojure/comments/2hql2h/why_is_coretyped_supposedly_inferior_to_static/)

------
MBCook
Is be curious to know how big a problem laziness is in real applications. Is
it mostly a non-issue because in a web app things tend to be short requests or
do you end up having to use seq and force strictness in many places?

~~~
implicit
I'm sure it depends on your programming style, but my experience is that you
can almost always ignore laziness and focus on getting your work done.

~~~
akurilin
Haven't run into issues with laziness yet, but, as you guys pointed out, our
use-case is very short-lived. We can likely get away with some sloppiness here
and there because of it. I'm sure I'll still get burned by this at some point,
but at least I'll be expecting it to some extent.

