1. 9

  2. 2

    To be brutally honest It seems the like author is taking a long and overly complicated journey with little to show.

    From the website the project goals are:

    Immediate goal: Implement a bash-compatible shell called OSH. Long term goal: Design a modern Unix shell language called Oil that can do everything bash/zsh/etc. can do, and more.

    I can’t explain why he needs a new python interpreter for this. What you really need is to work on the language implementation and less messing around on these rabbit holes.

    I get that its a bit of fun, but sometimes you need to decide if you are working for the delayed gratification of a finished project, or just doing something educational you have no intention of finishing.

    1. 1

      There are six problems here that motivate the Python interpreter hacking:


      The original plan resulted in a long discussion on Lobsters [1], and it was perhaps overly complicated. But I’m about to write about a variation that is much less effort. The SPOILER at the bottom was meant to assuage your fears. After some experiments, I’m not writing a VM from scratch.

      The thing that made me think that was doable was the tinypy codebase I mentioned. tinypy runs its own parser with less than 2,000 lines of native code!

      [1] https://lobste.rs/s/6vnrdc/unexpected_solution_cobbling_together

      1. 1

        All of those seem to be problems caused by using python where it is not appropriate, reinventing your own python with a fraction of the man power at your disposal doesn’t seem like the wisest choice.

        In my experience adding more layers of abstraction will only help if there is a real need for the abstraction. osh -> opy -> c is likely going to have more bugs, code and will be slower than osh -> c . You could save yourself thousands of lines of code by removing a layer. Only if osh becomes extremely large the benefit of the intermediate abstraction will pay off in reduced complexity in my opinion.

        I also don’t buy the complexity of the existing python interpreter argument, you are already implicitly accepting the complexity of the C compiler and the kernel, both of which are bigger than CPython.

        1. 1

          If you’re saying to rewrite it in C or C++, that isn’t an answer… I started it in C++ but realized I would never finish – see the first blog post.

          There is a simple metric I would use: total lines of code. Is OSH/Oil in Python + OPy + OVM bigger than an OSH implementation in C or C++? Is it bigger than bash? (150K lines)

          It looks like the answer is no. It could actually much smaller, especially when compared to bash. Wait for the next blog post before responding.

    2. 1

      Hmm, why is this tagged unix? I assumed that OPy referred to ops-related things. This is a post about an alternative Python compiler.

      1. 5

        Because the “Oil Shell” is a new unix shell being built. Read the homepage.