Surprises in Shell Development, Quirks, and Variable Implementation in Nu

_Growth in code size with each version_ # Surprises? It's funny, when you start working on a shell it's easy to think "it'll be like a REPL". In fact, it's closer to creating an interactive IDE for the terminal. As people came to Nu from other shells, including shells like fish, there was a strong assumption that completions would be stellar, that it will integrate well with existing workflows, and it will support configuring the prompt, the keybindings, and more. It also turns out that getting a shell correct is a lot more experimentation and a lot less following what the textbooks say. In practice, things like 'stdout' and 'stderr' are used in a variety of ways, as are the exit codes output by programs. Our initial designs started with a stricter view of these ideas, and softened over time as we saw that the real world is a much fuzzier place than we realized. # Quirks Nu hasn't been without a few quirks. Like any awkward growth spurt, we've had our awkward times and still have a few "curious" areas. ## No variables, yet Had you a time machine and told us a year ago that we still wouldn't have variables today, we probably wouldn't have believed you. Isn't that an important part of a language? Yes, it's definitely important. But we're also surprised just how far you can get without them. When you think about how you work with a piece of data, maybe you break it apart, maybe you work over the lines, or maybe you search inside of it. Each of these has a built-in way to perform the task in Nu and none require user-defined variables. That, of course, has its limits. At some point you want to take the result of one batch of commands and store it for later. We're thinking through how to do this, and it comes down to a few basic questions: - Should variables work in a traditional way? That is, should we fully evaluate what we pass to the variable during assignment? - Or, should Nu instead "hold" the pipeline you use during the assignment, so that you can run it whenever you want the value of the variable (possibly caching the result if possible)? This is less traditional, but more in line with a language that works lazily on potentially endless streams of data.

Developing a shell is more like creating an interactive IDE for the terminal than a simple REPL, requiring stellar tab completion and integration. The initial design was stricter than reality allowed. Nu has quirks, including the absence of variables, which the team is addressing by considering whether variables should work traditionally with full evaluation or lazily by holding and running pipelines.