Programming

Obfuscated code and weird programming practices

Modern computer programs are textual languages written in a way that is meant to be understandable — or at least readable — by virtually everyone.

For those willing to get their hands dirty with coding it is essential to be able to “read” a computer program. This means developing an understanding of the computer’s behaviour, and interpreting the significance of the structure of the program when this runs the code, even when this code is purposely intricate and very difficult to read— i.e. obfuscated.

As defined by Wikipedia, software obfuscation “is the deliberate act of creating source or machine code that is difficult for humans to understand. It may use needlessly roundabout expressions to compose statements. Programmers may deliberately obfuscate code to conceal its purpose or its logic or implicit values embedded in it to prevent tampering, deter reverse engineering, or even as a puzzle or recreational challenge for someone reading the source code”¹

Yet, while a computer system may compile code even when this is obfuscated, I believe it is crucial that code should be written in a such a form that can be easily interpreted by people as well. This is a typical perspective on writing code that follows rules of clarity and elegance. It is, in fact, very easy to find programmers praising the beauty of well-written code online. It represents such a common practice which cannot be unseen, and both the web and programming textbooks are inundated with tutorials and tips for writing elegant code.

However, as investigated by Nick Montfort and Michael Mateas with their paper A Box, Darkly: Obfuscation, Weird Languages, and Code Aesthetics, how do we explain the existence of obfuscated programming — either as a software development or as an aesthetic practice — in a world schooled with intelligible coding in mind?²

Some languages, often referred to as weird or esoteric languages, are often specifically designed to make legibility of a program arduous. They aren’t geared towards real-world applications neither are designed for any educational use. Weird programming languages exploit the concept of obfuscated code to “highlight the importance of the human reading of code in software development.”(Montfort and Mateas, 2005)²

With the rise of weird language programming, professional programmers and hackers alike started to organise obfuscated code contests as a mean to get creative with coding, rethinking the way most people perceive this practice (often idealised more as technical and structural, rather than artistic).

We shouldn’t be afraid to associate developers with artists. And yes, while some branches of programming are aimed at “fixing” and “posing the foundations” for the work of other coders (i.e. not what one would usually define as creating coding); there will always be creativity involved in writing code.

The aim of obfuscated code contests is never just about programming software through hard to read code (this is often achieved by introducing layers of complexity into the structure of the code) — they are about pushing the boundaries of the semantics of a language, creating art by playing with the syntax of code itself.

“In 1984 Landon Curt Noll and Larry Bassel held the first International Obfuscated C Code Contest. The contest was a success that has been repeated many times. […] The contest’s stated goals include demonstrating the importance of programming style. […] There is also an Obfuscated Perl contest, run annually by The Perl Journal since 1996.” (Montfort and Mateas, 2005)²

Common theme to all obfuscations is their intent to explore “the play in a language”², eliminating boundaries — or creating new ones — in programming language design.

The code snipped above is written in INTERCAL, a language that parodies other programming languages.

Coding in the realm of weird programming languages is often referred to as multiple coding. An example of multiple coding is Perl Poetry — “often little more than an exercise of porting existing song lyrics into Perl” which “does little to articulate the language of Perl itself”²

Black Perl, a famous example of Perl Poetry

On the other hand, the aim of Minimalist languages is to achieve “universality” while providing the programmer a very limited range of language constructs.

This code is written in Brainfuck, the esoteric minimalist language for excellence. Brainfuck consists of only eight simple commands and an instruction pointer. (Wikipedia)

Other weird languages, rather than simplifying and minimalising code instructions, they play with the syntax to produce literary artifact that can also run as valid programs.

The structure of the Shakespeare language exploits this “play” aspect in all its forms because it actually follows the structure of a stage-play.

Obviously the list of esoteric programming languages doesn’t end here. There are hundreds of weird languages out there, some trending while others almost abandoned.

I find that a useful way to grasp the way these languages work is to read their code snippets for compiling “Hello, World”. Try looking at the length, complexity, structure, and syntax of esoteric code here: https://esolangs.org/wiki/Hello_world_program_in_esoteric_languages


