New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discuss: improving Commercial Haskell #141

Open
snoyberg opened this Issue Dec 11, 2018 · 8 comments

Comments

Projects
None yet
6 participants
@snoyberg
Copy link
Contributor

snoyberg commented Dec 11, 2018

This is a topic for a (at time of opening) not yet published blog post, which will live here:

https://www.snoyman.com/blog/2018/12/improving-commercial-haskell

I'm opening the issue now to help me tie the knot, so I can reference the issue URL before publishing the blog post 😄

@DanBurton

This comment has been minimized.

Copy link

DanBurton commented Dec 16, 2018

I have already voiced the opinion, which I will reiterate here, that I would like for the Commercial Haskell SIG to have a code of conduct. The details of this would be dependent on the organizational structure that is selected for heading the group. If, for example, a committee were selected, then it would be the responsibility of said committee to enforce the code of conduct. I doubt there would be many cases to enforce, but what's important to me is that the structure is there for the cases when it is needed.

I am willing to make a more detailed proposal and argument in favor of a code of conduct, as necessary.

@kaishh

This comment has been minimized.

Copy link

kaishh commented Dec 16, 2018

BDFL model certainly seems to be the most succesful overall looking at other commercially succesful languages

@saurabhnanda

This comment has been minimized.

Copy link

saurabhnanda commented Dec 16, 2018

When I was intiially investigating Haskell for my company, I was delighted to find the IHG and Commercial Haskell. However, it soon turned to dismay, when I found that both were dead. Would it be possible to introspect on the reason why BOTH efforts didn't take off earlier? If there was any politics involved, it would be best to address it upfront, because it is bound to recur (any collection of humans has some politics - it needs to be managed).

The premise of this proposal is: can and should we do more?

Yes.

Are there additional activities that the Commercial Haskel SIG should be responsible for?

Apart from the ones already mentioned on your blog post, I think there should be some fundraising activity towards specific goals, such as specific GHC or core library development.

Should the decision making process and meaning of membership be clarified?

Yes. Does anyone have any experience with other trade groups, which typically have different level of membership with varying membership fees? How do they function? What're the pros and cons?

@DanBurton

This comment has been minimized.

Copy link

DanBurton commented Dec 16, 2018

Regarding bdfl. In cases like Python and Clojure, the bdfl has control at the level of language design. In this case, the Commercial Haskell SIG does not have that kind of control over the whole direction of the language. Instead, it only has control over initiatives like stack, stackage, intero, specific contributions to ghc, etc. I think the interests of the group are potentially diverse enough that pinning it all on just one benevolent dictator might be overwhealming.

If the SIG asks for donations or dues to fund projects, then donors or dues payers should have a say in the direction of how the funding they supply is used.

@saurabhnanda

This comment has been minimized.

Copy link

saurabhnanda commented Dec 17, 2018

One of the comments on Reddit asks a very pertinent question:

I'm confused. More and better documentation (even commercially-geared) benefits everyone, even non-commercial Haskell users. I'm not sure why this should be hosted on something different from haskell.org or the other official channels. And there are already personal/company blogs for opinionated posts.

@snoyberg

This comment has been minimized.

Copy link
Contributor

snoyberg commented Dec 17, 2018

I think the interests of the group are potentially diverse enough that pinning it all on just one benevolent dictator might be overwhealming.

I'm not the source of the BDFL proposal, and I don't think it's the best option. However, on this specific point, I think there's likely more diversity in needs for the Linux kernel or Python, and they've both succeeded with BDFL approaches. I don't think that's the reason to avoid it.

More and better documentation (even commercially-geared) benefits everyone, even non-commercial Haskell users. I'm not sure why this should be hosted on something different from haskell.org or the other official channels. And there are already personal/company blogs for opinionated posts.

It's about consolidation. I could put all of this content on snoyman.com or yesodweb.com or somewhere else. The idea here is to build up a group of people who have similar enough visions on things and can collaborate. The kind of content I'm talking about would likely be too opinionated for haskell.org, but I'd like it to be a less opinionated source than, say, each person's personal blog.

@AKurilin

This comment has been minimized.

Copy link
Contributor

AKurilin commented Dec 18, 2018

When I was intiially investigating Haskell for my company, I was delighted to find the IHG and Commercial Haskell. However, it soon turned to dismay, when I found that both were dead. Would it be possible to introspect on the reason why BOTH efforts didn't take off earlier? If there was any politics involved, it would be best to address it upfront, because it is bound to recur (any collection of humans has some politics - it needs to be managed).

I'd guess the people there are all heads down working all the time vs spending much time on evangelism. We like the idea of having those SIGs, but then everybody's back to work the next day.

@ntc2

This comment has been minimized.

Copy link

ntc2 commented Dec 20, 2018

More and better documentation (even commercially-geared) benefits everyone, even non-commercial Haskell users. I'm not sure why this should be hosted on something different from haskell.org or the other official channels. And there are already personal/company blogs for opinionated posts.

It's about consolidation. I could put all of this content on snoyman.com or yesodweb.com or somewhere else. The idea here is to build up a group of people who have similar enough visions on things and can collaborate. The kind of content I'm talking about would likely be too opinionated for haskell.org, but I'd like it to be a less opinionated source than, say, each person's personal blog.

I'm always excited about having additional centralized/indexed and up to date Haskell documentation. Blog-posts-as-documentation have several shortcomings that consolidated, community approach could improve on. Namely, blog posts are

  • bad for discoverability (but consolidated indexing could help here);
  • bad for compatibility with specific library versions / blog posts don't evolve as libraries change;
  • bad for outside contributions (many formats, source code not generally available);
  • not type checked.

I would like to see more "working example"-style documentation that is type checked to ensure compatibility with specific library versions. And if the documentation is version controlled, all versions could be available, so that people using an older version of the library could view the corresponding version of the documentation.

One way to achieve type-checked documentation would be to add Tutorial modules directly to the corresponding packages, e.g add a Data.ByteString.Tutorial module to the bytestring package. Another, similar approach, would be to keep the Data.ByteString.Tutorial module in a separate bytestring-doc package, which depended on bytestring. Having separate documentation packages makes it easier to develop the documentation without buy-in from the package maintainers, and also handles the case where the documentation isn't associated with a specific package (e.g. a monad tutorial ...).

Perhaps literate Haskell using Markdown (https://github.com/sol/markdown-unlit ?) would be a good format? Literate Markdown has the benefit that GitHub renders it (but without hyperlinked identifiers), making it very easy for people to contribute simple improvements via the GitHub web editor UI. On the other hand, Haddock doesn't support literate Markdown, which means we don't have an easy way to get hyperlinked identifiers. So, another option is just using traditional Haddock markup, but this has the problem of no easy "preview" functionality on GitHub to see if simple changes are formatted correctly (but misformatted PRs are much better than no PRs).

With this kind of approach, commercialhaskell.com could then provide an index and/or table-of-contents entry point into this tutorial-module style documentation. And package maintainers could also provide links to the tutorial modules in their READMEs.

(Re my biases, I do improve Haskell documentation sometimes:

but I don't blog.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment