Programming Philosophy
That Works?! Quines and Other Delightfully Useless Programs

Summarized using AI

That Works?! Quines and Other Delightfully Useless Programs

Colin Fulton • November 10, 2016 • Cincinnati, OH

The video titled "That Works?! Quines and Other Delightfully Useless Programs" features Colin Fulton at RubyConf 2016, where he explores the whimsical and entertaining side of programming, particularly through the lens of quines and esoteric programming languages. Fulton begins by sharing anecdotes from the history of computing, illustrating how playful experimentation can lead to significant advancements, exemplified by figures like Ada Lovelace and Linus Torvalds.

Key Points Discussed:

  • Introduction to Fun Programming: Fulton sets the tone of the talk by inviting attendees to enjoy the 'whimsy' present in programming, diverging from the typical focus on performance and correctness.
  • Historical Anecdotes: He shares stories from computing history, including Ada Lovelace’s insights on the analytical engine, highlighting the prediction of information technology's far-reaching implications.
  • Esoteric Programming Languages: Fulton introduces languages such as Brainfuck and Intercal, emphasizing their absurd and often impractical design, which is representative of programming as a form of art.
  • Code Golf and Obfuscation: He explains the practice of code golf, where the goal is to solve programming problems using the fewest characters, and discusses obfuscation as a playful art form.
  • Quines: A significant focus of the talk is on quines—programs that output their own source code—showcasing their complexity and creativity required to write them.
  • Examples of Playful Code: Fulton provides examples, such as attempts to create a Fibonacci sequence in CSS and a chess program represented as ASCII art, encapsulating the joy of programming purely for fun.
  • Community and Collaboration: The speaker encourages the audience to engage with these concepts, emphasizing the collaborative aspect of programming and the shared joy in creating absurd or whimsical code.

Conclusions and Takeaways:

Fulton's talk concludes with a reflection on the importance of playfulness in programming, illustrating how it fosters creativity and encourages experimentation. He urges programmers to explore unconventional avenues and not shy away from absurdity in their coding practices. Fulton promises to share the code and resources discussed during the presentation on GitHub, inviting further engagement and exploration of these ideas among his audience.

That Works?! Quines and Other Delightfully Useless Programs
Colin Fulton • November 10, 2016 • Cincinnati, OH

RubyConf 2016 - That Works?! Quines and Other Delightfully Useless Programs by Colin Fulton

Performance, readability and correctness are fine and dandy, but what happens when we start optimizing for whimsy, illegibility and outright silliness? Self-rewriting programs that also function as ASCII art? Yup. Rewrite any JavaScript program only using six characters? Why not?

Let's take a break from the practical and laugh at some of the most unbelievable code you've ever seen. Then let's pull out the magnifying glass to figure out how it actually works.

Learn how to read the unreadable and how to write code that—to borrow a phrase from the Ig Nobel Awards—makes people laugh, then think.

RubyConf 2016

