[Call for Ideas] Forming a Technical Agenda

Haskell Foundation
#27

Not sure if this is ‘techincal’?

Most of the people I recommend Haskell to get bogged down trying to get started with it. I think this is mostly because the content on www.haskell.org .

I would add an opinionated getting started guide. The two links from the home page are ‘Downloads’ and ‘Documentation’. Both are very information overload and don’t provide a clear ‘what to do next’ if you want to dabble with Haskell.

This would mean telling the user to just use stack or cabal. I would just pick one and give the steps needed, then perhaps at the end say ‘oh there is also this other tool you may want to check out’. A beginner doesn’t care about which tool to use, they just want to get the fun.

I would suggest it should include:

  • Installing ghc + stack / cabal
  • Running some haskell in ghci
  • Setting up a project
  • Installing a dependency
  • An example app that does something ie. hits twitter api. The user could tweak it in some simple ways?

The ultimate goal is to get the user to have clear instructions to follow to get a feel for Haskell and to have fun.

11 Likes
#28

Are you using GHC 8.10.3 or later? These issues should be largely solved thanks to @angerman’s RPATH mangling logic. If you are still seeing them then please open a ticket.

Good tip, thank you! This was just brought up yesterday based on your response here. We’ll give it a shot and report back as needed.

#29

There have been a bunch of really great suggestions, so I’ll let my list overlap to add voices and votes to those:

  • Clean up base and other core libraries, especially with laziness, partial functions, correctness, improved types and data structures, less Stringly-typed junk in core.
  • Drastic improvements to compilation speeds and memory use: big projects are difficult to work on, and advanced, FP-ninja libraries make real-world projects of significant complexity unusable (just the build times and build system requirements alone).
  • Drastic improvements to GHC errors and warnings.
  • Drastic improvements to GHC memory handling and GC characteristics, we leak too much and have to think too hard (lots of reasoning about what happens at runtime, not very declarative…)
  • Protecting/sandboxing against evil Template Haskell, seems like a really smart thing to do… and maybe before it winds us up on the front page news.
  • Improve onboarding, work with doc team to scope out best-practices for an authoritative tutorial demonstrating how to do common, real-world tasks (work with cli, files, HTTP services). Help define the recommended way for onboarding, and how to find / follow tracks thru to advanced topics.
  • Probably a long shot, but unifying hackage/stackage would be nice… can we find a way forward without being blocked on the PVP? Also, considering what’s in Stackage and how it works, seeing Rebecca’s call for improved hackage security makes me sad. Changing an already published package for the sake of PVP idealism is not a hackage feature, it undermines security and violates the trust package publishers extend to the package infrastructure admins.
3 Likes
#30

Cloud Haskell is dying, revive Cloud Haskell.

2 Likes
#31

I think the number one thing could be to lower friction in finding related information. Sure there is google, but some topics they take a long time to investigate and then there is no place to write about the findings (for example which library to choose A, B or C). You can put it on a personal blog sure. That would be one more place on scattered resources over the internet. Would be cool to start thinking of a platform (= website) that make it easier to discuss / add information. The way realworld haskell does it with inline comments is really cool. But also just general wikipedia style is useful.

Some concrete ideas how this could materialize:

  • Try to unify user accounts to become one “haskell” account. gitlab, wiki, hackage, discourse … as much as possible. Also helps moderating of content.

  • Open up new (forum) threads in the documentation on hackage.org on a: package, module, function etc … This would show as a not annoying button (again: like realworld haskell does it: “17 comments”).

  • Would be nice if comments can get likes (upvote). And then just show the comment by default when it gets enough upvotes (deemed to be important enough).

  • Also nice if packages, modules and functions can get likes, in a subtle way like reddit marks upvotes next to posts. The we can sort these things by likes so people know what others are using.

  • Allow people to open up guides (the kind of guide that they would put on a personal blog post). Does not need to relate to a single package or so. (either write protected or as wiki page, configurable). This could be as easy as having an official git repository where people can PR new markdown files which then will be generated on html page.

  • Have a way to link things together. Thing is if you just paste an http link in a comment to some other function it doesn’t link back automatically. Would be nice to have something like github “this function has been mentioned in …”. This would likely require some analysis (of code as well) + database (possibly graph structure).

I think this idea is worthy of haskell foundation because it spans over multiple concerns and working groups, which will be too difficult to carry out for a single person or company even. It’s technically a bit boring to implement, but very feasible. I like it because it will compound value over time as people are more discussing and contributing. Maybe this is not obvious to GHC maintainers or library authors … but the barrier to change some documentation is very high. Which is good in principle (to keep up quality), but next to that there is no low friction way available (or it’s in a corner of the internet where it is hard to find).

Second thing it would be nice to have a way to stay backwards compatible but not to be stuck with legacy decisions that are hard to change. For example the situation with prelude. There are alternative preludes sure, but no sight in community concensus or a way to move this forward. What rust did with the 2018 edition of the compiler was very interesting, it allowed users a choice to stay backwards compatible or flick the switch deprecating old functionality. I’m not sure how to solve this though. Having some people inventing yet another alternative prelude does not seem the way to go as this has been tried before many times. I guess the best way to start would be to have a good comparison between existing preludes, and possible even on a fine grained level (like a function), so things could reach concensus one stone at a time. The concensus thing people have been doing among each other in discussion threads on github. But it would need a bigger support with both moderation of the discussion and also a technical solution how to choose prelude out of the ghc box.

