Following digital excavation efforts at my disk’s deep directories, I stumbled upon a collection of colorful pseudo-random walk graphics. Since they are dated September of 2015 and were generated using unidiomatic slow snake script, their only property of note is a visually jolly aura; the following three possess a particularly vibrant one:
Inspired by grid worlds, non-linear notation and two-dimensional esolangs, I have attempted to design a few ASCII-art languages myself, none satisfactory enough for publication. Without the toolchain to interact in a non-typewriter manner — both on the software as well as on the hardware side — paired with the need for an apt encoding to facilitate higher-order capabilities, I could not manage to create something which stands on its own feet as a proper language, as opposed to nothing more than a convoluted yet primitive processor emulator.
In the fall of 2020, when I was tasked to teach elementary binary semantics courtesy of a brand new mandatory lecture at my university — constructing half-adders from basic gates and combining them to build full adders —, I thought that exactly this bare-bones grid world might be a fruitful endeavor for constructing and combining gates with a visualization of the entropy’s movement across the circuit (one might foolishly think of a bit meandering across a wire, although this interpretation has no physical merit to it). Within a few hours, I had managed to settle on a grid world definition together with an under 200 lines long interpreter for it. As I opted for an ASCII-CLI-look — significantly boosting development time —, I added image output facilities for this blog post (for which I swiftly designed a few pixel glyphs; only those used by the grid world), avoiding the need to take screenshots of my terminal emulator.
As in most grid worlds, non-inert characters are kept to a minimum: there are two entropy sources 0 and 1, the unary negation gate ! and three binary gates &, | and ^. All other characters except the space allow entropic bits to replicate, the special jumpers < and > allow to cross a gap of three characters, rendering interleaving wires possible.
Designing a 𝟥-bit adder
Calculating 0b110 + 0b011 == 0b1001 using a 𝟥-bit adder (input bits are interleaved, less significant bits reside on the left).
A matrix of discretely representable entries may be linearly layed out in memory using row-major order, concatenating successive rows into a contiguous -bytes long array. Such a representation, however, is disruptive to the matrix’ two-dimensional nature: whilst horizontally neighboring elements remain neighbors, vertically neighboring entries are torn apart by insertion of non-neighboring elements. As such, on matrices naturally defined operations get distorted by this encoding. One such inherently two-dimensional operation is matrix transposition. In the realm of matrices, are for nonsquare dimensions semantically different, being mapped to one another by transposition. Projecting onto their encoding, this semantic is lost and one is left with a permutation on memory . To visualize this permutation, its cycle decomposition is computed of which each cycle is given a color of the rainbow dyeing this cycle’s corresponding two-dimensional pixels when interpreting its path on the underlying array in the semantics of the original matrix.
Initial transposition cycles
Above listed are all visualizations for , shuffled. Whilst some behave extremely regularly — for example square matrices’ transposition permutations decompose into transpositions —, others are wildly intricate. Each of them adheres to a rotational symmetry; the top left and bottom right are fixed points.
Precisely one month ago, I opened a long awaited parcel shipped directly from Hong Kong: my very own Pinebook Pro had arrived. Eager to further my grasp on both software and hardware freedom, I unwrapped my mail and began to incorporate pine64’s flagship laptop into my workflow. Accompanying this journey, I wrote a diary which I share in this post.
Whilst a Pinebook may not boast with specs of performance, novel input methods or included licenses, it is part of a niche computing sector which values and upholds principal human rights even in the alien realm of microprocessor-based technology. Following my steadily growing discomfort regarding my computing equipment over the past months, I hoped for the Pinebook Pro to introduce me to a world of productive, in part minimalist and most importantly truly free computing experience. After a month of usage, I can confidently proclaim it to have delivered on this front more satisfactory than any other of my multitude of computing devices I have amassed over the years.
Especially in current times, it is calming to interact with an intricately mingled system of physical machinery and abstract commandments in which I can at least to a certain extent trust, lifting an ever-present veil of fear cloaking most boxes of bits. A Pinebook comes with software switches to turn off the built-in camera, microphone and WiFi card as well as Manjaro KDE Plasma running out of the box. Whilst I would prefer not having a camera or microphone built into my device at all and have a real physical switch to turn both off, as well as a more minimalist desktop environment, I am capable to entrust it my presence infront of it; in contrast to e. g. a proprietary phone lying on a tabletop nearby.
I am unaffiliated with pine64  and purchased my Pinebook Pro myself. I wrote the entirety of this blog post including the diary seen below using my Pinebook .
A detailed account of my experience with my Pinebook is given by a diary I wrote over the course of November 2020:
Enthusiastically following C++20’s new compile-time capabilities as well as awaiting more powerful ones being promised in upcoming standards, yet being stuck on C++17 , I try to take full advantage of the limited C++17-constexpr features. However, without static storage promotion, a constexpr std::string is all but a pipe dream, thereby necessitating the use of a wrapped static pointer; std::string_view.
One does not program against one’s compiler; one programs against the abstract machine defined by the standard.
Avidly writing C as well as golfing in it for over two years, I decided to venture out further in the realm of C-descendent languages, trying to get a foothold in C++. However, contrary to many other languages with their own closed communities, style guides, best practices and general higher machine abstraction induced ease of use, C++ is a different language. With a rich history spanning multiple decades, millions of users from varying backgrounds and the necessity of enabling low-level hardware communication influencing its design and ability to be used effectively, it is a daunting task to acquire enough knowledge and experience to successfully write a standards-conforming C++ program which accomplishes a desired task. Adding to this the plethora of textbooks supposedly correctly presenting their selected corner of the language and with that the immense danger of a poorly written textbook supplying a misleading first impression thus wrecking the fundamental knowledge of the language as well as the path ahead, I hoped for and succeeded in finding a thought-through, holistic and internally consistent as well as surely correct presentation of C++ in A Tour of C++, written by the inventor of and therefore a reasonable authority on C++.
What follows are my thoughts on the book A Tour of C++ , having begun to read it after only sporadically adjusting single lines in C++ golfs and having used it to facilitate a two thousand line C++ project  simulating a ficticious 32-bit architecture . I am in no way affiliated with either the author Bjarne Stroustrup nor the publisher Pearson (Addison-Wesley) and purchased the book on my own.