Code as an object – NAPL (Not Another Programming Language)
Let’s get started with the first concern of our new programming language: portability.
In this day and age, portability becomes increasingly important as several types of device are created. You need a language for computers, tablets, phones, but not just that. Soon you will need a language for all the Internet of Things considered.
By that, I mean your microwave might be talking to you, or your purse, your car… Here are some classic examples
– Your fridge could be telling you that you need more vegetables in your diet
– Mirror can give you suggestions on how to put your hair today
– A painting you just bought could give you information about its artist
– And wouldn’t it be nice if your dog’s leash could try to tell you what the dog is thinking?
It would be nice if you could talk back to the device as well with spoken words, but that’ll be for another blog post. In this one, we focus on the idea that you can deploy your NAPL code to all devices.
To come up with an easier way, let’s look back at how humans communicate:
To give instructions to a worker, you can write down a letter, you can talk to them, you can talk to someone who will talk to them, even have a translator translate let’s say sign languages to words… Whether it’s through email, text message, phone, or direct conversation, the information passed is quite flexible.
To enforce an easy deployment, let’s introduce the first attribute of the language: Code as Object
var function = new Function(code);
For NAPL, given that the code can be serialized, it will be possible to write code using JSON. The code will look something like this:
Note that this is just globally what the language will look like (a JSON object). I haven’t decided the content yet, so I just made up something but the actual code probably won’t look like this.
The advantages of making objects as Code:
- Code can be transported from machine to machine via the network very easily. As a result, we can create travelling code.
For example, the code goes to a machine in Vancouver and extract some information, then it travels itself to another machine in Paris and extract another piece of information, does some calculation, and gets sent to New York to provide the final response. To achieve this right now, it will most likely be a machine in New York requesting data from both Vancouver and Paris.
- Code can change on the fly: The fact that the code is simple data, allows it to be changed very easily on the fly, and perhaps by the user. This gives room for user-generated content to be added very easily into a program.
- Once a new interpreter is created for a particular device, code can flow into it through any medium. Basically you could deploy code into a device without complication, by writing the code perhaps on a web page, submitting it, then the code gets sent directly into a device, even as the program is running.
With such powers also comes some drawbacks. Here are some the danger of making objects as Code that we’ll need to solve:
- If code can be modified so easily, it also means a program can be hacked very easily.
- Since code is data, it’s likely that people can look at a program like an open book, and know exactly how it is built.
- The code itself will not be very compact, which could affect performance.
This first attribute of the language, Code as Object, favors portability and flexibility. Some drawbacks will be vulnerability to hacking and performance, so those are problems that we might need to address as the language gets developed.
PS: Thanks for some of the comments I’ve gotten so far on LinkedIn about the idea. I’ve got some great suggestions from introducing FUZZY elements into the language, to teach the machine new keywords. Check them out here: https://www.linkedin.com/grp/post/1787637-6013573424499212292