4 ms·

> languages with other features/language constructs than you're used to just seem worthless, complex, without value and foreign to you. Document the Haskell co

> languages with other features/language constructs than you're used to just seem worthless, complex, without value and foreign to you. Document the Haskell code and not stuff so much logic into one line. I think that's a fair thing to ask for in software engineering. Anyone who complains about Haskell seems to have either a.) not programmed it b.) weren't programming "correctly" c.) a xenophobe/blub/NOS I know what lambdas are, I know there are functions and folds. That in and of itself doesn't tell the story of the data that's actually being manipulated and the expected output. So that's why you have a 20-30 line comment block explaining what's going on in important API functions. You could program python, JS or ruby similarly; wrapping multiple functions on the same line until you have to actually trial each function to figure out why your not getting an expected result. It feels clever, at the moment, but we don't do it because we're not helping colleagues understand it. > You're not willing to learn the language because you don't understand it, and dismiss the language as having no value because you don't understand it. Is that really fair without at least having a basic understanding of the language? The commenter was heralding the project as a "great example" of "real-world haskell" and recommended contributing to it. I was shocked to see 8k stars and a paltry 50 contributors; of which, only the top 10 have contributed over 100 lines of code. That's half the contributors, proportionally, to something like neovim or redis, and even worse compared to node.js projects. And, I looked at the code of the project, which is open source, and didn't see code documentation. I'm trying to be generous. My advice: stop packing the code so close and document it, probably more than normal, since the symbology in their is highly dense.

ruslan_talpa 10y ago
Here is a project with about the same number of stars/contributors/contributors with more then 100 lines/time since release https://github.com/graphql/graphql-js/graphs/contributors?from=2015-06-28&to=2017-03-25&type=a https://github.com/graphql/graphql-js/graphs/contributors?fr... :) So by your logic, i could say: "If this considered a real world javascript/node, it's no wonder there's not a lot of people using it." which is obviously wrong. You are using the wrong metrics to judge the language popularity. Virtually every OSS project has only a handful of core contributors. PS1: Note that i am not arguing PostgREST is a great example of real world haskell, it's not for me to say since i have bias :) PS2: You are right that the source code is not commented and it could use a little of that but what you are missing (because you are not used to haskell) is that a lot of the documentation for haskell projects comes from the types and type signature of the functions. So just by looking at that, in a lot of cases, a haskell programmer can reliably tell what the function is doing without any documentation
- gothrowaway 10y ago
  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 10y ago
    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.
    - 10y ago
cgag 10y ago
It's not like putting the code on one line. It's like complaining about using map instead of a for loop but you don't know the abstractions. There's a line of too much abstraction, and lots of.haskell code crossed it, but the postgres code ive looked at doesn't seem to suffer from it. Also I really hate the types are documentation people, but I mean it's hard to argue with it for asking about what transformation is happening. Edit: also if be surprised if those numbers are all that bad if you consider the size of the codebase but yeah it's hard to get contributors to a Haskell code base.

ruslan_talpa 10y ago

Here is a project with about the same number of stars/contributors/contributors with more then 100 lines/time since release https://github.com/graphql/graphql-js/graphs/contributors?from=2015-06-28&to=2017-03-25&type=a https://github.com/graphql/graphql-js/graphs/contributors?fr... :) So by your logic, i could say: "If this considered a real world javascript/node, it's no wonder there's not a lot of people using it." which is obviously wrong. You are using the wrong metrics to judge the language popularity. Virtually every OSS project has only a handful of core contributors. PS1: Note that i am not arguing PostgREST is a great example of real world haskell, it's not for me to say since i have bias :) PS2: You are right that the source code is not commented and it could use a little of that but what you are missing (because you are not used to haskell) is that a lot of the documentation for haskell projects comes from the types and type signature of the functions. So just by looking at that, in a lot of cases, a haskell programmer can reliably tell what the function is doing without any documentation

gothrowaway 10y ago
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 10y ago
  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.
  - 10y ago

cgag 10y ago

It's not like putting the code on one line. It's like complaining about using map instead of a for loop but you don't know the abstractions. There's a line of too much abstraction, and lots of.haskell code crossed it, but the postgres code ive looked at doesn't seem to suffer from it. Also I really hate the types are documentation people, but I mean it's hard to argue with it for asking about what transformation is happening. Edit: also if be surprised if those numbers are all that bad if you consider the size of the codebase but yeah it's hard to get contributors to a Haskell code base.