Blog Archives

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.

How you deploy is also important. Frameworks nowadays let you deploy to web and mobile using JavaScript, C# or even Flash, but how many of you (programmers) know how to do that? And those of you who know, what do you think about the process? Pretty clunky isn’t it?

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

The idea is that the code’s format will be similar to data that can be serializable. The closest thing to this at the moment would be the fact that you can turn a string into code in JavaScript:

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:

   "NAPL": {
                       "expression": [
                                "a = x+y",
                                "return a"
   "javascript": {
        "code": [ "return 'hello world';" ]

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:





Coding Trick of the Day: Removing event listeners on naked functions

This is mainly an ActionScript coding trick. I think it works in JavaScript but I’m not sure.

Many time, you want an event listener that only gets called once, or being able to stop the listener after a particular condition. For instance, you need the ENTER_FRAME event on a bullet until it reaches its destination or goes offscreen. When that happens, you need to remove the event listener. However, if you’re lazy like me, you will not define your listener like this:

addEventListener(Event.ENTER_FRAME, functionName);

but like this:

addEventListener(Event.ENTER_FRAME, function(e:Event):void { .... } );

That’s called using a naked function. It’s just convenient and easier to do than defining a whole new function somewhere for that. Also, if your function is small and not really important, it improves readability.

The problems comes when you have to remove the listener, because you don’t have any function name to do this:

removeEventListener(Event.ENTER_FRAME, functionName);

Fortunately, there’s a trick to remove the event listener within the function itself. It goes like this:

     function(e:Event):void {
          if(condition) {

This will make the event listener remove itself.

Motivation for making game

My plan for this blog was to have posts about making games. So you might ask…

Where on earth are the posts about making games!?!

Ok, I guess I should realize keeping up a blog is not that easy. I always have this game making tutorial in mind I’m planning, but that’s actual work. I shouldn’t really feel work when I write this blog. After all, I do this partly to feel relaxed.

Ok, but where comes the part about making game?

Well, I’ll tell you what. I’m just gonna blable about motivation for making game. That’s gonna fill up one post, and it’s not as energy consuming as writing up a tutorial.

So some of you might want to create a game, but it’s either too hard to do, too time consuming, or the simplest and purest excuse: I have no idea how to do that.

Well, that’s kinda the thing. There aren’t many schools that actually teach how to make a game. A lot of things in life won’t be learned by sitting in a classroom (things like learning how to cook, how to dance, or how to play video games). Making a game is one of them. I could tell you all the blabble that it’s all about passion, etc… but I don’t think it would help. It’s true though that it’s all about passion, and that’s the reason you’ll have to self-learn.

Self-learning might come from books, online tutorial, but primarily it needs to come yourself… ok that didn’t make any sense. By that, I mean that you have to be curious about some aspect in making games. There are little small things that make up a game. When I made my first game, I didn’t think about a whole “Super Mario”, a whole “Zelda” or “Street Fighter”. I simply thought about making a circle go up when I press “UP”, go left when I press “LEFT”… Then I got curious about making something disappear when the circle overlaps another circle… eventually, all the small interactions where building blocks that allowed me to produce my first game (World of Turtle, all in ASCII characters).

Basically you have to start small. Even if you have no coding experience, there are some simple basic interactions that you can implement with minimal learning. How about an adventure game, where you click on links to decide what actions to do. This can be done simply with a webpage editor!

To produce a game, you can have your dream set on the big thing, but you should have actual goals set on small achievable tasks. Once you become proficient at making a circle move around, you can move on to think about gravity, collisions, keeping score… things like that.

By planning small achievable goals, you turn your attitude to “active”, rather than passively waiting for things to get done. Of course you can’t develop the next Starcraft without a whole team of artists and engineers. There are so many elements: animation, UI, path finding, networking… but you can definitely make a circle move with your arrow keys, and with some imagination, you can turn that into a game.

Even if what you make doesn’t turn into a successful game, it is still worth the time, because you learn from it. Eventually, you’re accumulating skills and experience about making games, which can lead you to work on projects involving more people. On top of that, you’ll know what it takes to make a game, you’ll be able to learn independently, and you’ll have the confidence to make a game knowing it’s not all witchcraft.

The road to making a game might be long and difficult, but it is clear and visible. Don’t just believe that you can do it, but know that you can do it… and do it!

Coding Trick of the Day: The Comment Swapper

On many occasion when I am programming, I want to test out a piece of code, then try another one, and go back and forth between the two. Sometimes, it’s to compare performance, other times I just want to compare the behaviors (It happens very often when testing animation).

It can be tedious to constantly comment/uncomment code. But thanks to the “Comment Swapper”, I can do this in one keystroke!

1   //*******
2   object.foobar1();
3   /*/
4   object.foobar2();
5   //*/

Try it out: by deleting/adding the slash (/) character at the beginning of line 1, you can instantly swap between the two chunks of code.