[TheSmoke]

it might look weird to the foreign eyes but essentially this is just a typed api with 3 routes.

/polls returns an array of Poll. /polls/:question_id returns a Poll. /polls/:question_id/results returns a PollResults.

the thing you call a mess is the combination of type level operators which helps you describe your API which is the essence of functional programming.

[jraph]

It does look weird to the foreign eyes, because it looks nothing like what you may encounter in your life when learning a natural language or math. As a consequence, this notation cannot leverage any intuition at all. You need to learn the syntax. Nothing is explicit and helps you guess if you haven't.

It is telling that this is "just a typed api with 3 routes". Somebody who haven't learned all the specific bits of Haskell (or, for that matter, specific bits of this program that may be overloading strange operators to define routes) won't even start to guess that it's defining routes. They can guess it is defining an API, thanks to the words used at the beginning of the snippet. And even though you told us that it's defining a route, I cannot figure out what it is really doing. It is just not clear.

So, yes, it looks like a mess for the foreign eye. I have no doubt it looks straightforward as soon as you learn Haskell and practice a bit.

Mainstream languages also look gibberish for people who haven't learned programming though. That's also something that we have to humbly keep in mind while, as foreigners who practice other programming languages, we discuss the syntax of Haskell.

[TheSmoke]

> And even though you told us that it's defining a route, I cannot figure out what it is really doing. It is just not clear.

it does nothing. :) that code sample is a description of the API. nothing more. when you're writing programs in a functional way, you describe your computation rather than actually computing it as opposed to imperative languages. imagine summation in math. it is a description rather than computation. you compute the sum according to the description. this API description is exactly the same.

the code in the comment is incomplete which makes it harder for you to figure out. where are the handlers? how do we return responses? i believe the rest of the code is actually mapping the API description to actual handlers.

  server :: Server API
  server = getPolls :<|> getPoll :<|> getResults

  getPolls = queryDBForPolls `andThen` transFormToJson
  getPoll pollId = (queryDBForPoll pollId) `andThen` transformToJson
  getResults pollId = (queryDBForResults pollId) `andThen` transformToJson

i agree with the comments and sentiments which say mathematicians learn and write haskell easier than the rest of us but i will tell you a secret: i'm a high school graduate with no degree at all let alone a math / cs one. i'm using haskell happily but it took way much longer time than probably everybody else. it just takes a bit of focused time and will to learn it.

[scotty79]

> It does look weird to the foreign eyes, because it looks nothing like what you may encounter in your life when learning a natural language or math.

It also looks nothing like what programmer might encounter earlier when learning programming languages.

Actually I think Haskell seems to be a little bit similar to mathematical notations so it might be easier for mathematicians to learn than programmers. Unfortunately they don't really have a business case for knowing Haskell and they learn Python instead.

[dmitriid]

It's also funny (ironic?) how they defend this syntax while bemoaning mainstream languages' syntax.

[jraph]

Mainstream languages probably look very verbose, clunky and ugly to many people who like Haskell-like syntaxes more. I feel this way when looking at a Pascal code.

But they have to keep in mind that this verbosity is a feature and they should not act surprised that many people like it. This verbosity makes many things explicit, and I'll not be the first to think that "Explicit is better than implicit".

Conciseness is also a feature, though.

[pyrale]

> This verbosity makes many things explicit

Sometimes, the verbosity just makes the language verbose. A pythonista will have zero trouble telling you when a block ends, despite not having braces around it.

Verbosity is unrelated to a language's explicitness as this is a semantic decision. It is usually related to syntax, which has other effects.

[dmitriid]

I'm still looking for that sweet middle ground between the two :)