2 ms·

IHP is really optimized for getting stuff done and shipped very fast. There are many existing haskell frameworks already that give you lots of options and make

by _query 6y ago

IHP is really optimized for getting stuff done and shipped very fast. There are many existing haskell frameworks already that give you lots of options and make you decide on everything. We try to have a single standard way of doing things to allow you to focus on actually building things instead of solving technical problems. This standard setup allows us to also e.g. offer a standard deployment process: https://twitter.com/digitallyinduce/status/1313410469785407488 https://twitter.com/digitallyinduce/status/13134104697854074...

q3k 6y ago
I do understand that, and I do want someone to hold my hand when it comes to Haskell library choices :). But it would be nice to be able let me replicate all the deployment/development setup aspects in a style that doesn't have an impedance mismatch with existing projects (especially monorepos!). It's fine if it occasionally breaks, it's unsupported, without warranty, I'm on my own, etc. Just let this be an option for people with Opinions on deployment/build systems, but no such Opinions on Haskell software engineering.
croh 6y ago
Please don't get it wrong,but I never understood 'getting stuff done and shipped very fast'. You can't get stuff done, if you don't understand. Too much magic works good for typical 'hello world' apps, but when things go south, it adds significant delay in debugging/fixing.
- nine_k 6y ago
  Why, they do understand. They just have made an opinionated framework that decides a lot of things for you. You can't reconfigure that, but also don't have to. A framework is best used when you go with the flow, build something similar to what the authors had in mind, and don't mind their particular technical decisions. You concentrate on getting "stuff", that is, business logic, done. The more flexibility and precision you need, the better choice a set of libraries becomes. It offers no handholding, and assumes you know what you're doing — but that's what you were after with all these "let me decide myself" requests, weren't you?

by _query 6y ago

q3k 6y ago

I do understand that, and I do want someone to hold my hand when it comes to Haskell library choices :). But it would be nice to be able let me replicate all the deployment/development setup aspects in a style that doesn't have an impedance mismatch with existing projects (especially monorepos!). It's fine if it occasionally breaks, it's unsupported, without warranty, I'm on my own, etc. Just let this be an option for people with Opinions on deployment/build systems, but no such Opinions on Haskell software engineering.

croh 6y ago

Please don't get it wrong,but I never understood 'getting stuff done and shipped very fast'. You can't get stuff done, if you don't understand. Too much magic works good for typical 'hello world' apps, but when things go south, it adds significant delay in debugging/fixing.

nine_k 6y ago
Why, they do understand. They just have made an opinionated framework that decides a lot of things for you. You can't reconfigure that, but also don't have to. A framework is best used when you go with the flow, build something similar to what the authors had in mind, and don't mind their particular technical decisions. You concentrate on getting "stuff", that is, business logic, done. The more flexibility and precision you need, the better choice a set of libraries becomes. It offers no handholding, and assumes you know what you're doing — but that's what you were after with all these "let me decide myself" requests, weren't you?