4 ms·

If you want to get a feel of the productivity using Haskell in production start with a simple CRUD app and use IHP (https://ihp.digitallyinduced.com/ https://ih

by fegu 6y ago

If you want to get a feel of the productivity using Haskell in production start with a simple CRUD app and use IHP (https://ihp.digitallyinduced.com/ https://ihp.digitallyinduced.com/) to build it. You will have something usable within a day - GUI and all. Then move further down the rabbit hole from there.

kreetx 6y ago
How about servant, and some popular js framework on top of that? IHP might be putting a lot of effort into the project, but the code generation part... I (personally) don't like that at all. And it's not common practice in haskell.
- hardwaresofton 6y ago
  Second this -- Servant is one of the best examples of server-side haskell there is, and from what I understand IHP is relatively new in comparison (correct me if I'm wrong). Servant is one of the best if not the best example of how haskell's higher level abstractions can benefit practical bread and butter programming (which making APIs is these days) tasks, and where type safety is a huge benefit. Writing servant handlers can also feel mostly imperative depending on how much you use `do`.
- _query 6y ago
  IHP is very opinionated in the way how it approaches building web applications (Code Gen, Project structure, Naming, ..). But exactly this kind of opinionated design makes it possible to be very productive, compared to doing everything yourselves.
  - kreetx 6y ago
    IHP is opinionated in the sense that it does state on the server side and uses (something similar to) turbolinks to make it look fast. But generating additional types for SomeDataType like ViewSomeDataType etc - my gut feeling tells me these should be implemented trough type classes instead. New data types shouldn't be generated for cases like this. Disclaimer: I've only looked at the docs of IHP, but this was what it looked like it was doing.
WraithM 6y ago
I find it extremely frustrating that I have to use Nix to use this framework. We don't use Nix at my company, and we likely never will. I can easily incorporate packages from hackage into our codebase. I really don't want to have to vendor this project myself. Why make a great web framework and then create such a large constraint on who can use it reasonably?
- Geminidog 6y ago
  We use nix in production at my company. It’s horrible. It’s only good for ecosystems that rely heavily on context or libraries installed by operating system package managers. Languages that have self contained package managers like JavaScript, Haskell or python don’t benefit. In fact in those cases nix actually makes things worse by making almost everything way more complex and error prone then necessary as literally nothing is designed with nix in mind.

by fegu 6y ago

kreetx 6y ago

How about servant, and some popular js framework on top of that? IHP might be putting a lot of effort into the project, but the code generation part... I (personally) don't like that at all. And it's not common practice in haskell.

hardwaresofton 6y ago
Second this -- Servant is one of the best examples of server-side haskell there is, and from what I understand IHP is relatively new in comparison (correct me if I'm wrong). Servant is one of the best if not the best example of how haskell's higher level abstractions can benefit practical bread and butter programming (which making APIs is these days) tasks, and where type safety is a huge benefit. Writing servant handlers can also feel mostly imperative depending on how much you use `do`.
_query 6y ago
IHP is very opinionated in the way how it approaches building web applications (Code Gen, Project structure, Naming, ..). But exactly this kind of opinionated design makes it possible to be very productive, compared to doing everything yourselves.
- kreetx 6y ago
  IHP is opinionated in the sense that it does state on the server side and uses (something similar to) turbolinks to make it look fast. But generating additional types for SomeDataType like ViewSomeDataType etc - my gut feeling tells me these should be implemented trough type classes instead. New data types shouldn't be generated for cases like this. Disclaimer: I've only looked at the docs of IHP, but this was what it looked like it was doing.

WraithM 6y ago

I find it extremely frustrating that I have to use Nix to use this framework. We don't use Nix at my company, and we likely never will. I can easily incorporate packages from hackage into our codebase. I really don't want to have to vendor this project myself. Why make a great web framework and then create such a large constraint on who can use it reasonably?

Geminidog 6y ago
We use nix in production at my company. It’s horrible. It’s only good for ecosystems that rely heavily on context or libraries installed by operating system package managers. Languages that have self contained package managers like JavaScript, Haskell or python don’t benefit. In fact in those cases nix actually makes things worse by making almost everything way more complex and error prone then necessary as literally nothing is designed with nix in mind.