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.
There are other questions we still need to answer as well, like how do variables and function definitions play together? How do variables shadow each other (or even if they're allowed)?
## To view or not to view
Nushell, being a language focused on working on structured data, has a few quirks with how and when the data is viewed. For one, Nushell has multiple types of data, and different types of data may have different viewing needs. To help with this, we created `autoview`, a command that will look at the data and detect a variety of different cases. Once it's identified the shape of the data, it will call out to the viewing command that handles viewing that particular kind of data.
Autoview is applied to any of the data being output directly to the user, which is the case for the last step of a pipeline. For example, the pipeline `ls` is actually `ls | autoview` behind the scenes. The `ls` command outputs each row of data corresponding to the files in the directory, creating a table. These rows are passed to `autoview` which detects that we need to view a table, calls the `table` command, which then views the data. This generally feels natural, well, most of the time.
It makes sense that `ls | where size > 10kb` doesn't output the data that flows between the two commands. If we did, it wouldn't be clear what the actual answer was. But what about in this situation: `ls; echo "done"`? Do we output the result of `ls` or not?
In the current version of Nu, we don't. We treat anything to the left of `;` as "do this, finish it, but don't run 'autoview'". This let's you do a series of different kinds of processing and only then view the end result.
This seems reasonable until you see something like `echo "hello"; echo "world"` and only see the output "world" and then have to stop and think through all the steps that led to that output.
## Getting turned around
As it turns out, the terminal is small. Want to view a few columns? Generally not a problem. Want to open that random CSV file from work with 30 columns? Well, now we might have a problem. How does that 30 column file actually look when you print it out in the terminal, with a nicely drawn table?
For some cases, we found we could be helpful by rotating the table so that the columns go along the side instead of the top. This is especially handy when there's only one row of data as it reads more like a record.