Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Dead-Simple Web Stack in Haskell

williamyaoh.com

Post reply on HN
Print view View original

111–120 of 120 posts

Re: A Dead-Simple Web Stack in Haskell

#111

Post by parliament32 »

seangrogg wrote: post #109
lhorie wrote: post #71

Earlier quoted context omitted.

Eh, that's not a great example. It can be hard to appreciate the simplicity of PHP when one's fully bought into the stockholm syndrome of another language/framework :) Consider this: a hello world in PHP requires no knowledge of programming whatsoever: a file saying "hello world" is enough to get the text to show on a browser. Having two different pages requires no knowledge of if statements, nor of 404 handling. On…

> It can be hard to appreciate the simplicity of PHP when one's fully bought into the stockholm syndrome of another language/framework :) I used to use PHP and I haven't touched Node.js in quite some time as I've been playing with Rust/(Rocket, Actix Web) and Go's standard lib. So... :) > Consider this: a hello world in PHP requires no knowledge of programming whatsoever: a file saying "hello world" is enough to get…

Nitpick but:

>that Apache server isn't going to install and start itself

Yeah it is, you just check the "web server" box during the Debian installation.

Re: A Dead-Simple Web Stack in Haskell

#112

Post by defanor »

_hardwaregeek wrote: post #104
defanor wrote: post #100

Earlier quoted context omitted.

That documentation indeed could be improved, but I guess the intention here is that basic usage is learned from the tutorials. Though it's possible to figure from that documentation alone as well (I'm reading it for the first time too, but using Haskell often): Path construction collects types of arguments into xs, then HVectElim (heterogeneous vector eliminator, or maybe "elimination") unwraps it into an appropriate…