References:

  1. En.wikipedia.org. (2018). Obfuscation. [online] Available at: https://en.wikipedia.org/wiki/Obfuscation [Accessed 9 Mar. 2018].
  2. Montfort, N. and Mateas, M. (2005). A Box, Darkly: Obfuscation, Weird Languages, and Code Aesthetics. pp.1–10.

Francesco Imola is a London-based musician, weekend photographer, and current Sound Design student at the University of Greenwich.

w. http://francescoimola.com/

tw. https://twitter.com/francescoimola

Deconstructing functions

When thinking of code as a set of instructions is it useful to assign a name to those chunks of instructions. The two fundamental ones (in programming) are called procedures and functions.

Functions and procedures share many similarities — in some programming languages procedures are seen as a special type of functions — but generally speaking, functions return a value, whereas procedures don’t.¹

Functions are self-contained modules of code that accomplish a specific task.² The aim of a function is to “acquire” data, process it, and “return” a result (or value). To streamline and maintain modern code, functions are now usually limited to performing a single task and are kept as short as possible. [To some programmers], the idea that functions should be small is something that is almost considered too sacrosanct to call into question.³

The power of functions resides in their virtually infinite modularity. They allow programmers to shorten code, reusing it instead of rewriting it.² A function can be written once and used over and over again at different points within a programme. It is also possible to call functions from the inside of other functions. Some typical examples of functions would be arithmetic operators like “plus,” “times,” and “square root,” which can be combined with other arithmetic operations to compose expressions.⁴

To announce a function we firstly need to assign this a name (or identity) and declare any argument that it will require. When a function is called the programme “leaves” the current section of code and begins to execute the first line inside the function.² Once inside the function, the code is run from top to bottom. The resulting value is sent back to where the function was called in the code and is used in place of this.

Additionally, functions can be seen as look-up tables that map from a certain symbol, the look-up key, to a value associated with this key.⁴

Most modern programming languages — Javascript is a classic example — often allow for predefined (or built-in) functions to be called. In such languages, a function can be assigned as a value to a variable, or can be passed into arrays (lists) just like any other data type.⁵ Such type of procedures is often employed in functional programming, a language design that mostly relies on functions, rather than variables.

A function eventually represents the simplest machine design. However, completely functional programs can only recreate an ideally logical data in-data out machine, not the one which we usually have to deal with. Every variable that lives inside the workspace of a function is only usable during the execution of the function. Good designs are to be based on a reversible logic — one which a function-only driven programme will not be able to accomplish.

This intuition is at the heart of logic. If repeating the same operation with the same input gives a different output, you know without a doubt that something changed: it isn’t the function you thought it was, it isn’t a simple machine.(Derek Robinson, 2008)

Implementing functions into my coding projects

For the past week I’ve been working on an extremely small and simplistic program that develops on the concept of text and type, and uses functions as main building blocks.

The project is called TEXTBOX. Its aim is to generate an artwork out of the text the user writes in the actual textbox when hitting the submit button. It is inspired by this example — which I have encountered while leaning more about using Input and Buttons on p5.

Javascript code behind TEXTBOX

I’ve called the greet function through the mousePressed action/built-in function in p5. In greet is placed the for loop which generates the copy of the text, and changes its colour and position randomly. Simply reload the page to reset the background to white.

An nice update to this would be adding a refresh button inside the actual webpage, as well as the ability to save the artwork (with different aspect-ratios) as a picture on your computer.

The project can be accessed here https://alpha.editor.p5js.org/full/SJvi1DzrG


References:

  1. BBC Bitesize — GCSE Computer Science — Functions, procedures and modules — Revision 1(2018). Available at: https://www.bbc.co.uk/education/guides/z9hykqt/revision.
  2. Programming — Functions (2018). Available at: https://www.cs.utah.edu/~germain/PPS/Topics/functions.html (Accessed: 19 January 2018).
  3. Sridharan, C. (2018) Small Functions considered Harmful, Medium. Available at: https://medium.com/@copyconstruct/small-functions-considered-harmful-91035d316c29.
  4. Derek Robinson (2008) Software studies by Fuller, M. Cambridge, Mass.: MIT Press.
  5. Goldberg, O. (2017) Javascript and Functional Programming — Pt.2 : First Class Functions, Hacker Noon — Medium. Available at: https://hackernoon.com/javascript-and-functional-programming-pt-2-first-class-functions-4437a1aec217.

