Earlier this year, I wrote a blogpost about our plans for the next version of the School of Haskell. SoH is a community service and project to make it possible to use interactive snippets of Haskell on any website, in particular on schoolofhaskell.com. Today, we are open sourcing the SoH 2.0 repositories! We've also retired FP Haskell Center, and SoH pages that were previously on fpcomplete.com now redirect to schoolofhaskell.com.
Here's the current status of the different parts:
Here's the repo main SoH code, which includes the browser client and API service. Once the service side of things is ready, they will allow you to embed interactive Haskell snippets in any website!
The soh-client is written using GHCJS, and provides a code editing widget. It uses ghcjs-react to separate the view from the model / controller. It utilizes some of GHCJS's fancier features, such as fully supporting concurrency and STM.
The soh-scheduler provides a REST API for requesting that a container running soh-runner gets spun up. We ran into some issues with deployment to ECS, likely due to our huge docker images. Our plan is to rework / rewrite the service code to instead target Kubernetes. Since the initial implementation of SoH 2.0, we've had a lot of positive experiences with kubernetes, and would prefer to use it.
The schoolofhaskell.com repo repo contains code based on code for the fpcomplete.com site. It is served from schoolofhaskell.com. The contents of the site is not yet interactive, as the kubernetes based version of soh-scheduler still needs to be written and deployed.
There are quite a few immediate things to work on in SoH, in particular, the switch to kubernetes, and integrating the new client with schoolofhaskell.com. Once these things are resolved, there are also some interesting possibilities. Ever since the client code was initially written, a number of developments have occurred that it might leverage:
One such development is haskell-ide-engine, a project to centralize our efforts on providing Haskell tools (particularly those that use GHC), as a service to text editors and IDEs. We'd like to focus our efforts in this direction on haskell-ide-engine, rather than stack-ide. This means that in the future, SoH may be based on haskell-ide-engine, along with some selection of its plugins. I encourage people to dive into helping with HIE, to bring it to a point where it makes Haskell development excellent, and to make it fit for usage SoH 2.0.
Another interesting development is Ryan Trinkle's excellent reflex library for reactive UI. While using react was quite nice overall, I ended up hacking around some of the paradigm. I think things would work out cleaner with reflex / reflex-dom, and this way SoH development can benefit that project!
Do you like this blog post and need help with industrial Haskell, Rust or DevOps? Contact us.