One of these days you should write something about productivity. It amazes me how much work you get done in such a methodical way. Congratulation for your work, I can’t wait to try Oil Shell!
Thanks for the support! I’ll answer briefly here – I have a few “advantages”, and one “meta” tip.
So if you take all that into account, my productivity probably isn’t out of the ordinary (at least for someone with 14 years of professional experience).
Also, take into the account the fact that I’m writing this in Python, and that is like a “superpower” if you compare doing the same work in C or C++. I started this project with 2000-3000 lines of C++, and I wouldn’t have gotten anywhere close to finished if I had stayed on that course.
If I have one tip, it would be “don’t get stuck”. My previous projects involved a lot of design, and truly clean slate design without any users makes it more likely that you’ll get stuck on something, or waste effort.
This one is more constrained because I made the decision to be compatible. I think this has helped in a lot of ways, one being that I don’t really get stuck. I just have to make things work roughly the way bash does, sometimes cursing it, sometimes documenting deviations and planning for better semantics in Oil, but I don’t get stuck.
If you don’t get stuck for 20 months, work full time, and don’t work on anything that’s not in the finished product, a lot of things will get done!
I always enjoy your updates! And I’m really looking forward to the next post on lexing.
Thanks, and feedback taken! Unfortunately I might not get back to lexing until February or March… The long HN thread on this blog post  reminded me how many people are confused about Oil and confused about shell in general. So there are a bunch of things I want to clear up before the next release.
The next release announcement should have a link to “why write a new shell?”
And then hopefully I can get back to lexing! The lexing style has continued to pay dividends. I mentioned very briefly in this post the sharing between echo -e and $'\n', which worked very nicely. I just dropped in this additional lexer mode and everything worked, and I was able to share part of it between runtime and parse time (static vs. dynamic)
Interesting stuff. The shell really is a space where there’s a lot of room for improvement. I’m not personally a big fan of Python, but, each to their own. I do wonder about the performance though - how does it compare to Bash?
In any case, keep going and good luck with this project!
I plan to break the dependency on Python. Speed is one of the reasons, but not the only one. I’ve prefaced all the release announcments with “it’s too big and too slow” to acknowledge this issue.
This comments has some more links if you’re interested:
It’s going to be a little tricky to do this without rewriting the entire program, but I believe it can be done.
If I understand correctly you will try to use automatic translation (to for example C++)? That’s certainly ambitious, but perhaps not impossible. There are even a few existing projects which are setting out to provide such translations (eg https://github.com/pradyun/Py2C).
My personal advice would be: that part is probably going to be relatively uninteresting for you, since it will involve fixing things that you already got working before. It could involve a lot of such manual fixes (in fact it’s likely that’s unavoidable). So: don’t lose heart, keep at it, make sure you keep progressing (even if slowly) and don’t get stuck.
I would also, personally, advise that you try to switch away from Python sooner rather than later. The bigger the project gets, the harder it’s going to be. Python is ok for certain things but I think you’re right that interpreted Python is not really suitable for writing a shell.
Whatever and however you do it, be sure that I’ll keep an eye on it. It’s an interesting project and I’d love to see it succeed.