4 ms·

I've tried this out a few days ago. I have some basic theoretical Haskell knowledge, but not much practical experience. However I do have some significant Nix e

by q3k 6y ago

I've tried this out a few days ago. I have some basic theoretical Haskell knowledge, but not much practical experience. However I do have some significant Nix experience. Ended up not even going through the beginner tutorial, as the installer/scaffold process required me to do things that I didn't like: - forced scaffolding of projects with some quite blackboxy generated shell scripts inside - use of nix, yet requiring me to install 'make' and 'direnv' system-wide (why? just let me use a shell.nix) - required me to use cachix.org as a system-wide nix substituter, which I don't want to do for security reasons (just allow me to build everything myself) All in all this looked promising, but ended up being too magical for my taste. I'd like to be able to start using IHP 'from scratch' instead - with my own Cabal/Nix/Bazel build machinery. This is a critical requirement for libraries/frameworks that I use. Your mileage may vary though - if you're okay with RoR-like scaffolding and blackboxness, then you might feel at home here, and at least you get a nicely typed language in return.

the_french 6y ago
I think replicating RoR in Haskell is explicitly the goal of IHP. I don't have a problem with them making opinionated choices for projects, I really don't want to have to wade through library choices and configuration each time I start a project. Granted I started out as a Rails dev...
- q3k 6y ago
  > I really don't want to have to wade through library choices and configuration each time I start a project. I think this is a false dichotomy. You certainly can have an opinionated way to setup a project that 90% of people use at first, with some way to customize things as you go along, or at least a way to replicate the standard setup with whatever tooling is more conducive to the user's vision. Flask is a good example of this. You start out with a minimal single-file app, with a somewhat magical tool (`flask`) that will take care of starting a debug server for you and whatnot. As you go along, you can grow your app according to the official manual ('project layout', 'growing big' manual pages, using blueprints and application factories and other typical Flask patterns), or you can do something that fits more to your existing codebase. You can also keep using the `flask` tool, or write your own equivalent. Or skip it entirely and express everything as Python scripts. Even with the quite more complex and scaffoldy Django, you're very much able to rejigger a scaffolded app easily into whatever structure you want, as long as you're ready to dust off the “Forbidden PYTHONPATH and DJANGO_SETTINGS tricks” book.
_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?
kccqzy 6y ago
I wholeheartedly agree. I do not like projects who assume they get to dictate my build process, my environment, or my system configuration. Just ship code, and let projects integrate your code in whatever way they are used to. That way, the marginal cost of introducing a new component into an existing system is really low, not to mention a much gentler learning curve.
- platz 6y ago
  what do you think of rails?

by q3k 6y ago

the_french 6y ago

I think replicating RoR in Haskell is explicitly the goal of IHP. I don't have a problem with them making opinionated choices for projects, I really don't want to have to wade through library choices and configuration each time I start a project. Granted I started out as a Rails dev...

q3k 6y ago
> I really don't want to have to wade through library choices and configuration each time I start a project. I think this is a false dichotomy. You certainly can have an opinionated way to setup a project that 90% of people use at first, with some way to customize things as you go along, or at least a way to replicate the standard setup with whatever tooling is more conducive to the user's vision. Flask is a good example of this. You start out with a minimal single-file app, with a somewhat magical tool (`flask`) that will take care of starting a debug server for you and whatnot. As you go along, you can grow your app according to the official manual ('project layout', 'growing big' manual pages, using blueprints and application factories and other typical Flask patterns), or you can do something that fits more to your existing codebase. You can also keep using the `flask` tool, or write your own equivalent. Or skip it entirely and express everything as Python scripts. Even with the quite more complex and scaffoldy Django, you're very much able to rejigger a scaffolded app easily into whatever structure you want, as long as you're ready to dust off the “Forbidden PYTHONPATH and DJANGO_SETTINGS tricks” book.

_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?

kccqzy 6y ago

I wholeheartedly agree. I do not like projects who assume they get to dictate my build process, my environment, or my system configuration. Just ship code, and let projects integrate your code in whatever way they are used to. That way, the marginal cost of introducing a new component into an existing system is really low, not to mention a much gentler learning curve.

platz 6y ago
what do you think of rails?