Personally i find these issues more interesting than improving a tool or getting % of compiler performance. People can (and did) take it onto themselves to make a tool or fix a performance bug. I also like a faster GHC, but there is something to be said for starting with things that can not be solved without haskell foundation.

2 Likes
#32

edit I have moved this post to a new thread since it opens a can of worms which is somewhat orthogonal to the present discussion.

The matter of the amending or adding to the base library has come up a fair amount in this discussion. While such changes are of course possible, I do wonder whether this is the best solution to the problems that users feel.

…

Towards a prevalent alternative prelude?
#33

{Moved to new thread}

#34

@hgolden, great points; could we move this discussion to the new thread?

#36

There’s no “move” mechanism as far as I know. I think it’s best just to repost it on the new thread and edit your existing post with a link to the next post.

#37

tl;dr I think the Haskell Foundation should focus on low-hanging fruit (namely documentation and guidelines) for most of the problems outlined in @ozataman’s original post, rather than focusing its effort primarily on technical improvements to GHC.

Definitely this!! Sure we can improve GHC in many ways but I don’t believe it will improve Haskell adoption.
My opinion is that the priority to lowering the entry barrier is by adding guidelines, documentation and ease the setup process (with HLS for example).

It takes too many efforts at the moment to both:

  • setup a Haskell environment
  • start playing with the language or create a toy project (We lack guidelines and great documentation)
3 Likes
#38

Personally, I think if you want more use of commercial Haskell then it needs to be easier to get into Haskell.

It took me about 10 years to finally write some Haskell that actually did anything useful. From an outsider perspective – particularly if you’ve not done CompSci – Haskell just seems incredibly intimidating. Which is a shame, as it’s a really lovely language to use.

I think my biggest stumbling blocks over the last four years of really getting into Haskell:

  • Documentation: it’s hard to find documentation. I would like Laravel-quality documentation in one easy to find place. So much existing documentation relies on understanding the types for it to make any sense, which took me a good year to get my head around.

  • (As mentioned elsewhere) The use of String, so you spend ages getting that working – only to discover a year later that Text is actually the way to go.

  • Laziness: haven’t really needed to fully understand it yet

  • All the category theory stuff: no idea – but I love writing Haskell and can get it to do the things I want

  • Build tools: what’s the right one?

Learn You A Haskell is easy reading, but I think quite dated now. The Haskell Book is incredibly detailed and fascinating, but it scared the pants off me – I still don’t follow most of it.

What’s my point? Good question. Something (anything) that makes Haskell more approachable gets my vote.

PS – Happy to do what I can to help with this (just finished a five year stint teaching on a programming bootcamp).

8 Likes
#39

so one thing that I think is long overdue and definitely needs money to make it happen:

merging the js (ghcjs) and jvm (eta) backends into ghc.

They’re not gonna survive and remain viable otherwise, and both (if done seamlessly) create lots of great new growth opportunties for haskell as a tool, as well as being interesting pressure points for revisiting the standard library problem :slight_smile:

3 Likes
#40

Merging ghcjs is in progress. And I believe Asterius also tries to align with the GHC build system to make merging eventually possible.

3 Likes
#41

With respect to Eta I believe the boat has already sailed. Eta forked off around GHC 8.0 and while I’ve not assessed what in particular would need to happen to forward port it, I have significant doubts that it would be anything less than a rewrite.

#42

Yes Eta is a long shot, but I hope the success of a GHCJS merge (which I think would be enormous) could build some momentum. I left a comment in https://github.com/typelead/eta/issues/984#issuecomment-761232613 saying basically that the Haskell Foundation’s existence should address the stated issues why Eta forked in the first place.

I would not at all be opposed HF funding @rahulmutt to get the the backend resurrected and merged upstream. I know there is a bad taste in many of our mouths over the fork happening in the first place, but IMO getting ETA merged would be awesome and make me feel “all’s well that ends well”.

(Lastly, GHCJS, Asterius, and Eta I believe all work from STG, so I think there could be some good synergy underneath the hood really fleshing out “backends from STG” abstractions, etc.)

1 Like
#43

Something that came up years ago was the idea of abstracting hackage to support multiple ways of working with the whole set of haskell packages. Right now, Cabal + PVP + trustee revisions is the blessed way to interact with Hackage, but it’s not the only one.

Perhaps this is still too hot of a topic. I just remember thinking at the time that we could have our cake and eat it too if we treated the blessed model as a distribution of Haskell, like the Ubuntu of Haskell, in an ecosystem that supported e.g. Trisquel and Kubuntu as well. Hackage revisions make perfect sense in such a model.

#44

Building projects on air-gapped or merely firewalled environments continues to be a huge PITA. Reproducible builds that depend on someone’s server somewhere and network availability - good luck with that.

There were efforts for completely offline builds, alas none reached maturity.

And I would say nothing of GHC bootstrapping…

#45

I’m surprised that you have found GHC bootstrapping to be problematic. Under the make build system GHC can be built with only alex, happy, and ghc. What specific issues did you encounter?

1 Like
#46

Hackage security model :eyes:

#47

@chreekat, can you elaborate? I’m not sure whether you are mentioning Hackage security in reference to @wiz’s comment or suggesting work on Hackage as part of the technical agenda.