00:00:19.480 Hello everyone. I think we’re about ready to start. I want to welcome you to "That Works?! Quines and Other Delightfully Useless Programs." By the end of this talk, I hope all of you will look at the background of this slide and say, "Of course, I know what that does!"
00:00:24.770 It’s incredibly obvious to me. Look, it’s Ruby—that is valid Ruby! So obviously, it all seems very simple.
00:00:30.800 Ruby is such a readable language that you can write code like that. It's great. My name is Colin Fulton, and I'm a front-end developer for a security company called Arbor Networks.
00:00:43.129 If you want to get in touch with me, I’d recommend emailing me because I just joined Twitter and haven't actually tweeted anything yet. However, if you want to see stuff related to this talk, I recommend following me on Twitter, as I'll be posting more there later.
00:00:59.269 All of the code you see in this talk that I personally wrote is available on GitHub. Some of it I have just uploaded, and it’s all under open-source licenses, so if you want to use it in your production code, feel free—though I wouldn't recommend doing that!
00:01:16.610 I want to start this talk with two stories about playing with computers. The first story is from the 1830s, when Charles Babbage was working on a problem and enlisted Ada Lovelace—whose full name is quite lengthy, which is why we call her Ada—for assistance.
00:01:29.450 At that time, if you wanted to do math, you didn't have computers or calculators. To perform lots of calculations, you would use log books filled with tables of logarithms—a huge amount of entries.
00:01:45.950 The question was, how do you calculate a giant book full of logarithms without computers? The answer was simple: you calculate them by hand, resulting in hundreds and thousands of calculations. As you can imagine, a few errors crept in over time.
00:02:05.240 In the realm of astronomical calculations, errors might not affect anyone significantly, but if you’re performing naval or military computations, such errors could be critical. Hence, the errors in log books were a major issue.
00:02:11.360 Charles Babbage worked on an engineering solution to this problem. Though he never built the device he conceptualized, we do have this beautiful fragment—a segment of the machine he was trying to design. This was a mechanical device made out of steel and brass.
00:02:30.769 You would input some initial numbers into it, and by turning a crank on the machine, the full-sized device would mechanically perform all calculations. Unlike a slide rule, it would do exact calculations; if a wheel was off by just half a turn, the entire machine would stop.
00:02:42.650 However, calculating numbers was not enough, because these numbers needed to be copied by printers and arranged for printing.
00:02:48.650 The full version of the machine was designed to include an actual printer that would mechanically lay out all the numbers, and in future versions, it could adjust kerning, spacing, and layout of the table.
00:03:06.049 Babbage never completed this device, as it was incredibly difficult to design in the 1800s, and Babbage himself was notoriously difficult to work with, often disrespecting those who collaborated with him. In his search for solutions, Babbage conceived the idea of the analytical engine.
00:03:36.410 He realized that instead of building a machine solely for calculating log tables—a task that, while useful, had a narrow scope—there should be a general-purpose machine to handle various calculations.
00:03:48.290 This analytical engine was the first real general-purpose computer proposed. It included serial buses, registers for storing data, op codes, and even had microcode to optimize certain operations. However, it was overly complex to implement.
00:04:12.859 Babbage didn't fully grasp several aspects of computer science; for instance, the largest registers that he envisioned could store 100-digit numbers—not binary digits, but decimal digits. No one needed that level of precision in programs. He thought it might be interesting to have more digits available.
00:04:29.870 Where Ada Lovelace comes in is she helped Babbage work on this project and was writing some papers for him. She realized that the analytical engine might not only compute numbers but could also represent other objects and their relations expressed by the abstract science of operations—computer programs.
00:04:53.890 For instance, she wondered if the fundamental relations of pitch sounds in harmony and musical composition could be expressed through this machine, which might enable it to compose elaborate and scientific pieces of music of any complexity.
00:05:39.730 What Ada Lovelace was observing was that a general-purpose machine could operate on numbers that could represent anything you might programmatically deal with—music, text, poetry, and more. She predicted the information revolution before computers and even the electric light were invented.
00:06:08.650 At the time, however, no one thought much of it. After all, this machine was never built, and the idea of computing music or images seemed absurd. Yet, as we know today, it is incredibly useful.
00:06:15.160 Sometimes, just toying around with computers can change the world. Ada Lovelace wasn’t the only one to play with computers, which led to world-altering concepts.
00:06:31.950 The Linux kernel, for instance, was created by Linus Torvalds as a hobby project. He didn't anticipate it would become immensely popular. In his original post, he even mentioned that it could only support one kind of hard drive—because that was all he had access to.
00:06:49.300 Now, as we know, the Linux kernel is a little more popular and relied on by many people. But it started out as just playing around with code.
00:07:02.410 Ruby was created when Matsumoto—also known as Mats—was toying with code, even though the world didn't need another scripting language or another object-oriented language. But Mats wanted to have some fun, and obviously, we're all here today because of that.
00:07:30.186 This talk isn't just about that.
00:07:35.559 It's about having fun in a different way. In the 1970s, a man named Steve Dompier was part of MIT's Homebrew Computer Club—a group dedicated to just playing around with computers.
00:07:56.040 At that time, computers were quite limited. He had just gotten an Altair 8800—a kit you could build yourself. As you can see, it had a bunch of switches and lights, and that was it.
00:08:14.470 If you wanted to program this machine, you had to use these switches to turn on signals for each line of the address bus and use another switch to individually pipe that data into the machine, line by line. This was time-consuming; it wasn't just writing assembly code—it was writing machine code in binary using dip switches.
00:08:41.100 It wasn't the most efficient way to program, but everything has to start somewhere.
00:08:53.430 One day, while playing with this machine, he had a radio turned on next to him, and he noticed that running certain programs produced a few beeps and bloops from the radio.
00:09:07.430 If you've ever had a Bluetooth speaker with an iPhone, you might have noticed, while your iPhone is on, it generates some noise. This phenomenon is due to radio interference. The FCC regulates electronic devices to ensure they don't emit excessive electromagnetic radiation, preventing interference with other devices, such as pacemakers.
00:09:29.910 Back in the 1970s, this wasn't as significant a concern; computers weren't ubiquitous, clock speeds were slower, and these devices weren't well-shielded. So, Steve was picking up the sounds from the computer computations.
00:09:49.110 He found it interesting and decided to experiment with it. He discovered that accessing specific memory addresses produced specific tones. He even pulled out his guitar to check the notes.
00:10:04.000 He would try different addresses and operations, came up with different tones, and eventually wrote a program that played music through the radio interference coming from his computer.
00:10:24.240 By today’s standards, this was a whimsical exercise with no practical application, but he and his friends had a lot of fun experimenting with it.
00:10:36.890 Of course, nowadays, we connect speakers to computers with audio ports, which is a better way to produce music.
00:10:46.890 Today, I want to delve into this idea of programming for the fun of it.
00:10:51.179 This talk is not about striving to create something useful or contributing to an open-source project. Instead, it's about the joy of writing code simply because we enjoy doing it.
00:11:07.640 So, while we often discuss writing good code, efficient code that’s easy to read, and the various aspects of bad code, I want to focus on fun code today. Fun code may be slow, inefficient, or hard to read—yet it is undeniably enjoyable to explore, especially if you love to tinker and solve problems.
00:11:45.319 A word of warning, though.
00:11:49.279 This talk will include really ugly-looking code—extremely ugly code. If you are sensitive to poorly written code or have had bad experiences with it recently, you may want to leave.
00:12:01.580 I hope none of you have encountered code like this, as this is my reaction if anyone ever does something like this in production. But let’s take a moment to relax and understand how all this terrible code works.
00:12:19.589 To begin, I want to discuss esoteric programming languages. These are languages that aren't suited for practical purposes yet can compute anything any other language can, though they are often difficult to write in or just meant for interesting ways to form programs.
00:12:44.350 One such language is called Brainfuck. In jest, I'll refer to it as 'brain fun' since children sometimes attend these talks, but those familiar with Ruby will understand what I mean. Brainfuck operates with just eight commands—each a single character—resulting in very concise code.
00:13:06.770 Brainfuck assumes your environment is an infinitely long tape of integers with a pointer pointing to one of those integers. The commands are designed to manipulate this tape, allowing computation through a unique syntax.
00:13:36.790 However, these operations alone do not yield a Turing-complete language—you need additional commands for loops. Despite its simplicity, the language can still express complex ideas using its minimal commands.
00:14:05.580 Another esoteric programming language is JSFUN, created as a parody of JavaScript. A group of programmers on a forum wondered how few characters they needed to write any JavaScript program using a limited subset of characters. This exploration aimed to evaluate strings as code.
00:14:25.720 In essence, you can represent any JavaScript program in a vastly reduced format while still utilizing the necessary components within JavaScript to evaluate and execute code.
00:14:51.180 We can parse down the characters used, removing any unnecessary numbers. We can rely on the basic operators and structures provided in JavaScript to build complex programs using these limited characters.
00:15:11.210 These esoteric programming languages are not new. In 1972, two Princeton students developed their own programming language to mock the languages of their time, calling it Intercal, which humorously stands for Compiler Language With No Pronounceable Acronym.
00:15:39.020 This language included several new operators and had some features that were left undocumented, making it quite remarkable—especially the requirement to use a 'please' keyword multiple times for politeness, or you would get errors.
00:15:55.960 But you don't need to create an esoteric programming language to display this kind of absurdity. I came up with an idea inspired by Sass, a CSS preprocessor.
00:16:05.540 For those unfamiliar, Sass allows you to use variables and functions in CSS, which helps reduce code redundancy. Its capabilities include creating Turing-complete languages through constructs such as methods and functions.
00:16:23.480 Here's an implementation of Fibonacci using Sass. It's amusing to consider adding a Fibonacci function to your CSS, which, while not common, reflects the potential to challenge ourselves with unusual problems.
00:16:58.620 Now, there’s Lisp—a family of programming languages that symbolizes code as nested lists. These lists are encapsulated using parentheses, and the first item in each is interpreted as a function, with the remaining items as the function's arguments.
00:17:20.740 I created Sassy Lisp—a combination of Sass and Lisp rules. It's a playful interpretation of these two languages and allows nested functions, closures, and variable scoping.
00:17:38.830 The implementation includes numerous helper functions while maintaining the structure necessary for classic Lisp operations, all crafted inside Sass.
00:18:06.300 However, this is not practical for production code—as your colleagues might think you're a little crazy—and is quite inefficient. Yet, it serves as a playful exploration that emphasizes programming's fun side.
00:18:20.360 Now, let us shift to code golf—a game where you attempt to write a given programming prompt in as few characters as possible. For instance, fizzbuzz is a classic exercise.
00:18:38.200 You print numbers from 0 to 100 but replace those divisible by 3 with 'fizz,' numbers divisible by 5 with 'buzz,' and those divisible by both with 'fizzbuzz.' Here’s a typical implementation in Ruby.
00:19:12.150 As with code golf, the goal in this case is to refine code reuse, finding efficiencies and reducing repeated patterns while attempting to condense the code into as few characters as possible.
00:19:36.560 In the case of fizzbuzz, we can utilize logic to dry up our implementation significantly without losing clarity. This process continues until we reach the desired character limit.
00:19:49.820 Obfuscation is another avenue of fun. The International Obfuscated C Code Contest elevates the absurdity of writing unreadable code to an art form.
00:20:08.480 You’d be surprised at how intricate and confusing these programs can be! He Yusuke Endo is a Ruby core maintainer known for his obfuscated code as well.
00:20:20.450 Just for fun, I'll demonstrate one of Endo’s obfuscated C codes—a print statement that outputs 'Hello, World.' But be wary! It may look simple, but the behind-the-scenes mechanics are quite complex.
00:20:37.860 As you can imagine, the final output will differ from the initial code itself. This highlights the concept of code that behaves differently from how it is presented.
00:20:51.360 Now let's transition to a different esoteric exercise known as a Quine. The rules here are quite simple: your program, when executed, must print out its own source code. This adds a layer of complexity to coding.
00:21:04.340 The challenge arises from the requirement that the program cannot read from its own file, which kind of messes with our ability to craft a solution. But with creativity, we can build a working Quine!
00:21:20.180 In Ruby, we can use various interpolation techniques to execute this challenge, allowing the output of the original program's source code, even with variations.
00:21:34.090 Moreover, with some clever coding, we can even extend our Quine to allow for slight modifications and manipulations without losing its self-identity.
00:21:40.820 As a side project, I proposed creating a chess program designed as a Quine, where the chessboard itself is represented in ASCII art, and the code to create it is also embedded.
00:21:56.970 This concept allows adding playful elements while maintaining the essence of a Quine, enriching the overall experience and creativity in programming.
00:22:10.510 I was motivated to explore this realm after reflecting on the flexibility of Ruby's syntax, where we can distribute codes widely without compromising architectural integrity.
00:22:24.990 The thrilling aspect of programming is that creativity can lead to unexpected results, as demonstrated by the chess program I crafted.
00:22:38.890 Finally, although the implementation of this chess program involved reams of code, the final result is still a bit humorous as it outputs an entirely valid chess board.
00:22:52.890 And yes, we remained open to the possibility of receiving user inputs during the gameplay!
00:23:07.890 My exploration of lambda chess concluded successful, following a lengthy execution process to execute complex calculations.
00:23:21.890 All this quirkiness and experimentation in programming leads one to reflect: why do we commit our time to absurdities? For some, it's a joyful distraction from convention.
00:23:36.980 Ultimately, these exercises present a platform not only for creativity but also a venue for collaboration among programmers who share an appreciation for playful exploration.
00:23:49.670 Thank you all for entertaining this notion. Please consider exploring these ideas further—whether that be through implementing your own interpretations or simply having fun with the process.
00:24:05.820 I encourage you to reach out if you’re curious to see more code of this type or discuss further insights. Let's educate one another in our programming journey!
00:24:13.460 I will be putting the code and resources from today's talk on GitHub, and I invite you to engage with it. If you’re interested, feel free to follow me on Twitter where I will be sharing more and fostering connections.
00:24:31.420 Lastly, if you prefer not hearing from me again, that’s perfectly fine too! Thank you for your time today.
Explore all talks recorded at RubyConf 2016
+82