ScarpeRoadmap.md

Scarpe doesn't really have a roadmap, in the sense of "here's how long before feature X will be included in Scarpe." But Scarpe does, of course, have a variety of things we're doing, things that would be useful to do, and reasons for doing things.

Less of a roadmap, more of a fun list of roadside attractions that we'd love to visit.

What would be good for Scarpe? What would count as an interesting and useful part of Scarpe?

(Many things we can do will help in more than one category.)

We also keep a list of possible brainstorming features for later including old Shoes functionality we don't have yet or stuff old Shoes never did but we might want to.

Approachability

We would like new people to be able to learn and use Scarpe. Here are some things that make that more likely:

• Testing and Robustness: if Scarpe works well and reliably, people will enjoy using it more and get fewer unpleasant surprises when they start to use it.
• Completeness: supporting all major Shoes functionality makes it easier to write apps. Supporting the original Shoes API makes it easier for people to use legacy examples and pick up coding Shoes again. It makes our old documentation more useful. It also makes for a good answer when people ask, "how do I do X?"
• Polish: if Scarpe looks good, people are more likely to want to use it. You play an instrument because the music sounds good to you. You write a program because you like something about it. A pretty, polished program is more appealing. A pretty, polished Scarpe is more appealing. There are a lot of pieces of Scarpe (e.g. how the basic drawables look) that can make a huge difference in how pretty a person's first Scarpe programs look.
• Portability: it would really help if people could easily pick up Scarpe and start using it. An easy-to-use web-based display library or a Windows port would help that. How can we get Scarpe to be easily usable by more of the world's potential programmers?

Utility

We want people to get something useful out of Scarpe, so that they keep playing with it. There are many, many things in this category. Here are a few to get you started:

• Packaging: if you can share your Scarpe program with non-programmers easily, that gives a happy payoff. People can see and use your work. Woot!
• Portability: being able to share work with people running Windows, or using a web browser, is good. That's not just traditional portability, but being able to use documents or storage in a useful way, for a user to get something good from a Scarpe program.
• Glue-ability: Scarpe is great for quick-start prototyping, using Ruby's existing gems, callout to the system and so on. While there's a natural tension here with packaging, we can still keep things at that point of tension, where a decision that's bad for packaging is good for glue-ability and vice-versa. Both are very important.
• Versatility: we pay a heavy cost for Shoes/display separation. In return we get the ability to switch display libraries in the future and to deploy the same application to desktop (Webview) and the web (Wasm.) Versatility is a powerful thing. It also trades off hard with a lot of other kinds of utility, so this also has to be a tradeoff.

Robustness

Once you've been programming in Scarpe for awhile, you'll get a good feel for how well the internals are built. Well-built internals will help us keep programmers for longer, and bring them back again later. Do you remember old languages or libraries that just felt good to use? That's what we need to be building.

• Error Messages: it is much more important to have Scarpe detect problems and give good error messages than to save CPU cycles. If something is enormously, profoundly slow or inefficient, add an environment variable to turn it on and off. But debugging and development should not be machine-efficient, they should be programmer-time-efficient. Even more than that, they should be programmer-enjoyment-efficient. We are using Ruby. Many existing parts of Ruby culture and philosophy already work this way. Use them.
• Testability and Debuggability: being able to test Scarpe applications is a big deal. Being able to stop and debug them is a big deal.
• UI Design and Documentation: being able to understand the API easily and use it fluently is really good. When that fails, getting a solid explanation to understand what's wrong is very helpful.