Posted on

Subtext 9

Subtext 10 is well underway, but version 9 deserves some mention. I didn’t record a demo video as in the past, because I have concluded that medium fails to communicate in sufficient detail. In the future I am going to try the forms discussed in my last post. Unfortunately Subtext 9 has fallen between the cracks, and all it gets is this lousy blog post.

Continue reading “Subtext 9”
Posted on

Evaluating programming systems design

I collaborated on this paper at PPIG19. They haven’t published the proceedings yet, so I’ve put the paper up here. Abstract:

Research on programming systems design needs to consider a wide range of aspects in their full complexity. This includes user interaction, implementation, interoperability but also the sustainability of its ecosystem and wider societal impact. Established methods of evaluation, such as formal proofs or user studies, impose a reductionist view that makes it difficult to see programming systems in their full complexity and, consequently, force researchers to adopt simplistic perspectives.

This paper asks whether we can create more amenable methods of evaluation derived from existing informal practices such as multimedia essays, demos, and interactive tutorials. These popular forms incorporate recorded or scaffolded interaction, often embedded in a text that guides the reader. Can we augment such forms with structure and guidelines to obtain methods of evaluation suitable for peer review? We do not answer this question, but merely seek to identify some of the problems and instigate a community discussion. In that spirit we propose to hold a panel session at the conference.

Posted on

What should I build Subtext 9 on?

This will still be just a research prototype of a programming language and environment, so I don’t care about deployment issues. Want to have:

  1. Discriminated unions and pattern matching
  2. IDE with debugging
  3. Rich GUI framework with functional style (Elm/React)
  4. Healthy ecosystem

Options:

  • Elm — nice and simple, but better suited to apps than an entire language environment. I really need mutation. Bit of a walled garden. Needs a real debugger (yes reproducibility improves printf debugging but it’s still just printf).
  • Dart/Flutter — could work. Refreshing simplicity compare to the chaos of web programming. Flutter is very appealing. But I’ve used Dart before. It is an old-fashioned OO language and I’ve gotten tired of that. Wake up and smell the pattern matching! Working in Dart felt like living in a remote province.
  • F#/Fable/React — nice, but a big language, with a lot of .NET baggage. Initial experiments ran into difficulties with the .NET tooling.
  • ReasonML/Bucklescript/OCaml/React — technically powerful, but no one seems to be in charge and it’s a big hot mess. Bucklescript is one guy in China. No source level debugger.
  • Swift/SwiftUI — very enticing: a modern language with a modern UI from people who really know their UI. Stealing the best parts of Flutter. Full tech stack fully documented and supported from one company with unbounded resources. Sadly, SwiftUI looks to be just too new. Still very mobile-centric. There isn’t even a table layout.
  • Rust/? — Rust looks a bit scary, but some people I respect love it. There is no good GUI story yet. In a couple of years I expect there will be a SwiftUI clone, compiling to WASM and native. Could be my future production platform.
  • TypeScript/React — utterly mainstream, and I already know it. Has a weak form of discriminated unions. Good enough.