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..
A Dead-Simple Web Stack in Haskell
81–90 of 120 posts
Re: A Dead-Simple Web Stack in Haskell
#82Earlier 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…
Re: A Dead-Simple Web Stack in Haskell
#83Hmm, 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
#84Am 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
#85Earlier 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…
Re: A Dead-Simple Web Stack in Haskell
#86Earlier 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…
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
#87I 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.
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
#88I 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.
Ok, a bit stretchy ;)
Re: A Dead-Simple Web Stack in Haskell
#89If 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
#90Earlier 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…
> php -S localhost:8080
Ok, are we talking about single files now or command line commands? Make up your mind.