Preskoči na glavno vsebino

User interface spectrum and a small Spreadsheet datatype demo

Languages

I have been repeating this thought, that programming languages are user interfaces for a while, mostly to myself. To put it better, all programming languages are somewhere on the "user interface spectrum".

As you go from the lower to the higher levelness of programming languages their core "audience" and their core vocabulary changes. 

Lowest level languages speak to the machine, in the machine language, use machine constructs and machine vocabulary ... think Assembly or C. 

Somewhat higher level languages forget about the machine a little and speak the language, use constructs and vocabulary of their abstract computational ideas/models. Think Lisp, Java, even Python.

Their model can be based on some academic concept or it can be a more human friendly representation of lower level vocabulary and constructs.

Even higher on the spectrum are for example command shells. It's audience is an  admin, a person, a user. It's vocabulary is centered around the user and the tasks the user might want to do. You don't use the "computer words":

URL url = new URL("http://example.com");
HttpURLConnection con = (HttpURLConnection) url.openConnection();
con.setRequestMethod("GET");

your just say: 

wget example.com

And above shell there are GUI-s (I have some specific opinions about them also, not for this blogpost).

Programming

And what is programming then. It's the translation from "computer speak", to "user speak". We do it internally, while programming. We translate lower level general words and concepts to higher level, more user/problem specific words and concepts simply by making functions / structures, construct higher functions out of these functions until we get to a end user/problem specific vocabulary (an API) and then a command-line tool or GUI as the final result.

For example:
 
tcp -> http -> getData -> JSON -> prepare -> HTML -> Visual display of information
 

Which level is the best then

Of course, it totally depends on what audience you are writing to. If your main problem is with the internals of the computer, you should speak in computer vocabulary.
 
If you don't care how, where and when information is represented internally, and your main focus is the information itself, how you process and display it for the user, starting with a higher level language will need less translating to get to the final result.

Where is Rye

Rye aims very high on this spectrum. Closer to the Command Shell than Python. It tries to use the human vocabulary and constructs, it tries to think about the information, not the way it is stored internally. 
 
For example. Humans don't think a list of people with their information is a list of dictionaries (or an array of hash-maps). To them, it's a table, a spreadsheet. That's why in Rye a SQL query doesn't return a list of dicts, but a Spreadsheet datatype/value.

Spreadsheet also better matches the given problem all around. There is no value in keys repeating on every row, it's just bad form for no benefit. Spreadsheet is inspired by a dataframe datatype in R.

But for the same "humane" reasons we don't call it Dataframe, but a Spreadsheet.

Small Spreadsheet demo

But it's not just how we name it. Having a Spreadsheet datatype, which is the right way for handling tabular user level information, enables users/programmers to solve their problems in a simpler, direct and more declarative way.

Spreadsheet will come with a lot of interesting, high level functions. We are not there yet, below is just a small demo of the current state.



Dynamic brother from another mother

Sometimes you need to solve concrete problems on the very low and very high ends. Imagine a 3D game engine, low end is the rendering, memory handling, loading of resources, general algorithms, high is the game logic, UI, scripted behavior.

That is why these tools very often use a low level language and an embedded higher level "scripting" language. Lua is used for this a lot because it's easy to embed into C.

You could also say webservers are the same. Webserver is often written in a lower level language (or it makes sense that it is) and for our application level programming, it makes sense to use a higher level / dynamic language.

Rye is built on Go and out of Go, and they integrate in a very simple and light way. So Rye could be seen as a good scripting language for Go projects. I intend to explore and document this at some point.

Follow us on github.

Komentarji

Objavite komentar

Priljubljene objave iz tega spletnega dnevnika

Less variables, more flows example vs Python

In the last blogpost ( Less variables, more flows ) I wrote a quick practical script I needed. It was an uncommon combination of CGI, two GET requests with Cookies and a POST request with Authorization header. I really like practical random/dirty problems, rather than ideal - made up problems to test the language. To get a sense of comparison I rewrote the example 2 times while removing specific Rye features. But that comparison is meaningless to a person that doesn't know Rye or at least Rebol already. So I went on fiverr and made a request for a Python script with these requirements. I got a nicely written Python script that uses functions for each step. To be more comparable, I rewrote the Rye code to a similar structure. Below is the result ... For a next step, it would be interesting, to extract a little simpler example out and add error handling. With Rye-s specific failure handling, I think the difference would become even greater. You can find Rye on github .
Objavite komentar
Preberite več

Ryelang - controlled file serving example and comparison to Python

This is as anecdotal as it gets, but basic HTTP serving functions in Rye seem to be working quite OK. They do directly use the extremely solid Go 's HTTP functions, so that should be somewhat expected. I made a ryelang.org web-server with few lines of Rye code 3 months ago and the process was running ever since and served more than 30.000 pages. If not else, it  seems there are no inherent memory leaks in Rye interpreter. Those would probably show up in a 3 month long running process? And now I got another simple project. I needed to make a HTTP API for some mobile app. API should accept a key, and return / download a binary file in response if the key is correct. Otherwise it should return a HTTP error. So I strapped in and created Rye code below. I think I only needed to add generic methods stat and size? , all other were already implemented, which is a good sign. Of course, we are in an age of ChatGPT, so I used it to generate the equivalent  Python code. It used the elegant
Objavite komentar
Preberite več

Receiving emails with Go's smtpd and Rye

This goes a while back. At some project for user support, we needed to receive emails and save them to appropriate databases. The best option back in the day seemed project Lamson . And it worked well ever since. It was written in Python by then quite known programmer Zed Shaw. It worked like a Python based SMTP server, that called your handlers when emails arrived. It was sort of Ruby on Rails for email. We were using this ever since. Now our system needs to be improved, there are still some emails or attachments that don't get parsed correctly. That isn't the problem of Lamson, but of our code that parses the emails. But Lamson development has been passive for more than 10 years. And I am already moving smaller utilities to Rye.  Rye uses Go, and Go has this nice library smtpd , which seems like made for this task. I integrated it and parsemail into Rye and tested it in the Rye console first. Interesting function here is enter-console , that can put you into Rye console any
Objavite komentar
Preberite več