Make IHP more haskell-y

[mpscholten]

A while ago Tom Ellis brought this up via email to the haskell foundation:

Dear board,

A few months I came across a post on Reddit that presented an
interesting perspective. It said that

the Haskell community feels boring, full of "why so serious" people,
Clojure/Kotlin/Elixir communities or many other PL communities have
a totally different vibe, more "vibrant"

https://old.reddit.com/r/haskell/comments/1kygyf3/a_break_from_programming_languages/mv6csf6/

I asked for more details and got a very interesting, detailed, response here:

https://old.reddit.com/r/haskell/comments/1kygyf3/a_break_from_programming_languages/mvjjt10/

I think the response is worth reading in full, but to give a taster,
it says that there seem to be fewer "new stuff" announcements for
Haskell than Clojure, the Haskell Interlude is more "bland" (that word
is my interpretatation) than the Clojure podcast, and that "Servant's
website is meh, stuck in time" whereas IHP "doesn't align with what
the haskell community values".

I don't have a particular proposed response, nor necessarily a wish to
start a discussion, but I thought it was an interesting point and I
can see where it's coming from, so I wanted to share.

Tom

We should fix this feedback and make IHP more aligned with normal Haskell - while still keeping the IHP vibes.

The original mentioned reddit comment is very good https://old.reddit.com/r/haskell/comments/1kygyf3/a_break_from_programming_languages/mvjjt10/

[amitaibu]

We should fix this feedback and make IHP more aligned with normal Haskell - while still keeping the IHP vibes.

Do you have examples of this? A significant advantage for IHP is that I was able to get non-Haskell Gizra devs (but with some Elm knowledge) to start working productively on IHP from day one, so we should be careful with introducing too advanced concepts 😄

[unhammer]

On the positive side, IHP is mentioned as Haskell's answer to Phoenix :-)

Also if the community "feels boring", do we really want to align with that? 😛 I find IHP quite fun, and love the focus on features and developer experience over "just" safety/abstraction. So IHP certainly aligns with my values, and I think it would be good to play to IHP's strengths, perhaps taking some inspiration from how Phoenix is marketed and developed.

That said, I'm guessing the "integrated" part of IHP, being a "framework", is a big reason some haskellers feel like IHP doesn't quite align with their values. I think breaking it up into several libs was a good step here, as well as support for lucid instead of blaze, and different CSS frameworks. There have also been some related issues opened, getting a solution to these might make IHP more palatable to those who are on the fence:

• https://github.com/digitallyinduced/ihp/issues/2075
• https://github.com/digitallyinduced/ihp/issues/131

if they can be solved without inconveniencing the default/core use.

[mpscholten]

Do you have examples of this?

Some small thoughts:

• Using our controller context instead of wai vault
• Using exceptions for control flow (e.g. render throws an exception instead of returning a value)
• No good support / use of middleware's
• our login functions could be a dedicated wai middleware instead of being IHP specific
• use cabal for managing haskell dependencies (this would improve support for Haskell language server and haskell listing tools) (but still using nix)

On the positive side, IHP is mentioned as Haskell's answer to Phoenix :-)

Yes 😄

I think breaking it up into several libs was a good step here, as well as support for https://github.com/digitallyinduced/ihp/pull/2055, and different CSS frameworks.

Exactly 👍 General we need IHP to compose well with the existing haskell library ecosystem (e.g. the whole wai ecosystem). Breaking it up into libraries had no real impact on IHP being "integrated" so far. So that shows we can do it without loosing the IHP way :D

[unhammer]

Nice list of challenges. TIL about wai vault / https://www.yesodweb.com/blog/2015/10/using-wais-vault

[mpscholten]

In https://github.com/digitallyinduced/ihp/pull/2149 I tried removing ApplicationContext with Vault and it's working great 👍

[mpscholten]

Another PR in this direction: https://github.com/digitallyinduced/ihp/pull/2150

[Montmorency]

Great list of positive directions. I think this one is a great idea to tackle early:

• use cabal for managing haskell dependencies (this would improve support for Haskell language server and haskell listing tools) (but still using nix).

That would help IHP align with broader haskell ecosystem and as pointed out before would open up some of the potential for making it easier to profile and improve different aspects of the framework and leverage some of the work that has gone into cabal packaging and might introduce IHP users to and they can begin contributing custom libraries according to community standards.

The nix integration is a super power. IHP has used it since the beginning and now the development and deployment story is really really good (continued regular caching of latest ihp packages/dependencies binaries and aligning with cabal/nixpkgs will probably help this even more).

Commercially there is a huge advantage to being able to deploy not just your app but a full system closure with configuration and secrets declaratively (the vanilla nix and the det-sys nix linux-builders are a huge help to anyone working on macos). The development environments can also be shared instantly between developers you can rollback and pin versions and deployments and it really gives you a multiplying factor on managing applications in production.

I'm really not sure exactly what it means "doesn't align with what the haskell community values". I guess the points Marc mentioned, particularly exceptions, and also, I guess, people have strong views on the use of implicit parameters and doing too much (anything?) in bare IO.

For me, IHP has been a great bridge between having a prepackaged nix powered web framework ready to go with lots of practical patterns and convenience functions, and being able to bring in "haskelly" libraries developed in an academic context e.g. sql-list comprehensions, fgl, uu-parsinglib, arrows... all of these libraries/concepts have been integrated in different IHP projects and used commercially (the end user has no idea but its fun for the developer 😄).

Users may prefer to interact with different databases in different ways e.g. it would be interesting to try e.g. opaleye with ihp-hsx blocks but I think this shouldn't be too far off with the general unraveling of packages.

I think IHP is doing a good job of being an "integrated haskell platform". As it becomes leaner and modular users can build off it and swap in new packages, language extensions, middleware etc. If users can do this and continue to rely on quality documentation and community support I think more and more companies and developers can feel confident adopting it as part of their technology stacks.

[CSchank]

I would like to echo the above and say that 99% of the issues we've had with IHP have come from Nix. To be fair, I am pretty inexperienced with Nix. But I have never had nearly this many issues with cabal/Stack in other Haskell projects. I'd say Nix is my biggest pain point. I also see its strength, but I think I've spent much more time fighting with getting Nix working on our devs' systems and Codespaces than it has saved me.