There are two ways of looking at OSH:
I started with the first view. While I've been working on [OSH][osh-language] 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!
(3) New Roadmap; The Top Priority. I want to make a prototype of the Oil
To be specific, I'll implement the part of the Oil language that's analogous to [bash]. Oil will have other features like structured data types and declarative constructs, but I may not get to those by the end of the year.
I need to come up with a name for this subset of Oil, perhaps "Oil B". (B is for bash.) Suggestions are welcome.
(4) Elevator Pitch for Oil. I haven't been doing a great job of
Notice that this is entirely about shell programming. It leaves out the interactive shell.
On the one hand, there are probably 10x or 100x more interactive shell users than shell programmers. On the other hand, I think it's better to completely nail a problem for a small group of users. There's also less competition in this space. For example, [zsh], [fish], and [xonsh] are interactive shells with happy users. But I don't know of large shell scripts written in non-bash languages.
Let me try it out here:
Suppose you've grown a large 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. It's more readable and maintainable, and you'll get proper data types like numbers, arrays, and hash tables.
Even shorter one that I typed on reddit:
Basically OSH is a bash clone, and Oil is a new shell language that you can automatically translate bash/OSH programs to. It's more readable, maintainable, and has proper data types. The idea is to give you an easy upgrade path from bash.
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. In working out the rationale for Oil, I've
Shell is a language for specifying distributed architecture. Processes and ports. Problem: this is still far away.
I like to type fast. There is some truth to this. But:
I've been working on it for 15-16 months now. Time to look back.
Project Retrospective: What did I do?
What did I learn?
De-risk OVM -- pretty much did that
De-risk OPy: need to do this.
List of Possible Directions
Refocusing the project
Why? I need to sell Oil again.
blog generated more excitement than code??
Goal: see below
Architecture Odds and Ends -- mainly runtime vs.
the language of startups
Sorry if this terminology is obnoxious. But I think it is accurate.
probably need a new test framework to test that the conversion and the original both have the same output!! and exit code. Same execution model.
next: for Oil design, consult vim and textmate syntax highlighting.
Oil by end of year! 5 months left!
But then I still won't have anything that concrete? Nah I think it being slow is OK. Nobody complained that it was too big and too slow!
Change parser to use exceptions, Fix parse error messages
TO START: oil-quick-ref!
making args.py WORK ON CONST WORDS WOULD BE VERY USEFUL
completion and interactivity - second pass
[ and [[ should share parser