Comment by embwbam | Hacker News Reader

Comment by embwbam | Hacker News Reader

This looks well done, but having used Haskell professionally on multiple web projects, I have to take issue with some of the design choices.

Templating? Haskell provides such a wonderfully clean way to generate HTML via combinators and do notation. You don't need a quasi quoter to get a DSL. See Lucid. All templating does is remove control features (like forM, for example). [1]

They've reinvented common operators. For example, (|>), which is great, I've used it in Elm, but the Haskell version of this is (&) from Data.Function.

These are just a few examples. They're ignoring Haskell conventions to make it more familiar to people coming from other backgrounds, even when the community conventions are strictly better or equal. Rails was a nightmare for me, it was impossible to tell what was a language feature and what came from the framework. I suspect this will equivalently speed up initial development while slowing understanding.

[1] https://mmhaskell.com/blog/2020/3/16/lucid-another-html-opti...

> Templating? Haskell provides such a wonderfully clean way to generate HTML via combinators and do notation. You don't need a quasi quoter to get a DSL. See Lucid. All templating does is remove control features (like forM, for example).

IHP's templating HSX is targeted at people with a react background that are familiar with JSX syntax. In the background it compiles down to blaze-html and can be used together with e.g. forM_ (which we have aliased to forEach). It's just a more familiar syntax on top of blaze html.

Some internal IHP functions are even still implemented with the blaze combinators: https://github.com/digitallyinduced/ihp/blob/master/IHP/View...

> They've reinvented common operators. For example, (|>), which is great, I've used it in Elm, but the Haskell version of this is (&) from Data.Function.

The |> just looks more beautiful to us :) Take a look at the gorgeous expressiveness of this: https://twitter.com/digitallyinduce/status/12990709068542484...

> They're ignoring Haskell conventions to make it more familiar to people coming from other backgrounds,

Yes, IHP is the haskell framework for builders :-)

> IHP's templating HSX is targeted at people with a react background that are familiar with JSX syntax. In the background it compiles down to blaze-html and can be used together with e.g. forM_ (which we have aliased to forEach). It's just a more familiar syntax on top of blaze html.

Ok, but then your users will write views without understanding what they're doing. All the magic will make them feel confused and powerless when they do anything outside of the blessed path. They can't extrapolate that forM_ works for any monad in the future.

> The |> just looks more beautiful to us :) Take a look at the gorgeous expressiveness of this

Agreed, I wish we all used |> instead of &, but that operator is called & in Haskell. You're crippling your users' ability to read other code-bases in the future. And that same code would be plenty readable with &, don't you agree? Your example doesn't even show your operator, you're replacing it with a unicode character. I could make vim do the same for &.

> Yes, IHP is the haskell framework for builders :-)

There's so much more to "building" than the first month of development! Easing someone into the Haskell ecosystem is much more important than helping them get a CRUD app running that they don't know how to customize. Haskell is an order of magnitude more productive for me than other languages (ruby), because of its differences.

> They can't extrapolate that forM_ works for any monad in the future.

To be fair, this is a problem with Haskell as well; forM_ is more properly known as for_, which works with any Applicative, even if it isn't a Monad. :)

> All the magic will make them feel confused and powerless when they do anything outside of the blessed path.

Maybe, but what are the chances they chalk it up to a normal and acceptable learning path?

> They can't extrapolate that forM_ works for any monad in the future.

I think it's important people know that, but how much does it matter for IHP's intended audience?

> Agreed, I wish we all used |> instead of &, but that operator is called & in Haskell. You're crippling your users' ability to read other code-bases in the future

I think this is an important point, but I'm not sure how much it would matter for most.

> And that same code would be plenty readable with &, don't you agree?

Most would assume & means something with boolean and I bet. I find & readable, but even Haskellers on my team didn't really seem to take to it.

> There's so much more to "building" than the first month of development!

People don't really value the long term but default I've found. Then once they have committed to something to a degree, they don't change from it.

If IHP makes it easy enough to get to the point of feeling like one should keep using it rather than starting over...

Maybe the extra learning challenge will feel "normal", worth it, and otherwise motivated.

> Haskell is an order of magnitude more productive for me than other languages (ruby), because of its differences.

I can relate to this, but coming from Python. Others who aren't sold on Haskell by it's usually toured virtues are probably likely to be sold by getting someone spun up to hack away on more quickly.

I find making a lot of these arguments kind of funny since I typically find myself arguing from your position :)

> Take a look at the gorgeous expressiveness of this: https://twitter.com/digitallyinduce/status/12990709068542484...

a: The image is https://pbs.twimg.com/media/Egc0d5KXcAYdskO.jpg

b: That's hideous, especially the doublewidth characters.

c: I didn't even know unicode had east-asian-width=2 duplicates of '←', '→' and '▷'.

d: The string "|>" does not appear in your purported example.

The image is probably using natively supported font ligatures.

seems very likely that it's Fira Code

Reply on news.ycombinator.com