Home

Post-Release Thoughts

2017-07-29

I've been digesting the feedback since the first release, and thinking about what will come next. I wrote Roadmap #4 in March and Roadmap #3 last November, so it's time for another one. I'm slightly shifting the direction of the project, but only those following will closely notice.

Prior to the 0.0 release, I was already planning the OSH 0.1 release. Several areas need polish, and I was excited about new features, like a better set -x (xtrace).

But now I think it's better to concentrate on the Oil language for the next few months. I haven't worked on it since February, when I translated shell to Oil.

This post is a list of topics to write about, many of which support the focus on Oil over OSH. Feel free to leave feedback if anything doesn't make sense.

Blog Backlog

(2) Review of Roadmap #4. Here's a short review in lieu of a dedicated post:

(a) Rather than re-implementing OSH in C++, I shipped the Python prototype! So the C++-related tasks were aandoned. The implementation language was the riskiest part of the project, and I think that risk is mostly gone.

I'm glad that I shipped early. Although I got good feedback from the 0.0 release, it also gave me the sense that OSH isn't as compelling as Oil. I'm glad to have that feedback sooner rather than later.

(b) I wanted to attract contributors and parallelize the work. It was a long slog! Although some people were excited about contributing to OSH and Oil, I didn't get any significant code changes. I got a few build patches, which I appreciate.

In retrospect, it was too early for others to work on the code, and it may still be too early. I've churned the code a lot: reorganizing the whole repo, porting it all to Python 3, and then back to Python 2 for OVM!

On the other hand, I am disappointed that I haven't gotten any patches to the [spec tests][spec-test]. I thought that high test coverage would make it easy to contribute to the project.

Future Topics

There are several topics I want to address, but I'll likely only get to a few of them. The most important one is the elevator pitch for Oil. Let me know if you have questions or want to read about a particular topic.

(1) Project Retrospective. I've been working on Oil for nearly 16 months.

(2) Possible Directions for Oil. I could outline future work on each of these subprojects:

Any one of them is big enough to fill the rest of the year, and I haven't even talked about awk and make. This project is big!

But one subproject is the more important than all the rest: the Oil language.

(3) Roadmap #5. The top priority: I want to make a prototype of the Oil language by the end of year.

(4) Elevator Pitch for Oil. I haven't been doing a great job of communicating what this project is about.

The problem is that the project is too big. In January, I tried to explain the project goals, but I think I've failed, since friends keep asking me what the concrete benefit of a new shell is.

So I need to narrow the project, and have a concise elevator pitch for that part of it. Let me try it out here:

Suppose you've grown a thousand-line bash script. You're having problems maintaining it, and you want to port it to a new language. Oil is the language you can automatically translate it to.

I think that a fair number of people can relate to this situation. I can elaborate on it, but I want it to also stand alone. Let me know what you think.

(5) Conversations with Friends. Recent conversations have helped me focus the project and communicate what I'm doing. A dialectic is often a good way to explain something.

(6) Work on OSH That Impacts Oil. I'm not completely stopping work on OSH for the next few months. There are some minor things I need to work out which will help me with Oil.

For example, I haven't yet implemented C-escaped strings like $'\n' in OSH. Strings in Oil will be C-escaped by default, so the implementation can be shared.

Summary

There are two ways of looking at OSH:

  1. OSH is a vehicle for Oil. I'm implementing OSH to make sure I understand the execution model of bash, and to make sure that Oil subsumes all its features.
  2. OSH is production-quality bash clone. It's better because it's statically parsed, has better error messages, and has a better interactive completion API.

I started with the first view. While I've been working on [OSH][] for the last six months, I've been entertaining the second view.

But not only am I eager to work on Oil, I think it's more interesting for users right now. The slogan I've been using in my head is:

I already did a draft of Oil-Quick reference and I fixed up the osh2oil tests!