Basic is the key issue here. Sure I can type this out and get a simple program working (although if I make a transcription error, I'm not super sure I can reason through the code). But if I want to build anything beyond the basic, I can't rely on the three whole tutorials on Spock^[1]. I need to start understanding the library. But at that point reading the docs is pretty frustrating. Even with your explanations, I c…

Longer names can be seen as unnecessary and duplicating information. One has to balance between being verbose and laconic when it comes to naming in general, but judging by the lack of annotations in this case, not much care was put into it being easily readable. It may be useful to report it, once that's an issue: chances are it just seemed obvious to the author, as it also often happens to code in general, and acceptable to users.

If you see an insufficiently documented and/or straightforward API, and there's no good reason to use that one in particular, I think it may also be a good idea to look for alternatives, in any language.

> how's package management?

I think it's fine, but there are different opinions on how it should be. I prefer a better system integration and shared libraries coming from system repositories (which is usable with Debian), Cabal works fine, Stack seems to be popular, some seem to use Nix.

> Did you guys ever resolve cabal vs stack?

"Resolve" as in choosing a one true way to build/install things? I don't think so, but there is this annual "state of Haskell" survey that includes build tools, which was closed just a few days ago this year (but no results available yet, afaik), though there are the results from last year [1]. "State of the Haskell ecosystem" [2] may be of interest too.

There certainly are imperfections/drawbacks (and/or varying approaches/opinions/preferences), and it may not be a good choice for you for making a dynamic website (I think in many cases the overall best choice is the language one is most fluent in at the time), but my replies were mostly with the "I really want to use Haskell for something useful" sentence in mind: being exposed to worse (or at least less suitable) bits and running into a dead end can be unfortunate in that case.

[1] https://taylor.fausak.me/2018/11/18/2018-state-of-haskell-su...

[2] https://github.com/Gabriel439/post-rfc/blob/master/sotu.md

Re: A Dead-Simple Web Stack in Haskell

#113

Post by 15155 »

girvo wrote: post #55
bad_user wrote: post #28

Earlier quoted context omitted.

Doing PHP programming was my first programming job, lasted for about 3 years. While I agree with you about the allure of PHP, to be honest, I will never choose PHP again or touch any projects that uses PHP. PHP is an awful, obsolete language, patched again and again to make it more modern. It's like wearing an old leather jacket that has been patched repeatedly, yet it still has a nasty smell. This is entirely subjec…

Absolutely none of that takes away from the original comment though. PHP as a language is pretty garbage. PHP’s deployment story and as a concept is pretty interesting, and we’ve dropped it entirely as a community. The reasons why are interesting to explore, I think. The closest to it is something like Node, I guess: install the language, you can wire up an HTTP server with a couple functions, but it’s still lacking…

> The closest to it is something like Node, I guess: install the language, you can wire up an HTTP server with a couple functions, but it’s still lacking the simplicity of PHP there.

How is configuring Apache/mod_php/whatever is used these days easier than require('http')...?

How about the htaccess shenanigans that had to be used to achieve vanity/custom routing?

There's no way the Node stdlib with a hand-rolled path-based router (so as to not require a dependency manager, mimicing PHP - even though npm is packaged) isn't an overall-better story from a simplicity (and performance, and maintainability, and security) standpoint than the Apache/PHP stack.

"Drop a bunch of files into a directory and have a dynamic website" was a romantic idea. Most people probably just use(d) cPanel remotely and WAMP/MAMP.app locally and never needed to configure Apache, but that complexity was definitely still there.

Analogously: Next.js might be the "WAMP/MAMP.app of today."

Re: A Dead-Simple Web Stack in Haskell

#114

Post by girvo »

15155 wrote: post #113
girvo wrote: post #55

Earlier quoted context omitted.

Absolutely none of that takes away from the original comment though. PHP as a language is pretty garbage. PHP’s deployment story and as a concept is pretty interesting, and we’ve dropped it entirely as a community. The reasons why are interesting to explore, I think. The closest to it is something like Node, I guess: install the language, you can wire up an HTTP server with a couple functions, but it’s still lacking…

> The closest to it is something like Node, I guess: install the language, you can wire up an HTTP server with a couple functions, but it’s still lacking the simplicity of PHP there. How is configuring Apache/mod_php/whatever is used these days easier than require('http')...? How about the htaccess shenanigans that had to be used to achieve vanity/custom routing? There's no way the Node stdlib with a hand-rolled path…

Of course the complexity is still there, but using WAMP/MAMP.app is exactly the context I'm thinking about this through :)

I agree that Next.js is making big strides in this direction. I think other scripting languages could do similar, too. I imagine Lua would already have something like this floating around, ready to be packaged up in this way?

Re: A Dead-Simple Web Stack in Haskell

#115

Post by _hardwaregeek »

defanor wrote: post #112
_hardwaregeek wrote: post #104

Earlier quoted context omitted.

Basic is the key issue here. Sure I can type this out and get a simple program working (although if I make a transcription error, I'm not super sure I can reason through the code). But if I want to build anything beyond the basic, I can't rely on the three whole tutorials on Spock^[1]. I need to start understanding the library. But at that point reading the docs is pretty frustrating. Even with your explanations, I c…

Longer names can be seen as unnecessary and duplicating information. One has to balance between being verbose and laconic when it comes to naming in general, but judging by the lack of annotations in this case, not much care was put into it being easily readable. It may be useful to report it, once that's an issue: chances are it just seemed obvious to the author, as it also often happens to code in general, and acce…

The reason I ask about package management is because when I do my annual try-to-use-Haskell-for-real event, I pick either Stack or Cabal, inevitably run into issues with one and have to switch to the other. Plus I've had situations where I tried to install packages and the manager gave me the computer equivalent of a shrug. Contrast that to Cargo which works beautifully and seamlessly out of the box.

However I hold out hope that Haskell is getting better and easier to use. Legitimately, this tutorial's code looks a lot better than what I've seen before. But I'm still dissatisfied with the level of naming and documentation. I get it that the names may have been obvious to the author, but it's a little worrying to me that the author didn't think about this fact when writing the documentation. Plus Spock isn't a young framework. It's my belief that anybody writing a package should know that interface names are designed to be readable and understandable. And these names aren't subtly hard to read. HVectElim just isn't a great name.

That being said, I don't want to just hate on the Haskell ecosystem. I do really find the language fascinating. I just want some better documentation, more tutorials and nicer, unified tooling.

Re: A Dead-Simple Web Stack in Haskell

#116

Post by verttii »

_hardwaregeek wrote: post #115
defanor wrote: post #112

Earlier quoted context omitted.

Longer names can be seen as unnecessary and duplicating information. One has to balance between being verbose and laconic when it comes to naming in general, but judging by the lack of annotations in this case, not much care was put into it being easily readable. It may be useful to report it, once that's an issue: chances are it just seemed obvious to the author, as it also often happens to code in general, and acce…

The reason I ask about package management is because when I do my annual try-to-use-Haskell-for-real event, I pick either Stack or Cabal, inevitably run into issues with one and have to switch to the other. Plus I've had situations where I tried to install packages and the manager gave me the computer equivalent of a shrug. Contrast that to Cargo which works beautifully and seamlessly out of the box. However I hold o…

Stack uses cabal underneath though. What kind of issues are you running into?

Personally I love the language but struggle with all the (necessary) stuff around it. Configs, deployment, dependency management, editor setup, lint, auto-formatting... Everything feels unnecessarily painful.

Re: A Dead-Simple Web Stack in Haskell

#117

Post by _hardwaregeek »

verttii wrote: post #116
_hardwaregeek wrote: post #115

Earlier quoted context omitted.

The reason I ask about package management is because when I do my annual try-to-use-Haskell-for-real event, I pick either Stack or Cabal, inevitably run into issues with one and have to switch to the other. Plus I've had situations where I tried to install packages and the manager gave me the computer equivalent of a shrug. Contrast that to Cargo which works beautifully and seamlessly out of the box. However I hold o…

Stack uses cabal underneath though. What kind of issues are you running into? Personally I love the language but struggle with all the (necessary) stuff around it. Configs, deployment, dependency management, editor setup, lint, auto-formatting... Everything feels unnecessarily painful.

Generally issues where package management just fails. Also it's just overall not ergonomic. I end up installing yet another version of GHC a lot (I believe that GHC version should be handed separately from package versions like rustup/cargo, nvm/npm, rbenv/bundler). But this info could definitely be out of date. I might be due for another try at Haskell

Re: A Dead-Simple Web Stack in Haskell

#118

Post by leshow »

johnday wrote: post #40
leshow wrote: post #36

Earlier quoted context omitted.

That assumes you've got apache set up, or nginx and php-fpm. It also uses the php interpretor. If you had to build a binary like Haskell would, your approach would be different (although you could run haskell in interpreted mode I wouldn't recommend it). It's also kind of unfair because PHP was created for making web pages, Haskell wasn't.

If the lesson is "use languages specifically designed for the use case", then that's a lesson worth learning.

The lesson is you can't compare just the language parts of the setup without taking a holistic perspective. just PHP is not sufficient to make a 'hello world' page, you need an entire web server in the form of apache too

Re: A Dead-Simple Web Stack in Haskell

#119

Post by defanor »

_hardwaregeek wrote: post #117
verttii wrote: post #116

Earlier quoted context omitted.

Stack uses cabal underneath though. What kind of issues are you running into? Personally I love the language but struggle with all the (necessary) stuff around it. Configs, deployment, dependency management, editor setup, lint, auto-formatting... Everything feels unnecessarily painful.

Generally issues where package management just fails. Also it's just overall not ergonomic. I end up installing yet another version of GHC a lot (I believe that GHC version should be handed separately from package versions like rustup/cargo, nvm/npm, rbenv/bundler). But this info could definitely be out of date. I might be due for another try at Haskell

Not sure if it became much better in the past few years; I seem to run into issues less and less often (and all were solvable rather quickly), but it may be simply because of the avoidance of problematic packages and approaches. Here is a bit more of information though:

- Cabal 2 supports Nix-style local builds [1].

- Stack seems to aim very smooth and easy workflow. Though it didn't work well for me when I tried it (I think I had a version that was too old, and was rather appalled by the way they suggest to install a new one, with `curl ... | sh`). And as mentioned above, I prefer the opposite of adding even more layers on top of cabal and using multiple package managers, in part because it introduces more ways for things to go wrong. Likewise with Nix outside of NixOS.

- I used to find Cabal sandboxes helpful, but not using them these days. Different versions of the same package can be installed simultaneously, if it becomes tricky to stick to a single version while using Cabal. And as the last resort one can wipe out the local package database.

- Careful versioning could solve some of the package management and dependency resolution issues, and there is a common package versioning policy [2] (similar to, but not exactly the same as semver), but not everybody follows it (in versioning their packages or in pinning dependencies); one should be careful with packages that don't.

- Minimizing dependencies can be useful for this, among other things. Without keeping an eye on it, one can easily find themselves in a dependency graph with hundreds of packages, often coming pretty much directly from developers (without additional package maintainers keeping an eye on them following any standards or being compatible, though it's supposed to be better with Stack), some of which may misbehave at some point.

- On some systems it is viable to use a system package manager for Haskell package management.

But possibly my experiences are not representative either: as mentioned before, opinions and approaches around it tend to vary.

[1] https://www.haskell.org/cabal/users-guide/nix-local-build-ov...

[2] https://pvp.haskell.org/

Re: A Dead-Simple Web Stack in Haskell

#120

Post by Sharlin »

seangrogg wrote: post #109
lhorie wrote: post #71

Earlier quoted context omitted.

Eh, that's not a great example. It can be hard to appreciate the simplicity of PHP when one's fully bought into the stockholm syndrome of another language/framework :) Consider this: a hello world in PHP requires no knowledge of programming whatsoever: a file saying "hello world" is enough to get the text to show on a browser. Having two different pages requires no knowledge of if statements, nor of 404 handling. On…

> It can be hard to appreciate the simplicity of PHP when one's fully bought into the stockholm syndrome of another language/framework :) I used to use PHP and I haven't touched Node.js in quite some time as I've been playing with Rust/(Rocket, Actix Web) and Go's standard lib. So... :) > Consider this: a hello world in PHP requires no knowledge of programming whatsoever: a file saying "hello world" is enough to get…

No command-line copypasting was required to install a fully functional LAMP (or WAMP!) package.
Post reply on HN