Francesco Imola is a London-based musician, weekend photographer, and current Sound Design student at the University of Greenwich.

w. http://francescoimola.com/

tw. https://twitter.com/francescoimola

A difficult relationship between algorithms and code

As algorithms gain their prominence in our daily lives and start to affect us to a degree still unknown to many, we should start seeking to understand them a little bit better by drawing on the history, social relevance, and definition of the algorithm itself.

First of all, algorithms are not code. They are two separated yet well acquainted entities in the way that one completes the other. “Algorithms are a finite number of calculations or instructions that, when implemented, will yield a result.” Code is the practical implementation of algorithms, described as set of instruction for a computer delivered via the use of specific programming languages.¹

It is important to remember that an algorithm does not live only within the environment of Computer Science but is firstly a set of mathematical operations. One can think of algorithms as step-by-step formal instructions to solve a problem that are only abstract until implemented on the machine. As suggested by Andrew Goffey in the chapter “Algorithms” on M. Fuller’ Software Studies, we can interpret algorithms as if they were sentences (term firstly used by Michel Foucault) in a language — one which does not cohere with the idea that words can’t do things. A language that is self-sufficient and can transversally communicate with itself without the need of actual “speakers” if engineered to do so.²

Languages base their existence on two basic delivery methods, speech and writing (memorisation being a result of the formers). However, we can see the power of speech diminishing when, in society, “the volume of knowledge quickly increased to a point at which there was too much [knowledge] to pass in the form of dialogue”³. To reason about the nature of the very first algorithm known in history — the instructions for factorisation and finding square roots developed by Babylonians in 1600 BC — we need to imagine dealing with the volume of congested information required to be processed to get the job done. To tackle this issue of “big data” it became crucial to develop written rules and instructions aimed at managing such “ill-defined network of actions upon actions”⁴.

Later in history, Turing’s abstract mechanical machine condensed the logic of virtually any possible algorithm into bits on an infinite strip of tape. Here the algorithm, while occupying a crucial role in the computing process, becomes nothing but a set of data fed into the machine to yield a result. But even a cardinal concept like that of the Universal Turing Machine assumes a degree of abstraction in that it supposes a precise set of inputs (1, 0, and Blank) and outputs (move tape left, move tape right, go back to the beginning state, etc.). Without such structure of data the algorithm is broken.

“Although computer scientists reason about algorithms independently of data structures, the one is pretty near useless without the other. In other words the distinction between the two is formal.” (A. Goffey, 2008)

In a sense, we need algorithms to be broken, “machines to break down and systems to be hacked”⁵ because unintended side-effects are the foundation stone for most creative applications known to us today. I believe the study of algorithms needs to escape the shadow of code, and the much worshipped process of learning to code. This means taking a step back to find the patterns that connect data, before even writing a single line of code.


References:

1–3. Horan, C. (2017). The future is algorithms, not code. [Blog] Hacker Noon. Available at: https://hackernoon.com/the-future-is-algorithms-not-code-64cacca3b908 [Accessed 28 Nov. 2017].

2–4–5. Fuller, M. (2008). Software studies. Cambridge, Mass.: MIT Press. (Respectively on pages 17 and 19)


Francesco Imola is a London-based musician, weekend photographer, and current Sound Design student at the University of Greenwich.

w. http://francescoimola.com/

tw. https://twitter.com/francescoimola

ASCII art is fun

Filling the blanks with character(s).

Screenshot from “whorunow”, ASCII piece inspired by JODI

The American Standard Code for Information Exchange, abbreviated with ASCII, was designed in 1963 to be used with teletypes. A few years later became the Standard Code for Information Exchange for all computers in the United States. Although new character encoding schemes — such as Unicode, ISO/IEC 2022, or Mac Os Roman — have since been introduced, ASCII still remains an internationally accepted character code for the interchange of text in the electronic domain.

When did ASCII become art

