JotSpot

A more remrkable example of a Wiki backed by a Wiki specific DSL.

The guided tours on Jotspot's website aren't very useful. I recommend viewing Jon Udell's discussion cum demo with the Jotspot guys.

The most important point for PL types is the notion of programmability. The world is going in that direction, and this should work to our advantage guys... Language design is becoming more mainstream, but it's still hard work that requires good linguistic intuition.

It seems that the Jotspot guys are aware of this trend, seeing as they talk about "part time programmers".

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

JotSpot

(I'm the CTO of JotSpot.)

Following up on some of the comments from the FlexWiki thread: I don't think you necessarily need to decide between the "true DSL" approach and the "object model exposed to GPL" approach. At JotSpot we spent a long time designing the underlying data model and the appropriate DSL. But we also discovered that the DS part of our L meant that it was good at what it was designed for but not so good for the occasions when you really need a GPL.

So we built in the ability to embed real GPLs into the DSL that represents the wiki page. This is an inversion of the usual pattern (embed your DSL in your GPL); it looks more like Javascript embedded in HTML. (Or in the worst case it looks like the WikiTalk example cited by sean in the FlexWiki thread.) It isn't elegant, but I think it's better than the alternative which is to use the DSL for general-purpose tasks. The idea is that most "part-time programmers" won't need to escape out to the GPL, but it's there if you need it. (And part-time programmers can use components built from the GPL without needing to know the implementation.)

Another feature of our system which might be of interest to LTU readers (and probably to no-one else!) is the fact that we're storing the AST of our DSL. We do this so that we can transform the AST into different editable representations depending on the context.

Language design is hard work, and we still have plenty of open issues at JotSpot, so I welcome any feedback you might have. And we're hiring!

Interface design

Once you start to consider the language as part of the user interface (and an application specific DSL is, of course, exactly that), it becomes natural to consider basic UI patters, such as distinguishing casual and power users.

More importantly, providing hooks for user supplied code shouldn't be seen as even being in the same category as providing a DSL. Each apporach solves a different set of issues, for a different set of users.

Finally, I wonder whether routines wirtten using a GPL can be exposed to part-time programmers using the DSL.