DEV Community: kalium.xyz

Brainf*ck in 5 minutes.

kalium.xyz — Sun, 11 Aug 2019 15:28:48 +0000

The easiest least readable programming language I’ve written in so far has to be Brainf*ck. Brainf*ck is what I’d call a tacobell programming language, everything is made from the same 8 ingredients. You use the 8 operators to manipulate one datapointer (a number stored somewhere) and to change datapointers (Brainf*ck has 30.000 datapointers).

The operators are as follows:
“>” moves the datapointer to the right.
“<” moves the datapointer to the left.
“+” increases the selected datapointer by one.
“-” decreases the selected datapointer by one.
“.” outputs the number in the selected datapointer as an ASCII character.
“,” reads one character from input and writes it to the datapointer.
“[” if the current datapointer is at 0, then skip to the next “]”.
“]” if the current datapointer is not at 0, then go back to the last “[”.

Take note of the last two being able to form a loop to do clever manipulations.

So now that you know the commands you want to print the text: “Hello world!” as is traditionally the first thing to do with any new programming language. You start by looking up the ASCII number for every character:
H = 72,
e = 101,
l = 108,
l = 108,
o = 111,
space = 32,
w = 119,
o = 111,
r = 114,
l = 108,
d = 100,
! = 33.

Now the first datapointer will be used as an index for the loops, the second for the characters, and a third one for the space and exclamation mark. following below is the tutorial.

First we want 72, we know that 72 = 12 * 6 so we set the index to 6:

++++++

Then we start a loop that increments our second datapointer by 12 for every point it deducts in the first datapointer (making it go up to 72 before our loop stops)

[>++++++++++++<-]

And then we can print the “H”

>.

Now we need to increment the second datapointer by 101 - 72 = 29, a prime number so the same trick won’t work again. We will use 28 + 1 instead.

<++++[>+++++++<-]

We can now print the “e” and simply do +7, print again twice, +3 and print again.

>+.+++++++..+++.

Now we are going to use the third pointer, put it at 4 * 8 = 32 and print space.

<++++[>>++++++++<<-]>>.

Back to the second pointer for the rest of the letters same as before.

<++++++++.--------.+++.------.--------.>+.

Our final code will be:

++++++[>++++++++++++<-]>.<++++[>+++++++<-]>+.+++++++..+++.<++++[>>++++++++<<-]>>.<++++++++.--------.+++.------.--------.>+.

Easily writeable and understandable.

Online brainf*ck interpretator:
https://copy.sh/brainfuck/

What made you get into programming?

kalium.xyz — Sat, 10 Aug 2019 19:50:13 +0000

Why (and when) did you get into programming?

Do you feel that the modern "everyone should code" push is what got you into it?

Game of monkeys and ladders, how to learn wrong behavior while being rational.

kalium.xyz — Fri, 09 Aug 2019 01:05:27 +0000

So it starts, people disable swap space on their Linux servers and desktops then much later complain about their computers choking when they use up all their preciously guarded memory. "Why would anyone design an OS like this!" they lament, well its simple. Your home computer is a variable load machine and not some static production server with a known workload, and even then disabling swap space if you do not have perfect knowledge of the system is hardly a sin.

There is an anecdote I heard a while back that perfectly describes how these situations happen: Scientists set up an observation room with sprinklers in it and a banana on a ladder. They let three monkeys in the room. Whenever a monkey goes to climb the ladder the scientists turn the sprinklers on till the monkeys learn to keep each other from climbing the ladder. Now the scientists switch out one of the monkeys for a fresh one without any memory of the evil cold sprinklers. This new monkey only sees a delicious piece of fruit right for the picking, however whenever he climbs the ladder the other monkeys will become aggressive and beat him till he learns to do to not do so. The scientists observing this replace another one of the original two remaining with a fresh monkey. The cycle repeats with both the oldest and older monkey joining in the beating and the new monkey learns not the climb the ladder. This is when the scientists replace the final monkey and remove the sprinklers. When the final monkey comes in and tries to climb the ladder the other two will stop him from climbing by beating the shit out of him. None of these monkeys know why but they all understand perfectly that you should not climb the ladder.

Lets think about this, Some credible guy said something and we follow it. This is rational, though its quite likely he gathers his opinions from others (turns out you can only really talk to other people and yourself). Now we should first and foremost go trough the tedious process of asking why he is doing something before we try to do it ourselves. Remember our ability to communicate is about the only thing that sets us apart from the monkeys.

Building a JSON parser for great good

kalium.xyz — Wed, 17 Jul 2019 10:56:00 +0000

Motivation

A good way to learn more about programming languages is by understanding how they work. The best way to understand something is to have made it in the first place. Today we set out to build a simple JSON parser using the specs on json.org. JSON is a fairly straightforward and well documented spec so it is a good target for learning how to write a parser.

Process of parsing

JSON gets parsed into a data structure, so we don't have to worry about anything but the translation of a JSON string to the data structure. The first step in the process of translating the JSON file into a more abstract JSON object is called tokenization, lexical analysis or lexing. These terms are often used interchangeably. Lexing and lexical analysis are more often used in natural language processing and have their roots in linguistics. The process is as follows:

the tokenizer gets called with a string lets say: { "key": "value"}
The string gets broken down in units of meaning (e.g. keywords, separators, operators). The way we do this is by simply scanning over every single character and changing our mode of operation to accommodate (see an opening curly brace? we are dealing with a JSON object, opening square bracket? an array). These units of meaning are called tokens or lexemes. We can see that our string starts with an { indicating its a JSON object, moving on to the next relevant token we see a "key", :, "value", and finally the end of the JSON object }.
The tokens get put in the resulting data structure as we identify them. In our case our string becomes a root JSON object in our abstract representation of the JSON. (JSON object) We create the JSON object as soon as we identify it. If we encounter any malformed token along the way we will panic and the parser will quit, so its save to make assumptions like that the object will be a complete JSON object. Once we see the key we append it in our structure (JSON object (key)) and once we see the value we append it to the key (JSON object (key value)).

You might wonder why we would still need the closing brace, or why we don't just represent it without these symbols if they don't contribute up until this point. Our tokenizer works like a state machine, it switches modes depending on the input it gets called with. The } means, exit parsing JSON object, where a , would indicate there to be more key value pairs to follow.

Once we have the entire string turned to a data structure we are done, because JSON is much simpler than a programming language we do not have to go over the resulting data structure to run any instructions. The program can decide how it will use your resulting JSON data structure.

Implementing the tokenizer

the easiest way is to loop trough every character and switch modes depending on the character fed into the parser. You can do this using a switch statement that calls into a the right function for parsing a token. For a string you would see that it starts with " so any character that is not " will need to be stored, the latter token indicating that the string has ended and that you should exit the function and return the string to be embedded in the data structure you are creating.

understanding how to read the relevant documents for implementing a JSON parser

This excerpt from "how javascript works" is linked on json.org and explains the "McKeeman form", its good to read this trough and use this as a guide when implementing the different modes of the parser as you can see which types include what more clearly than on a syntax diagram:
https://www.crockford.com/mckeeman.html

If you have any suggestions or sources that should be linked you can fork this article.