This seems like it could be useful, but I don't seem to be able to create a discussion which is visible to everyone, yet only editable my members of my team, which is my main use case (for discussing project direction and such). "Public" seems to mean "visible to everyone in the organization".
Category theory matters to programming because, among other things, it teaches us how to abstract over programming languages. What better definition of abstract programs than "things with types which compose"?
Now consider categories with various types of constructions (products, limits, exponentials, etc.) and you'll notice they correspond to requiring certain features in your language.
I work on the PureScript (http://purescript.org) compiler, tools, libraries and book in my spare time (along with many other unpaid contributors), because it's the programming language I wished had existed when I started creating it. It's still the closest thing to a perfect environment for web development, at least as far as I'm concerned :)
We recently added a way to dump out the compiler's intermediate representation as JSON, so it's actually very straightforward to create new backends by transforming that output [1].
The representation is fairly compact, so the requirements for a PureScript compiler backend are fairly minimal. You just have to translate all of the features of the IR:
- Functions with lexical scoping
- Support for the primitive types defined by PureScript (we need to define some of these types more concretely in a specification)
- A way to encode records. This could be something like JavaScript's objects, or just a map data structure.
The JS backend actually does more optimizations before code generation, but it starts from the same intermediate representation.
Halogen is not the only option for building web applications with PureScript. There are simpler options like Pux and Thermite, which are possibly much easier to teach. Halogen is optimized for a different use case.
You don't need to constrain yourself. AltJS allows users to mix and match different languages for different problems. Use a pure functional language where it makes sense for you, and don't where it doesn't.
> to become even more hardcore on algebra and categoric language
In some of the standard libraries, yes, that's true. However, it's possible to use PureScript without the standard libraries, and use alternatives such as Preface (a teaching library) or Neon (an alternative to Prelude)
> Still, type classes seem to appear less and less elegant as time goes on
I think part of the problem is that type classes are so easy to abuse. When you have a problem like e.g. monad transformers, where a) you have a lot of boilerplate code which would be irksome if written out by hand, b) you have laws to make sure the generated code is sensible, and c) your types have exactly one such sensible instance, then classes are very nice. Abuses of type classes exist where any of the three above conditions fail to hold IMO, and a scrap-your-typeclasses approach can be very valuable then.
I haven't used latest Halogen yet, so I can't give a detailed comparison, but the approach in Thermite [1] is indeed what I am referring to above. It was based on some work in the OpticUI library [2], and has worked out quite nicely for the few projects I have applied it to.
I will say that the types in Halogen seem more complex, but they can be justified by the fact that the coproduct machinery helps ensure all actions get handled somewhere. This may be possible with prisms, I'm not sure yet. This library [3] seems relevant.
One issue I've found, which I understand the Halogen folks are also finding, is that it is tricky to wire up action handlers such that a subcomponent can invoke an action and have a parent act on it and invoke its own action in response. Granted, this is a relatively infrequent use case, and you can always push such logic into some shared parent.