Live data from Hacker News

A Dead-Simple Web Stack in Haskell

williamyaoh.com

81–90 of 120 posts

Re: A Dead-Simple Web Stack in Haskell

#81
post #32

Earlier quoted context omitted.

I entirely agree about the language itself being a comfortable middle weight, somewhere around the order of Python. But both languages give you a lot of scope to make things complicated and there are much stronger norms against making code as clever as possible in Python than in Haskell. Is there a Pythonic Haskell movement? Because if there isn't there should be.

There is this great talk 'stick to simple Haskell' along those lines, but unfortunately it is hosted here https://skillsmatter.com/skillscasts/14133-stick-to-simple-h... Unfortunately I can't find it anywhere else, but it is worth keeping your ears out in case it pops up somewhere..

The link doesn't work.

Re: A Dead-Simple Web Stack in Haskell

#82
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…

> a file saying "hello world" is enough to get the text to show on a browser Wrong. A file saying "hello world" does not even serve its contents through HTTP on port 80, contrary to the node.js-example you are arguing against. Good luck setting up that Apache monstrosity (as it was common back then) without any "programming knowledge whatsoever". But yeah, I guess your mentioned stockholm syndrome is a thing for PHP…

It sounds like you've never actually used PHP. Even way back when, you could pick from multiple pre-packaged solutions (XAMPP, WAMP, etc). In windows, the installer was a no-brainer click-through wizard, much like any other random software you'd find on sourceforge or whatever. And not only it would setup apache, but also mysql. Then you could click a button to turn on PHP (so no need to type anything in terminal either). You could also get hosting and upload your PHP files via a browser interface to put your hello world live on the web without ever typing any "code" other than the text "hello world" on a index.php file in notepad. Not even knowledge of version control was required for this form of deployment (though, of course, you can also follow standard industry best practices like with any other mainstream language).

Re: A Dead-Simple Web Stack in Haskell

#83
Let's walk through my thoughts.

Hmm, okay so Spock looks nice. Neat! The routing code looks very easy to read:

  main = do
    spockCfg Hello world!"
      get "users" $ do
        Spock.json (A.object [ "users" .= users ])
      get ("users"  var  "friends") $ \userID -> do
        Spock.json (A.object [ "userID" .= (userID :: Int), "friends" .= A.Null ])

Alright, let's figure out how this works.

  runSpock :: Port -> IO Middleware -> IO () 
Okay that makes sense. Takes in a port, some middleware and spits out IO. Not crazy. Hmm, okay these dollar signs are making things a little confusing, but I can figure out that spock returns an IO Middleware and therefore we can see that spock takes the output of the right do block along with spockCfg. Not the easiest to scan at first glance because of the right to left reading but okay.

Let's look at get.

  get :: HasRep xs => RouteSpec xs ps ctx conn sess st 
Ah, okay, so uh...this doesn't appear to be a function. Oh, I see, here it is:

  type RouteSpec xs ps ctx conn sess st = Path xs ps -> HVectElim xs (SpockActionCtx ctx conn sess st ()) -> SpockCtxM ctx conn sess st ()
Well I'm not really sure what xs, ps or st are. And HVectElim doesn't tell me anything. Path is pretty clear and SpockCtxM is a monad of sorts. But what the hell is HVectElim? Alright whatever, let's just figure it out via the signatures of Spock.html/Spock.json. Which are...nowhere to be found in the documentation. I looked them up in the index and nope, no entries. I'm very confused about what HVectElim is and why that would be a fine name.

I can continue past this point, but you get my gist.

This is actually way better than my other experiences with Haskell and web dev, but it's by no means an easy or fun experience reading this code. Variable names like xs, ps, etc. are great when you're dealing with a generic list but they get old when that's the only documentation (because "type signatures are documentation" is totally infallible). And a name like HVectElim is just baffling. What, did they charge you per letter? Did half your keys fall out? Why is that a good name?

I really want to use Haskell for something useful. But I'm running into pain points trying to understand a glorified Hello World. Now granted I'm by no means a great Haskell programmer. But that's kind of the point. I understand monads. I get functors and applicatives. I should be able to write a dumb Hello World app dammit.

Re: A Dead-Simple Web Stack in Haskell

#84
None of that "web stack" is simple. Literally, none.

Am I the only who thinks _every single_ Haskell "developer" suffers a worrying large amount of imposter syndrome? I mean, c'mon. No-one actually cares if you write Haskell or "push lambdas". At the end of the day the only thing that really matter are: 1. Does it run? 2. Is it buggy? 3. Is it cheap?

Re-inventing the wheel for no other reason than to hand-wavingly say "look MA I MADE A WEB STACK" is nothing more than masturbation.

Haskell is a community of cancerous people that should die, along with cancer.

Re: A Dead-Simple Web Stack in Haskell

#85

Earlier quoted context omitted.

> If everything worked so fine and dandy in the good old days, we'd still be there. I'm not a historian, but I'm pretty sure a historian could find a lot of counter examples to statements like this. That includes historians who know an aweful lot about programming languages.