ASCII artworks are probably something we associate with less-known internet forums and obscure Read_me files. Often used to refer to all text-based visual art, “ASCII art is a graphic design technique that uses computers for presentation and consists of pictures pieced together from the […] characters defined by the ASCII Standard”(Wikipedia).

Since its early uses, when printers and emails still lacked graphics abilities, ASCII art has gone a long way. Today, the aim of artists like Andreas Freise at asci-art.de is to collect and catalogue a number of text-based visual works which have never before experienced public recognition . ASCII artists have not yet made it to physical art galleries because of a profound connection to the net as original exhibit space. In addition, due to ASCII’s easily editable nature, the artist signature gets often lost in the way, which makes it difficult to get to know the people behind the canvas.

My attempt at ASCII art

I approached the ideas behind an ASCII artwork from a contrasting direction to most net artists. While text-based pictures are made to be seen from a distance because of the object they represent, we rarely appreciate ASCII in detail. With whorunow, I wanted to draw the user’s attention to the shapes of symbols and letters — which more than often are typed using a monospaced font that retains its space between characters such as Courier New — as an homage to both typography and digital designers.

First step to creating my own ASCII piece was processing a screenshot of my Facebook profile through Picascii. Tools like the this let users upload their pictures and then automatically convert pixels to ASCII characters through recognition of luminosity and pattern complexity in an image. The resulting text-based image can be saved as .txt file for further editing.

Here, I used my Facebook profile as a canvas to represent people’s image of their online identity: a mirrored version of their persona in a constantly changing state, unconsciously reflecting an inborn search for new interactions.

Second step was creating an HTML page where to link my piece. A very simple structure was necessary, with the only addition of the <pre> tag. This tag is useful for formatting text that needs to retain spaces and line breaks as it is written, and it is the key element to display ASCII art correctly on a web page.

Overview of the code behind “whorunow” (continues to the right)

Set the monospaced font to a pretty big value like 12px or more and your ASCII is displayed as if it is being zoomed in (mobile browsing may vary, especially on iPad), letting you move around the page in any direction and actively explore the artwork. Key element to this piece is the addition of text, difficult to spot amongst the myriad of characters on the page. I believe it makes the experience engrossing, as people will scroll through the canvas in search of something, that may or may not be there.

Take a look around whorunow here.


Francesco Imola is a London-based musician, weekend photographer, and current Sound Design student at the University of Greenwich.

w. http://francescoimola.com/

tw. https://twitter.com/francescoimola

What I learned #01

Building a “program” without code

As a first year university student there’s a lot going on in your brain. Strong expectations and mixed feelings arise as you walk into each new class. Foreign faces, and maybe some familiar ones, you’d have to approach, interact with, and make connections.

Last week Creative Coding class was all about making connections. We — as a group — were asked to describe an everyday action or situation as if it was to be executed by a computer program without the use of any code nor technical terminology. Plain, simple steps. Written down and then reenacted in form of performance, which would have given us the opportunity to see the process in action, and perhaps pick up on errors or steps we didn’t think of.

We thought survival was an interesting theme to work on. Intended as victory upon a lifelong fight between individuals.

Presented with an external attack, an individual can — at a very simplistic level — either fight the enemy or fly away. Choosing to fight could result in two different outputs: victory or death. However, the individual also has the option to run away. Despite the hiding skills, no species has ever made it on this planet without fighting for survival at least once. In such case, at some point the individual who has run away will eventually incur in another fight without escape as an option. For both instances, if we assume that winning a fight equals survival, then our sequence would keep running in an endless loop until the energy of the individual is exhausted. When death occurs, the sequence would stop running. A simple, logical process, which in reality is actually affected by an endless number of variables.

After all, it posed challenges to how we think of computer programming. Coding is nothing but directing an orchestra of bits, with data as instruments. The only difference? Machines are the best trained players you can ever find and they are never wrong. They respond to what we tell them in ways we can predict, manipulate and make work for our own purpose.


Francesco Imola is a London-based musician, weekend photographer, and current Sound Design student at the University of Greenwich.

w. http://francescoimola.com/

tw. https://twitter.com/francescoimola