Why Sponsor Oils? | blog | oilshell.org
I've been thinking a lot about how Oil can achieve its goals sooner rather than later.
I considered some wild possibilities like abandoning the Oil language for an embedded JavaScript interpreter in the shell. This idea actually has some merit because JavaScript is sandboxed, standardized, documented, and has high-quality interpreters like duktape and QuickJS. But I rejected that idea for a few reasons that are no longer important.
After some more thinking, I can now see "the end" of the Oil project. It's not really the end, but the path to a production-quality 1.0 shell.
I decided to cut many things out of the project, including large parts of the Oil language. I prototyped an expressive, powerful language for the October pre-release, but it's too big. Ironically, I figured out it was too big by making progress on implementing it!
The next few posts will explain the reasoning behind this, and give you a picture of what Oil will look like. (Of course, you can always try the latest release, which I'm looking for feedback and bug reports on.)
I make every Oil release with an interactive Oil shell, which in turn runs thousands of lines Oil's own bash scripts.
But I don't use Oil daily because I want it to be faster, and because I've hit a longstanding problem with leaking file descriptors. And I can't ask people to use Oil if I don't use it myself. So in 2020 I want to fix these problems, even if it means cutting many features.
You can kick the tires on those features now, but so far not many people have done so. I imagine that's because I haven't documented them. So I'm also going to prioritize writing docs about existing functionality before developing more of the Oil language.
I learned the hard way that implementing a big language means that you also have to document a big language!
I started this blog in October 2016, and published a post every day for a few weeks. I'm going back to that strategy because it helped me describe Oil clearly.
I would spill out many thoughts in the morning, cut over 50% of the text in the afternoon, and then polish/publish a post in the evening. The next day I would start by editing the leftovers, and repeat the process until I was out of drafted text.
I think of this as a time-based release strategy for blog posts.
It occurred to me that another way to think about this announcement is that I'm doing the same thing for Oil itself.
What's going to be in Oil? Whatever I can fit in it by the end of 2020 after making it faster. I have to be using it daily myself then, and hopefully other people will be too.
(I plan to maintain Oil past 2020, but I hope that feature development won't stretch into 2021. I also hope I won't be maintaining it alone.)
To start, I'll only publish these posts on /r/oilshell and the @oilshellblog Twitter. Comments are appreciated and will guide future blog posts.
When this blog series is done, I may write a summary and distribute it more widely. There are many shell users unfamiliar with Oil. I'd like for you to be able to point your friends at these posts and inspire interest in getting involved.
My goal for Oil in 2020 is for it to be a fast, production-quality shell with good documentation. It will run existing shell scripts, fix usability problems with bash, and have significant new features.
After the heavy development and frequent releases of the last year, I feel like we're within spitting distance of that goal. But the larger Oil language is still speculative, and I don't see it being done in 2020.
Next, I'll enumerate the blog posts I want to write, and explain the main point of each one in a sentence or two.