Oh yeah. Take consumer goods got example: A straight razor or double edge safety razor and a bar of soap work an awful lot better, cost the customer significantly less, and produce far less waste than modern mass-produced shaving convenience goods at the expense of greater initial costs and a modest increase in required skillset. A fountain pen with a hand-tuned gold nib is refillable and can last nearly a lifetime w…

Try the EZ Duz It can opener. It’s basically the old SwingAway before they sold the name to a maker of cheap openers.

Re: A Dead-Simple Web Stack in Haskell

#86
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…

> a file saying "hello world" is enough to get the text to show on a browser Wrong. A file saying "hello world" does not even serve its contents through HTTP on port 80, contrary to the node.js-example you are arguing against. Good luck setting up that Apache monstrosity (as it was common back then) without any "programming knowledge whatsoever". But yeah, I guess your mentioned stockholm syndrome is a thing for PHP…

Sure it does.

    php -S localhost:8080
It's that easy. For both node and PHP (and any other server), you will end up with more plumbing in production anyway. For example, having a load balancer, cache or other ingress in front of the service. These kinds of universal network layer functions (which I'd argue even include authorization and authentication) should not be part of your code anyway, but part of the network infrastructure (k8s and OPA e.g.)

Re: A Dead-Simple Web Stack in Haskell

#87

I think a simple web stack should aspire to the simplicity of the PHP stack, twenty years ago: 1) Create a directory "foo" on your server 2) Make a file called "bar.php" in that directory 3) Write "Hello World!" in the file 4) Open http://localhost/foo/bar.php in the browser and see "Hello World!" Lines of code or configuration so far: zero . 5) Add some actual code to bar.php 6) Reload the page and see the result Nu…

It is intriguing that nobody's replicated PHP's ease of deployment. Every other language does require downloading some sort of runtime and setting up some sort of templating/page serving system. Would be an interesting experiment to start with essentially an HTML generating DSL like PHP, but with more modern language design.

They tried with Java (Tomcat/JSP) which from memory wasn't that bad to setup, and I even remember trying a Perl variation where you inlined Perl code instead of PHP, but the name eludes me right now.

I guess PHP just had that first mover advantage. Don't forget that a lot of the simplicity is because your average shared hosting provider has already installed it for you.

Re: A Dead-Simple Web Stack in Haskell

#88
post #36

I think a simple web stack should aspire to the simplicity of the PHP stack, twenty years ago: 1) Create a directory "foo" on your server 2) Make a file called "bar.php" in that directory 3) Write "Hello World!" in the file 4) Open http://localhost/foo/bar.php in the browser and see "Hello World!" Lines of code or configuration so far: zero . 5) Add some actual code to bar.php 6) Reload the page and see the result Nu…

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.

To the point. It is very naive to ignore the fact that the work was just outsourced to an IT guy. And the world in which Haskell, Java, JavaScript or .NET can deliver the same "simplicity" of PHP is just called Function as a Service/Serverless (just that this needs some more years before simplicity is actually reached).

Ok, a bit stretchy ;)

Re: A Dead-Simple Web Stack in Haskell

#89
My take on the whole "complex versus non complex" debate raging below.

If there were nothing to the exorbitant complexity, there would be no complaints about modern stacks. It would be sort of, invisible? Like an OS is mostly invisible these days - that problem space is mature to the point that its, for most people, an afterthought.

So modern web dev does suck, yes. I am 100% of this opinion.

But the simple solution was re-invented into the 'mess' we have today. It doesn't scale (well), and although yes it wasn't complex it was a hell of a lot more complex to add features to, at least ones which weren't simple "hey change the look and feel of some widget" or "hey do some flashy UI thing".

I think that's probably a generally true statement, when a lot of work is needed to develop something (physical or otherwise), it will suck, because it still needs to be worked on? So anything being used by the industry and "modern" will have pain points, period.

Once its actually good, it tends to be simplified to the point that it becomes invisible. OFC, you can still use WAMP or whatever, or weebly, but nobody cares about WAMP or weebly anymore, outside of whatever small pet project or blog you run.

Re: A Dead-Simple Web Stack in Haskell

#90

Earlier quoted context omitted.

> a file saying "hello world" is enough to get the text to show on a browser Wrong. A file saying "hello world" does not even serve its contents through HTTP on port 80, contrary to the node.js-example you are arguing against. Good luck setting up that Apache monstrosity (as it was common back then) without any "programming knowledge whatsoever". But yeah, I guess your mentioned stockholm syndrome is a thing for PHP…

Sure it does. php -S localhost:8080 It's that easy. For both node and PHP (and any other server), you will end up with more plumbing in production anyway. For example, having a load balancer, cache or other ingress in front of the service. These kinds of universal network layer functions (which I'd argue even include authorization and authentication) should not be part of your code anyway, but part of the network inf…

> Sure it does.

> php -S localhost:8080

Ok, are we talking about single files now or command line commands? Make up your mind.

Post reply on HN