[gothrowaway]

It's indefensible to have code that tightly compacted, throwing functions around and not documented.

Don't care if it's Python (basically pseudocode), Javascript, Haskell or Erlang.

For all the time Haskell commenters turn criticism into a Socratic dialog, they could be considering ways to make their code digestable. It's been what, 20 years now?

Not just to non-haskell programmers, but all the haskell programmers I see swarming around threads like these on the internet; you'd think they'd actually be teaming up and collaborating with each other. I can't put my finger on it, I think there's a trend, a feeling, that it's not suitable for programmers focused on achieving business ends. It's more of a hobby thing

Programming in the enterprise means confronting the reality that there are design trade-offs and someone else has to read the code. Haskell programmers seem to go off the deep end trying to pull off a hack of making haskell work a certain way, then its "pencils down", sayonara. The real world doesn't accept that, programs have to be maintained by others.

[lucasdicioccio]

I have a (non-contributor) experience with the PostgREST codebase. It's true PostgREST codebase is not great (lots of long functions, need some work to extract the main program into a library etc.) but the codebase definitely is easy to navigate and modify. For a transient project at work I've asked a dev to evaluate how much work it would be to port PostgREST to MSSQL. My dev had a working proof-of-concept in a few days. The bottleneck was not navigating and patching PostgREST codebase but dealing with MSSQL. We decided to go another route only for the lack of a native MSSQL driver in Haskell: there's an ODBC driver (which my dev used for his PoC) but I don't really trust ODBC+FreeTDS. Hence, we'll write a good-old C# binary with a Microsoft-blessed driver to expose the few ad-hoc queries our own team needs rather than a generic solution for the whole company and we'll move on. In short, I have some data invalidating your argument about the PostgREST code style being indefensible. Although I don't enjoy PostgREST codebase I love the product because it delivers what the website claims. Rather than diminishing the hard work of devs using a throwaway/slandering account, I just reckon that Haskell and "ship it culture" are reconcilable.

[Apaec]

I also did something similar to postgREST for MSSQL in java, not in haskell because of the same driver issues you mentioned. I managed to implement jwt auth pgREST style taking advantage of MSSQL user impersonation though I did jumped into some limitations, for example the lack of enviroment variables in transaction scope in MSSQL forces you to have to declare one db user for an app user.

I have little experience in Haskell despite that it was easy for me to understand the gist of what postgREST does and port it to java.

[mst]

ODBC+FreeTDS is not generally a good idea. Microsoft's ODBC driver works fine though.

https://blog.afoolishmanifesto.com/posts/install-and-configu... explains how to get it going on debian.

[throwme321]

Some lines are indeed atrociously long. No Haskell programmer I know would advocate this. I think the project maintainer should insist on sane code formatting. All the critical lines I checked were from contributors. Other than that, I think the case you are trying to make here is largely imaginary. That is not to say that the project couldn't use some more source level documentation, but that you do not see how not actually knowing the language in syntax and semantic and never having written any code in it could possibly cloud your judgement on the comprehensibility, pretty much says all about your case, if you ask me. (I hope that sentence wasn't to long, if you ask nicely I'll add some documentation)