JANELLE: Hi, everyone. Welcome to Episode 125 of Greater Than Code and I am here with my fabulous, beautiful, wonderful, crazy, awesome co-host, Jessica Kerr. JESSICA: Good morning. Thank you, Janelle and I am here -- right here -- with Avdi Grimm. AVDI: Yes, I am Avdi and I am very, very, very thrilled today to be here with our guest, Sam Aaron. I first met Sam, I was at a conference in New Orleans and it was conference, conference, conference, code, code, code all day and then, after all the conferencing was done, there was a party at The Aquarium and in The Aquarium, there was this guy creating electronic beats live using Ruby, up there on the stage with his laptop with the code projected on the wall and it was fabulous. I actually got to dance at that conference and it made me so happy. Since then, I have had the great pleasure to get to know Sam a little bit better at some other conferences and he makes music with code and not only does he make music with code but he uses that as a way to get kids into coding. I love everything that he is doing, so Sam I am so, so happy that you joined us today. SAM: [inaudible], thank you very much, Avdi. JESSICA: I know how. I know how. You tell us what is your superpower and how did you acquire it? SAM: I think probably, it is the ability just to stare at the same problems for days until I solved it and not give in. When I tell the kids to how to code, that's when they say, "What we need to learn to code?" We just say, "A lot of patience," and also, the ability to delay our gratification as well, so to know that I will feel good in, maybe a month if I keep on this every day. That's my special power. JESSICA: This is how you got into academia? SAM: I think it's how I gone to programming in general but now, I am actually no longer in academia. JESSICA: Yeah. AVDI: You won. SAM: Yeah, it depends on which side you're looking at. It is always a half-full cup. JESSICA: Oh, you have a PhD. SAM: Yeah, I do have a PhD. JANELLE: I can definitely see those things going together, though like patients and delayed gratification in research problems. I definitely have this research gravity in myself of easily getting obsessed in staying with a problem because of that continuous stream of gratification that comes as you get clarity and kind of understand things. I'm kind of wondering, if you thought about your poles in that world, what problems just fire you up inside? SAM: That's interesting. I would have broken those into two separate things. I think that delay gratification thing, it does lend itself to a kind of academic mindset but additionally, I think it really just describes a programmer, where most programs really just sit in front of things until it work, so that's the general sense. But in terms of programming and the areas I find interesting, I'm particularly interested in seeing programming as a form of communication to converse with a computer or with others through the medium of programming itself and what that can offer in terms of the kinds of things you communicate and also, the kind of frictions or the speed of the communication. I think those are really two different, interesting dimensions to explore when you're considering programming as communication. AVDI: I would be curious to hear more about examples of programming languages or programming idioms that aren't so much a conversation and idioms that you think are more conversational. SAM: I think everything is conversational, actually. AVDI: Is there anything that in your mind smooth the way to the conversation? SAM: Yeah, I think first of all, just standing back and thinking of what you're doing when you programming of any kind, explicitly as an absolute communicative exercise, I think that can shed new kinds of lights on what we're doing. It's not always the right thing to do, obviously but it's useful in certain situations and when you do start think of it as communication, you start asking, "Who am I communicating to? How effective is that? Are they likely to understand? How can I test they understand?" When you talk to other humans, hopefully you spend a lot of time verifying that person's understanding of what you're saying and not being offended or their focuses and the way that you're hoping to push it, so that the communication is effective. If you just try to communicate, just to have fun, to be aware of that as well, there's not necessary any content in the messages, just a small body language or just excitement or laughter. When you explicitly see programming in the form of communication, that shed new lights, that helps you understand things from waste, to take it from the really abstract to something a bit more concrete, one of the things I tend to try and do is to think about, in the particular thing I'm communicating, one of the things which are not going to change very much, one of the things which I like to change a lot and to try and find that distinction. I think that's really always a critical thing because once you can agree on some things in conversational in domain, I think that allows the fluid things to be much more fluid. AVDI: Interesting. JESSICA: So in domain driven design, when you establish a model and you layout some definitions within the context of our discussions here, this has a specific meaning and this has a specific meaning. SAM: Precisely. Yeah. Once you do that, then the rest of the flowing stuff just flows around that much more fluidly. Because it go back to Avdi's point about what's more or less communicative. I think that's actually a really interesting question would be, what kinds of things have a lot of static things, a lot of those defined unmovable, immutable things and watch the concept of a lot of movable things and to understands what you're working with in which particular context. This also could apply very loosely but I don't want to get down to the wars of static versus dynamic and typing versus non-typing but I think these things also become a part of this discussion as well. If you're doing a formal proof, there's not many moving parts once you've defined it, for example. JESSICA: Approved types tests, all of these hold something still. SAM: Yes, absolutely and they all could be used as a means of communication and knowing which things are fluid, which ones aren't can really help your process. JESSICA: What is fluid? SAM: For example, when I was working in industry, I had a client who had come in every week and describe parts of his system or their system and those descriptions, they change dramatically every week and they were inconsistent. In my head, a professional programmer, which I clearly wasn't and probably never will be, would have sat down and said, "You must now define all this stuff and one will person will write it down and I will sign a contract and if you want to deviate from it, then it's going to be a rewrite of the contract and it's going to incur different costs," for example or incur different time frame for the project, so you need to define what it is. I knew that if we did that process, it would be a complete disaster and the project would require that thing to be rewritten and it would be disastrous for everybody. Instead what I did, was I remember all our conversations and I figured out which parts of the conversation is actually didn't change across each week. I sat down with them and said, "These things here, are you sure these will never change?" He's absolutely sure. Because it was so obvious to him that it was static. I then built a language around those constant things that grows much more fluid and then he was unable to change the system, try to launch and join after launch based on being able to write something which is much more close to his language and his domain. That's more DSL-style approach but having an understanding of what aspects of his communication were fairly constant and it's pinning them down, I guess it's a DDD-style approach, then we need [inaudible], what I'm trying to say. JESSICA: That's very interesting. I used to think that as a programmer, it was my job to get the requirements and to get the business to tell me what should happen in every corner case and I'm really annoyed some people doing that and now I get it, that there's always conflicting requirements that -- SAM: Yeah, it's changing. JESSICA: Yeah. It's a negotiation. It's a conversation and in that case, this running software itself that's communicating to the business so that they can then communicate what needs to be different about it. SAM: Absolutely. This communications everywhere, like logs for example, one of the first thing to do when I'm building a new system is make the logging as good as I possibly can because that's one way of getting the computer program to talk to me about what it's doing. AVDI: Tell me what you think goes into good logging. SAM: I can't define good for everybody but for me, it's the ability to have the right level of verbosity and to go in and to modify that but really, all going into one central thing, ideally and in an ordered way. It needs to be ideally totally ordered -- JESSICA: By ordered, do you mean structured? Or do you mean sequential? SAM: Yeah, sequential, in a way that you can sort it. You call that sort and always gives you the same list. JESSICA: Okay. It has a deterministic order. SAM: Yeah. This is where I'm going now. This is not what I was doing in my previous systems. I wasn't thinking about this when I'm logging but logging now for me is how it's sorted, it's totally ordered, it's deterministic in that sense. It's immutable, it's serializable, obviously but also enables things that pattern matching at risk, be able to find and filter and sort. So kafka-like event logs, for example fit these kinds of descriptions and I’m working on for my own systems. Again, if you can serialize as well -- JESSICA: You're on logging framework? SAM: Yes, absolutely. I'm actually building a new language with logging at the heart. AVDI: Really? SAM: Yeah. JESSICA: Have you heard of Honeycomb? SAM: No, I haven't it. JESSICA: It kind of does this but with events. SAM: Can you describe more? JESSICA: Honeycomb is about structured events. SAM: Yeah, what do you mean by events? JESSICA: An important thing happened in the system, kind of like a log without the message fields. AVDI: It's about observability, right? I figure, if that's the term -- JESSICA: Yes, so observability in its strictest sense. The charity actually has a pretty strong definition for it. SAM: I'm struggling to see any distinction between a log and an event at this point. JESSICA: Exactly. A log is an event with a description and a Honeycomb is an event aggregator that basically puts them on a custom databases that they've created, so that you can query and you can index on fields that are high cardinalities, the technical term, like session ID that are extremely different despite of you need to group those then you can narrow and filter your traffic in a lot of ways. An event is just a structured log without the message. SAM: I'm using open sound control as my current protocol for these kind of events. JESSICA: Say that again. SAM: Something called open sound control. JESSICA: Open sound control? SAM: Yeah. It was designed to replace MIDI. This is the old school, in the 70s, early 80s protocol for keyboard -- to talk with the keyboards, essentially. That protocol is still around today but it has some limitations. An open sound control was designed to try and replace those but actually, it turns out it's much more useful protocol than just replacing MIDI -- people using robotics and for controlling all sorts of cool things. It's a very simple format. It has a binary protocol. It has binary representation, which has a URL style string -- /foo /bar/ baz -- and then a bunch of arguments, which can be strings, floats and integers but with some extension types. Then, it defines a very simple pattern matching that you can apply, so you can search for subsets of these things using regular expression-like things and also, what's really nice about it is you can put these messages into what they call bundles, which means specifically timestamp because I'm also very interested in time for the kind of systems that I work on and so my logs, the part with total ordering is a notion of logical time, to make sure that the time isn't just the current time because that's not very deterministic but some logical sense of time. JESSICA: Oh, okay, so like a world [inaudible] time as supposed to physical world time because that has a lot of context dependence, a logical-like conceptual. SAM: It's just like an integer, really. AVDI: Yeah, like a counter time as supposed to wall clock time. JESSICA: [inaudible]. AVDI: Yeah. SAM: Yeah, exactly. This is for the kind of weird systems that I'm building. I'm not saying this is -- JESSICA: What kind of weird systems are you building? AVDI: Yeah. Let us talk about systems that you're building and if we could, I'd love to start with Sonic Pi because that's what you are so identified with. JESSICA: The Ruby one or the Clojure one? SAM: Well, it's all sorts of languages and so I had Sonic Pi. The language itself that the user uses is a DSL-based type of Ruby and that runs as little server process, which has side effects, which send these open sound control messages out to something called SuperCollider, which is a synthesis engine. The SuperCollider synthesis engine executes synthesizers, which I've designed in Clojure using overturn which I have built with Jeff Rose, which is a compiler which compiles Clojure data structures into these little binary synthesizer files. There's also Erlang in there for communicating with external process and GUI is written in C++. The Erlang there is a bit ridiculous because it was written by Joe Armstrong. He was totally into Sonic Pi and really helped out. We also have bits of C, which convert open sound control to MIDI and vice versa. JESSICA: That part makes sense but C++ for the GUI is hilarious. Are there historical human reason for that? AVDI: Is it a QT? SAM: It's QT. Although the Germans called it 'cute' and the reason why I'm using that is because it's cross-platform and then the first version of Sonic Pi, it has to run on Raspberry Pi 1 which is a very, very low-powered device and so, any web solution was totally, not even in the beginning to an appropriate thing. It had to be blazing fast. JESSICA: So it's a native-compliant for various -- AVDI: It's a widget tool kit that you can compile to pretty much anything and yes, it's built on C++. What was the origin of this project? SAM: Sonic Pi, particularly that was a response to a very small grants, which the Broadcom Foundation were trying to essentially get people to write something interesting for kids for the Raspberry Pi. Raspberry Pi just been launched about eight months prior. It was ludicrously successful. They were attempting to try and get more kids to program and part of that was to create low-power but also, low expense hardware -- that's what Raspberry Pi was but also to then get interest in kids software to run on that, that kids could use. A lot of the software that was around at the time wasn't really designed for low-power devices or low CPU power devices and so, there was struggle on Raspberry Pi. Raspberry Pi Foundation were giving money to organizations who try and optimize the system, so Scratch for example. They spent a lot of money on trying to optimize a Smalltalk VM for all the aspects of it for the Raspberry Pi and give facilities. But then, Sonic Pi was an attempt to build something new and what could be built and I was working at the University of Cambridge computer laboratory on a different research project, which is very similar to Sonic Pi, of course, so why it's a nice segue, which was Overturn, which is my weird ideas along with Jeff Rose and many others, of trying to build the craziest, most powerful language environment for creating new kinds of musical instruments. That was both dealing with the synthesis of sound, the mathematical properties of how you turn numbers into sound and how you manipulate those numbers but also the interactions you might want to create from the body to those synthesizers. You would build, either physical devices or use the existing, off-the-shelf MIDI devices or open sound control devices and then network them together, so the events of one device would be able to be mapped in an unappropriated synthesizers. I was exploring Clojure because I was very interested in highly dynamic languages. Ruby was something I was really very excited about at the time but I also tried to build early synthesizers in a concurrent fashion in Ruby. My concurrency skills were unbelievably bad. JESSICA: I really have [inaudible]. SAM: It certainly does not, so yeah, a shared memory, a bad combination. Anyway, Clojure offered a solution to this. It's also faster and have all the amazing JVM libraries available readily. It talks about time in a very different way than I took about time but I had notions about atomic operations on data. Data can either be this or that and there's no in-between. These kind of things really resonated with me stronger and so, I want to build a language on top of that and discovered that a chap called Jeff Rose had already started working on a project called Overturn and he's also living in Amsterdam where I was living at that time, so we made immediate friends and then hack on that. But Overturn had a number of problems and I think these are interesting in terms of our original discussion about time and communication, mainly because you could build pretty much anything that you can imagine in Overturn. It's a very powerful system for turning ideas into musical instruments but it takes a long time. It also requires -- AVDI: In terms of programming time? SAM: Yeah, absolutely and development skills required to do that, so you can't just make a sound. You have to design a sound. What on Earth does that mean? I used to learn about envelops and filters and directed to graphs and computation, which you're describing their audio pathways and all these stuff is beautiful and super interesting and I recommend anyone listening to spend time doing it if they want to but it's a very niche, as you might say, passion and to ask the question, would you like to make an instrument. A lot of people would say yes but then, if you then say, "Well, you then need to learn synthesis design," that's a huge barrier to entry, a huge amount of friction. JESSICA: I think they're not as hot. SAM: For sure and that's why just going on to the piano and just opening it up, opening the lid and just play, you know? I'd say, you want that kind of level of immediacy and so, I go around to give these talks about Overturn, people would get super excited to go to their hotel rooms or be out and walk down the corridors and hear that crazy sounds but it never ever progress better than that because no one can really do anything interesting than this. I think because I didn't focus on the feedback cycle as a process of using the system. I only thought of it as a developer. When the developers talk about Language X versus Language Y, they tend to talk about in terms of power and that power is rarely talked about in terms of time. You might say, "I can solve this thing in Language X and I can write such a structure of it that is defined to be true," or it's very hard for it not to be true or it's very elegant and you can clearly see that it's very closely related to the language that I am working with the business. There's all these lovely things but no one ever says, "But actually, it took me six months to get to this point." JESSICA: To be able to get that kind of power, to be able to write that set of language? SAM: To write the solution, to construct the solution, people are asking about the time it takes. JESSICA: Yeah because we can do anything in programming and I get so excited about all the things that I could do and then I remember that no, I can only do a few of them. SAM: Because of time and age. This was really emphasized when I started doing live coding before as Avdi was saying. Because when you're writing code on stage, you do not have four days. You only have a day, you only have an hour, you have half an hour, you have 10 minutes, you don't even have a minute, you have like 20 seconds. AVDI: Until the loop comes around again. SAM: Yeah. What kind of programs can you write in 20 seconds? It's an interesting question to ask. In Ruby, it's a very weird constraint. AVDI: Yeah, you're like the most agile programmer. JESSICA: [inaudible] 20 seconds long. SAM: Obviously, that limits the kind of programs you can write in 20 seconds. There's these dimensions and constraints but if we really take it to that extreme and what can you write in 20 seconds, so that forces you to think about programs as communications and it forces you to think about how do I really optimize the communication service as precise enough but also, efficient enough. My system as one of many kind of systems and lots of other [inaudible] that explores these dimensions in different ways. For example, there's a system called title cycles, where [inaudible]. It's a lovely language but that's optimized for reducing numbers of key presses. The language is very terse and as a consequence, it's very hard to read and might be very hard to look at the code, know what it's going to sound like and the same way, I might take a bunch of spirographs and to choose different cogs. I can describe which cogs I’m using but to describe the actual output is a very difficult process because different wheels can produce radically different spirals, if that makes any sense. JESSICA: Yeah. SAM: It's a simple thing to describe but it's very hard to predict what's going to look like. JESSICA: You just contrasted, "I can make a solution that is very hard or impossible to make it incorrect but it took me six months," versus, "I have something that's precise enough and gives enough feedback quickly and efficiently enough, that I can write in 20 seconds. SAM: Yes and also I know what's the constraints are, the space of things I can actually write in 20 seconds, so it drastically reduces the number of things you could do in that time. JESSICA: But you can make a lot of cool sounds. SAM: Yes, absolutely. That to me, that's the exciting things. I want to be able to express myself and so, the level of my expression for me personally as an artist is the ability to convert my thoughts into actual resonating sounds as quickly as possible and I'm using code and other things as a way of doing that. JESSICA: Which we get to convert into dancing. SAM: Yes. AVDI: I love the sense of an enforced tempo there. I think it's a really interesting kind of constraint when there is a fixed tempo, both in processes of creating things and also, in software systems. SAM: What do you mean by tempo? Do you mean like a repeated beats of --? AVDI: Yeah. You're talking about 20 seconds, which is -- JESSICA: This is not an arbitrary deadline. SAM: Yeah. To me, I was describing it more as a max duration. If it's longer than 20 seconds, that can, for certain parts of the music, start to irritate people because it just repeating. It has to change every 20 seconds. On some parts, you want lead the longer for example but you often get to a point in the piece and it's jarring or you know it can go in a different direction and wanted to get it there and then how do you get it there. JESSICA: So it is not a fix but it is adapted according to the context, just the context is sometimes is extremely short and always [inaudible]. JANELLE: It's interesting listening to this. I feel like Avdi is probably biased by having conversations with me over the last weeks about clocks. I'm very obsessed with clocks myself. SAM: What kind of clocks do you mean? JANELLE: I've been really frustrated by a few different problems in the software world and one of them that I've been working on recently is a sort of a stateful alternative architecture for doing stream flow processing and coming up with a way to do generalized, assumable structured flows. SAM: Explain to me the meaning of assumable. JANELLE: I've got buckets of time, say that are in hours, days, weeks, etcetera and so if I think about a moment of time, I can think about that moment of time that I'm in as a small window. I can have like a 20-minute window as my smallest increment and then, in that moment, I'm also within an hour, within a day, within a week, within a year, etcetera so I can have different time scales, different zoom levels and still be at the same position with respect to a geometric coordinates. The way I think about time is almost a little bit inverted with the way I have the clock setup and I have a minimum increment of 20 minutes and then, I look at an hour as having three 20-minute increments, essentially and so, by structuring the event in terms of a time scale that starts with a minimum, I think of like a ticking metronome over time, how many beats in a measure and then, if I've got three 20-minute slices, say the math adds up to an hour and I can aggregate up different zoom levels by looking at relative time within a particular set of coordinates. If I think about a quarter note, if we think about four beats in a measure and I've got these quarter notes, I think about a half note as a doubling of a quarter note. JESSICA: So what does this do? I also think about half notes as a doubling of a quarter note but how does this relate to your flows? JANELLE: When we're talking about doing spirals and looking at logging in relative time, you have a set of events that happen relative to something else. For example, if I start a job on a server and I'm trying to look at all the events that happen, the significance of relative time is how many ticks of the beat after I kicked off the job. My kicking off of the server job is like a start is the beginning of a sequence and then, I count relative time from the beginning of that sequence of just 1, 2, 3, 4, 5 and if I divide up beats of the measure of where stuff happens, then I've got coordinates of things and then I can look for patterns in coordinates. JESSICA: You're looking for patterns. JANELLE: Essentially, yeah. You're looking for patterns of events in time. JESSICA: Why do you that? JANELLE: When we're talking about making predictions, I'm talking about -- JESSICA: Can you give me a concrete example? JANELLE: Sure. I was just thinking with respect to like, we're talking about Honeycomb and monitoring and logging of what your servers are doing and so, if I've got a server that has, let's say a bunch of job runners where things that I can kick off and I kick off a job on my server and it starts running and the memory starts increasing and my memory increases at a certain rate over time and then down the road somewhere, there's a spike. Then the next time, say the next day, I kick off the exact same job, memory climbs for a bit and then maybe an hour and a half goes by and then, there's a spike. If I want to look at patterns in time though for that particular job, what I want to do is align all the start moments, where the job kicks off and then look at the patterns, in terms of sequence of events in time from that start position, so the relative sequence is relative to an event. I feel like, with the way that we ought to be looking at clocks is the positioning of the clocks themselves, the coordinates are essentially like relative time within a scope and that scope can be something that varies, so if we want to know like where are the patterns across all the server jobs, I want to look at the patterns in time and the patterns in context and how does affect the numbers, so I can find out what potential cause of events might be causing that spike. At the end of the day, the thing I'm trying to uncover is what is the correlation of things that contributes to the spike and those are all timing-related but they're not timing-related of the server doesn't care what time is on the counter. What the server cares about is what time the job was kicked off, so it's all relative on how much time went by since the job kicked off. I think how we need to start measuring like the way with we to blogging is everything is relative. SAM: This is exactly how Sonic Pi work. You've described exactly how Sonic Pi does its internal logging systems in time. When you start the program, it starts to run, it captures the current time and anything else is [inaudible]. JANELLE: When you were describing in terms of the language that you're building, I think it might have a really good use case for it too, like I was planning on writing my own language for this kind of thing but since you're already working on this, I feel like it is probably exactly what I would need to build to do what I'm working on. SAM: That's interesting. Do you still got patterns through time in these events that you're looking for? JANELLE: Yeah. SAM: How do you come up with a pattern you're looking for? How did you describe it? What are these things look like? JANELLE: I gave an example with a server job kicking off but what I'm really doing is the data I'm measuring is developer activity, developer flow. For example, if I imagine a developer doing their job and if I imagine these components that we work in are like rooms in space and I navigate around these different locations and space as I'm navigating around different codes, I get a description of my code model that is divided up into component rooms with a simple light package filter like if the code in this package, it's this component. Just essentially -- SAM: Could that [inaudible]? JANELLE: Right now, I'm doing things at file granularity, so each file is a location and each component is just a package filter. I'm a Java developer by trade, to turn on your Java brain. SAM: So that's also, [inaudible]. JANELLE: Yeah. So then, I've got these component rooms and as I am navigating around these different rooms and navigating to different locations, sometimes I'm just looking at something, sometimes I'm modifying things, sometimes I'll be executing some things, so I've got all these different types of activities that are happening in this context of this flow through time in these rooms. Then when I go to different rooms, I imagine this going across a bridge between these two components through a hallway to this other place. I have a space model where I've got these rooms and these locations and place in space and then I've got a set of coordinates that are based on time. For example, the tools that we use for measuring in monitoring idea flow is modeled off of anatomy of a conversation, which is why I like listening to you and going, "We need to talk." But essentially, I have the developers get in the habits of breaking down their work into intentions: what is my next intention? What am I trying to complete with this next little chunk of work? What am I trying to accomplish? And so, you keep a journal of your intentions as you're working and then in the background, you're kind of navigating through space and then I'm dividing up the work according to these intentions and all of the relative sequencing of clocks is relative to the start events, these moments in time when I start a new thing. I am basically getting flow feeds that are organizing the overall structuring context of the developers to flow through the code and then, I'm building a friction model on top of that, so every time you run into something unexpected, you hit the DevTF button and then, it starts a kind of collaborative troubleshooting session with your team and you all kind of work together on conquering the DevTF and then from that time period, from the moment you see an unexpected observation, whatever it might be, something that causes confusion from where you're at, to the moment that you get that result is you can think of like TTR metric, where we've got some time -- SAM: What does TTR mean, sorry? JANELLE: Time to resolve the DevTF, basically, so it's a -- SAM: A TTR [inaudible]? JANELLE: Yes but it's something you can think of a friction as having frequency and magnitude over time. We've got our flow model and then we've got our friction model on top of it and each has relative geometric coordinates and essentially, this is how I think about ideas flowing, whether they're ideas flowing between our brains and the code and we're trying to communicate an idea by molding the code like clay to represent an idea in our mind or if we are reading the code, reading an idea that is inside the code, it's kind of like moving that idea from inside the code into our head and we've got flow between us and the software and ideas flowing in between so you can think of a connection with ideas flowing and then, we also have flows between people and then in both cases, in both context, we've also have this friction or these DevTF moments that are these points of confusion where we recognize this other human or this computer on the other side of the wire does not understand what we're trying to say. I just wrote some code or were sent out a message into the air, turned a thought in my head into sounds as you put it before and that process, sometimes doesn't get understood, right? SAM: What you're describing as feels very much like the kind of approach I've taken to developing Sonic Pi as a process but also, this [inaudible] if you consider but maybe you're interested in [inaudible], which is when you press a direct button, that might not be the right moment to solve that problem, maybe because you're [inaudible] and I've been doing that thing. This thing pops up at me, "Oh, no, [inaudible]," but I haven't got time looking at it right now because if we do -- JANELLE: [inaudible]. SAM: Yeah, exactly. When I was practicing coding in the early days, I was rewriting, well, making some music and get my [inaudible] takeover the practice and I end up in the EMACS and not doing anything. It's actually [inaudible]. Whereas, [inaudible] and come back to it later but [inaudible]. It's the kind of thing you described, which is much more detailed set of logs which context-specific about what will happen so I can then go back to that effect and explore what have might gone wrong. Was that fitting in what you said or was that completely --? JANELLE: Yeah, on the DevTF, I have a do-it-later button. SAM: Yeah. AVDI: I haven't [inaudible] for this conversation. Actually, there are a few things that I want to talk about but there's one I had just inserted in front of that which is that it follows on for something you just said. When you are at live coding to create music, the last thing that you want to happen is for something you do to crash the whole system, the crash the whole piece of music. I'm curious like that's interesting to me because strategies for that seem relevant in production systems of the non-musical production nature and I'm curious what kind of design constraints you put into your Sonic Pi to mitigate one whoopsie, bringing the whole performance to a halt? SAM: Good question. It should also be pointed out that there are a number of life-cutting performance that actually do want to crash the system during that performance. It's not necessarily wanted to avoid over time. Actually it crushes [inaudible] artistically. JESSICA: Like smashing your guitar? SAM: Precisely, [inaudible]. There's a function that you can write which will terminate a system in a known times in the future. You can set a time and turn and [inaudible]. You can also call the help line function to then, if you actually discover the interest to revert that, so it doesn't crash. I think there are interesting things where the crashing is an important part but yeah, to answer your question, when I'm performing to a lot of people, I typically don't want it to crash because I want people to keep dancing and when it crashes, the dancing stops. What I do is I spread my bets, essentially over a number of threads. First of all, I assume my system itself, that the core of the language doesn't crash. That's really the important part and then, Overturn tends to user code with crashes. Of course, it's very easy if you write code to just type in the code, so user crashes are extremely common -- JESSICA: And we have the dynamic language. SAM: Yeah, exactly. The run time error is essentially a very common thing. If you spread your bets, if you have multiple threads, then only the thread that has the error will die and all the other threads will continue to execute, so if you always have a least one thread [inaudible] and then don't change multiple threads simultaneously unless you really sure what you're doing. Just change it one at a time. AVDI: Oh, like rock climbing. You move one leg at a time. SAM: Yeah. Don't do the spring jump. That could be fatal but sometimes, you need to do, though. I'm sure there's some particular [inaudible] from one point to another to make it [inaudible] but it's very dangerous to me. AVDI: I feel like a lot of programmers try to make that move all the time. JESSICA: Yeah. SAM: Absolutely. AVDI: -- one leg at time is [inaudible]. JESSICA: Revert! Revert. SAM: As I'm getting older, I'm working on smaller and smaller and smaller chunks. I'm really like, "Is this working? Is this working? Is this working?" all the time. JESSICA: Yeah and that's the feedback and that's the conversation, right? SAM: I'd say, it's definitely a part of the conversation when things go wrong. I think the interesting question if you would consider this but as soon as you're in a performance situation, and you've got all these threads which are generating beats and one of them dance because you made a typo and then you can clearly see the typo. You fixed the typo. How then do you get that thread to restart but in time of anything else, is the critical question. Typically, concurrency don't talk about 'at the same time.' It just talk about simultaneously, so in other words, at the same time would be people clapping where every claps where you just hear one clap even though there are 10 people clapping. Whereas, simultaneously, it's like applause, where ever was this clapping randomly. We hear a lot of different claps. Most programmers are these last types where you just got lots of claps all happening at the same time but at Sonic Pi, it tries to enable users to be able to have all these claps happening at exactly at the same time. If you are -- JESSICA: It's coordinated. SAM: Absolutely, temporary coordinated. If you wanted to bring that thread back into the life, if you haven't brought in in time [inaudible] as well, it's interesting. JESSICA: Yeah, that's cool. JANELLE: This also goes like I was thinking about the logging use case. If we got a server job that we kicked off and we're trying to monitor the behavior of the server in time and if you got a start event of when this job was kicked off and maybe, we've got that job kicks off every day, every week, whatever these different times are and you've got these patterns of memory usage and these memory spikes over time that are relative. I can think of the servers or these instances of the server job going off as a clap and then, we could take all of these instances of these server job kick offs over time in alignment and in synchronize and temporarily coordinate those so that all the claps happen at the same time, so then we can look for patterns in relative time, relative to the start of the kickoff of the job. SAM: Sure. You're basically looking for rhythms. JANELLE: Exactly. Looking for rhythms in memory usage from a server job. SAM: Nice. AVDI: While we still have time, there are a few more things I really want to make sure that we talk about and one of these is just your work with kids. Can you tell us about what kinds of sessions you do with kids and how you run those and what sort of results you've seen? JESSICA: Yeah, how they react? SAM: Yeah. I'm doing a whole different plethora, different style of interaction with children. First off, with working with a teacher within a school, these are 11-year old children and that's when the first version of the Sonic Pi was born in that classroom, [inaudible] and that gave me great insights to the constraints you have when you work with children and anyone learning particularly, it's not just to children. Adults are actually much more interesting, difficult [inaudible]. It's an easy to problem to [inaudible]. Children also force you to consider simplest thing, actually and the education context as well and you should think about that everywhere, everything you do, to be honest and I think it's very easy to consider teacher something to an adult and not considering making it super simple, whereas you wouldn't do that in a child. You always want to simplify that but I think [inaudible]. But what children also do is they provide often a curiosity and an interest and an open mind, which makes this stuff much more friction-free, whereas adults often come with closed minds or pre-conceived ideas and it's often it can be much harder to get and to see things in new ways. This is particularly evident when I talk to music teachers. I have a much harder time to talk to computer science teachers. That [inaudible] in tech. But to kids, the kind of thing that [inaudible] lessons in classrooms and schools, so teaching computer science and also teaching music at young levels, six to 11-year olds and 11 to 16-year olds. I've also giving workshops in universities and there'd be technical music courses, so I'm also using code in composition which is not new. This has been going on since the 50s but something brings a different tool to the bag and a different focus on simplicity and focus on administration. The most [inaudible] what I've done is when I've done things in museums where it's been a [inaudible] that children's school holiday, so of course all the children's parents will then fog off their children to the grandparents. They can have enough day out and do their own thing. So the grandparents then take their grandchildren to these kind of museum events and I've been giving workshops to grandparents and grandchildren combos and that's absolutely delightful. It's really nice to see they're both engaged in making sounds to showing headphones [inaudible]. The things I've typically done have been very much introductory computer science, introductory live coding and the results have been super exciting in the sense that people can go from nothing to make a sound very, very quickly and the range of sounds that made across the classrooms, whether they're children or adults, it's dramatic to the extent where if you [inaudible] to one of the participants and play that music out to everybody else, it causes everyone to be like, "How on Earth did you make that sound?" You would say, "Well, go and ask them," and [inaudible] through showing off the work and people get excited by it and things [inaudible]. JESSICA: Oh, yeah, through amplification. SAM: Through amplification, absolutely and also promoting and treating like don't work in an isolated fashion. No workplace is like that although most schools, see to force this kind of ridiculous, I'd say [inaudible] working which it doesn't seemed to me to make sense for educational or in general but actually just say, "Go and cheat. If you like that code, go and ask them how they made it," and take snippet from it or maybe change a sample or maybe tweak here and there. This is what programmers do all the times with stack overflow. We promote that kind of behavior -- AVDI: I love that. SAM: But I haven’t done yet and this what I'm excited in the future is to go past that really beginner stage. There's a lot of people starting to code, starting to make music, starting to have fun but moving to what I do when I'm performing, that's still a pathway, which I haven't really figure out yet and I'm working at the moment. AVDI: I love the idea that this concept that preventing cheating is just the wrong model for the real world because that's how real functional teams work and anybody working and creating in the world works is you build off of other people's work. Everybody builds off of other people's work. I love glitch. If you mess with glitch at all, where you just like go on and create a coding project on the web and it's immediately available online, I love how they have the remix button where you can take anybody's project and hit the remix button and you get your own copy of it and you code around it. I love that term and the fact that they use the terminology, remix. I feel like that's a wonderful contribution of the electronic music world to just the discussion of how we work and how we learn, this idea that it is normalized to -- SAM: I believe it's Scratch to kids programming, it just called Scratch because of the DJ metaphor. AVDI: Oh, yeah, interesting. JESSICA: Yeah, the idea that taking a piece of someone's work and putting it in an entirely new context is indeed a new piece of work. AVDI: Yeah, not only a worthwhile thing to do but it's a great way to move the whole world forward. JESSICA: Yeah, it is. SAM: I think it's greater distinction when we talk about cheating, [inaudible] I don't mean break the law or breaking rules. I actually mean -- JESSICA: Copying. SAM: Copying and asking. Cheating in an exam sense, where you look over at someone's shoulder. AVDI: Right. SAM: In a professional situation, you probably get asked to do a job and I just sit on my own and then, a week later, my brother come and says, "Have you done the job?" and so, I didn't really know how to solve this problem. That's not a professional way of being. I really should [inaudible] go and ask for help. Go and find a relevant expert. Go and talk to them. Also if I'm cranking a solution, whatever it is, go and find some [inaudible] and ask them if this the kind of things, like verify your work with this. These are all important things. Before you get [inaudible], I just remember one of the subjects. I remember just reading about someone is saying a person in that class, we got everyone around her in the exam to write in a really big way, so she can reads the answers and cheat in the exams and they said that it turn out that this person didn't cheat got best results than everybody because she was able to verify the answers. So three people wrote this one and one person wrote this one, so [inaudible] more people, therefore [inaudible] high grades because she crowdsource the answer. JESSICA: How does this relate to your superpower that's staring at the same problem for days? SAM: Good question. It was senses. How would you --? JESSICA: Well, you just said, if your boss comes back at you a week later, "I didn't understand this. I've been staring at it for days." SAM: Oh, right. I don't have a boss. JESSICA: But when you were staring at the same problem for days, do you look for other people that solved similar problems? Do you go and ask people? SAM: Yes, it's a good question. Yes. Sometimes, I've been to both [inaudible]. I think you need to do both of those things. That's a good question. If there are other people to collaborate with on the specific thing you're working on, than you were allowed to then yes, definitely do that but then, it's always possible. JESSICA: Right at some point and this is, I guess where your PhD has come from, you get to the edge of completed research. SAM: And other people's interest. People will say, well, it's not interesting to me. JESSICA: Yeah and that's where you get a problem that's worth staring up for days because no one else has found the answer to that problem but it's not like school. You don't have a whole group of people being asked to do the same thing. SAM: Yes and you also do something that's meaningful to you, hopefully and that will give you more motivation to continue. That's why I said I was observing children in schools is when you put something to them, a task which is meaningful to them, then they're far more engaged -- much more deeply engaged. JESSICA: Music has been to everyone. SAM: Music is a great way of achieving that. AVDI: Does music make it easier to learn to code or just code make it easier to learn to make music? SAM: Well, I can be [inaudible] to say what is the difference between music and code. Obviously, there are a fundamental differences in a sense that you can see the difference but actually in that core, music has a notation that it can be perceived as being a notation for the interaction [inaudible] but also, it's actually sociological phenomenon as well. It's a social thing, so it really depends on what you mean by music. JESSICA: So you're making with coding -- SAM: -- a composition in a Western score or dots or lines or squiggles and what do you mean by music and [inaudible] learning from a master who's learned from their master and their master and this is a behavior that just passed on through observation and not through any form of writing. There's lots of different styles of conceiving music. AVDI: It's a good point. SAM: [inaudible]. JANELLE: I think music is a really great metaphor for all the patterns that happen when we're working. I started off my career, wanting to be a singer, songwriter and music was my whole life and it was until I started get a feel for what a current music would be like that I discovered programming, like after that point. But before then, my whole life was music and the way that I thought about the world and saw everything was music. When I got into software, I was all distraught at first with not really knowing what I wanted to do with my life anymore. My boyfriend at the time, he thought he fun to cheer me up and take a class together and he was kind of hard work geeky type, so he's looking to the class catalog and he's like, "Oh, X86 assembly, that sounds fun." I didn't even know any other programming languages existed. My only experience with computers at this point was like playing King's Quest in high school. I got into this class and I was like, "This kind of like programming my [inaudible] in that class. I know I got some BASIC instructions. I can do that," and I started thinking about stitching programs together as stitching music together and then, I had these procedures that were a little musical phrases and I could weave them all together and I started writing the game Breakout completely in assembly, not knowing anything else, just reams and reams of assembly code. Once I found interrupts and I realized I could switch to graphics mode and I could make a PC speaker beep and all these things, I just got so excited about the potential. I showed to my teacher what I was working on and he's like, "What do you just keep going with that? Show me what you're working on," and he gave an A. I'm like, "I like this class. This is the way they do school," but that's when it really hit me -- I can create anything. I can dream. I can create any crazy idea in my head, that I can translate into code, that I can communicate to a machine, that I can translate music into this notation for interacting with this new kind of instruments. I could bring to life. I just had to learn how to speak the language, right? SAM: Absolutely and to know what the side effects that it can do, like making sound on [inaudible] and there's a lot of splashing lights and all sorts of crazy things and knowing that repertoire of side effects within [inaudible]. JANELLE: And I think that in the same way that music needs to be free. It's like it wants to be free. It wants to be remixed together. I feel like software has a bit of that same kind of core of like once we take our ideas and figure out how to translate them into code, how to translate them into the language, remixing them together is the art. It's like the jazz age of our generation, right? SAM: Absolutely. When we talk about [inaudible], and I see this as database which is a part of one of those event logs. You can call it [inaudible] and you then share that through history and you can then take that [inaudible], you can modify it and if you link back to the original one, then you have this sort of path of confidence that you can see [inaudible] a mix and from where I'm [inaudible], it fluctuated back nicely. JESSICA: Which is what's missing in cheating. SAM: Yeah, exactly. It's when people take an [inaudible]. That's [inaudible]. Going back to your point earlier about code being rhythmical, there's two things to know. There are a lot of analogies in music which make teaching computer science really, really simple and fun but also the pure rhythmicality of computers is also interesting. I remember reading about really, really old computers in the 60s, where they're operating so slowly, you could actually physically hear the computers operating almost like machines and when that operation to get into say, a bad loop, we can hear on the machine the repetitive [inaudible] that can now be about programs in a bad loop and then knowing what kind of problems to solve. [inaudible] by simply listening to hardware. It's also an interesting music group. JANELLE: I wonder if we could do something similar. I'm just imagining if I could make patterns that I do when I'm encoding, make sounds. If I could listen to the sounds of the instruments of my developers and my organization, if you could summarize it all into a sound signal, you could probably listen to whatever normal is for your organization. SAM: [inaudible]. I think it was Financial Times about three weeks ago, where there's this small video where they took data about trading and then converted it to music, to then be able to try and see the patterns that you described. It is interesting but I assume, looking at the graph is going to be much more high bound with more information. But I think the general [inaudible] is it's very easy for programmer to take data wonderland to map it.[inaudible], that's trivia for most programs to be able to do. The really hard problem is to be able to take meaning from one [inaudible] and map it to [inaudible]. That's the hard part. It's quite easy to build like [inaudible] sound devices that take any events and then find the appropriate pentatonic scale notes and also sound beautiful like wind chimes but it would be very hard to then take that audio and be able perceive the meaning from the original source and that tends to be hard thing. If you can find a way for your day to turn to meaningful music, where the music meaning is something you completely understand, that would be amazing but I think I imagine that would take a lot of training and learning to be able to build that [inaudible]. In sufficient level, virtually more [inaudible]. JESSICA: It's like acquire meaning associated with the sounds that corresponds in some way to the meaning in the logs. SAM: Exactly. To me, [inaudible] take the information that you're reading or observing and then you generated meaning from that. I can see from a graph that is going up, there's no [inaudible]. I don't see that's a very simple basic example but [inaudible]. If you want to be able to take the audio and how it derive similar kinds of quality of meaning from just listening to audio, that can be hard. AVDI: There are shops that have tried the experiment of taking their production metrics and basically, piping those into synthesizers and having some kind of droning -- not drone but stuff like ambient soundscape generated by their logging, by their metrics and using -- JESSICA: Anomaly detection. AVDI: Right anomaly detection because that's the amazing thing is with sound and with human brains is that when you can turn it into something like that, we're super good at picking out when things are changing. I used to be able to have a strong sense of what my computer was up to base on the hard drive noises. SAM: Was it useful for them. Do they said that we did it --? AVDI: It never became widespread and it would be interesting to find out -- JESSICA: -- Like normal, not normal. AVDI: What's that? JESSICA: The best you're going to get there is normal, not normal. AVDI: Right. JESSICA: It's not going to tell you what's happening. SAM: And they even listen to you all the time in the background. JANELLE: I think that the problem there is the same thing that there's no shared language of meaning that transcends domains in that context. If I have ones, sort of server speaking a certain language and logging these type of events, whatever metrics they're tracking, if we think about a sound that's representing a meaning, then what we need in order to call that off is a clear set of meanings that translate across domains in a way. I think it's a solvable problem but it's like you put noise into a system. In audio, you get out as noise, right? And essentially, that core, hard problem of mapping meaning from one domain to meaning and another is the abstraction to solve as the abstraction of communication itself. It's essentially -- SAM: Before we [inaudible], isn't it? JANELLE: Yeah. My mind is so blown from [inaudible]. AVDI: We need to get to reflection soon but before we get there, there's one other thing I really want to talk about. Sam, you had a really big performance recently. Can you tell us about that? SAM: Oh, sure. That was amazing. Sonic Pi was used by a lot of kids everywhere. It was great and there was a music organization in London, which helps a bunch of schools, in its vicinity, setup a really ambitious project called Convo, where they got a thousand kids who is singing, playing traditional instruments, clapping, drums, all to perform in this place called the [inaudible]. This beautiful massive performance venue in London. It absolutely is amazing. They covered past, present and future music. That was the themes there, of the performance. They started off with bird song and tapping and rhythmic gestures to drumming patterns and then to pop music and the future music. They're so inventive. They brought all these children, often with orchestra that they [inaudible] three years prior so that was all very native, not just to children but with the organizers and the [inaudible] by a wonderful [inaudible]. She did a really amazing job of making it something interesting to listen to but also, not so complicated that you have to be professional performant to be able to perform. Although, there were quite demanding aspects of the piece and part of that is a small cabin, almost glorious [inaudible], especially with the future part was the live coding part. I worked with two children who would be sitting [inaudible] last year with the lyrics, so they run this weekly after-school course and that has led by a lady called [inaudible] and she's [inaudible] artist [inaudible] and she has been teaching in [inaudible] and she [inaudible] these students to form in the final piece and we all got together overseeing practice sessions, took one of [inaudible] pieces and I converted it to code and also, the children wrote their own in code, which was the stuff that they wanted to sound, how's the rhythm they wanted to create and I also modified to make it very simple to actually write up rhythms and patterns and we used that on stage and we performed alongside a thousand of the kids. It was just phenomenal. It was just a beautiful experience to have. Essentially, all I did was to make sure that things didn't really go wrong. I made a few dental tweaks but really, the majority of the performance was [inaudible]. That was just a glorious thing to be part of and see it happen. Even the mayor of London is tweeting about some of my code on a big screen [inaudible]. AVDI: That is absolutely amazing. SAM: What I get excited about really is that most people in the world, I don't think have seen real code. Most people who have seen or heard a code, have seen it on tech TV or in films and we know that how ludicrous programming is and I was going to get a Java applets to decrypt my [inaudible] engine X cluster, that probably sounds completely sensible to non-programmers. He was an example of [inaudible] where people actually seen a real actual code that was really executing in [inaudible] as well. That was really interesting, just show people [inaudible] -- people are credible, actual, real, perception of real code executing. It doesn't have to be this weird thing. It's only business that's used to make rich people richer. It can actually be a tool for expressing yourselves and forgetting people to get together and celebrate and communicate [inaudible]. AVDI: That was absolutely beautiful. I think that's probably a great note to move to reflections on. JESSICA: I have one. One thing that you said early, Sam was that everything is a conversation and we have to ask how can I test that they understand. I suspect you are language based on logging is about how do I know it works before I make it work. But you said, when you're talking to human, you spend a lot of time checking for understanding and that's something [inaudible] that you spend a lot of time checking for understanding. You look at, whether the language you threaten, whether the presentation you've given, whether that really communicated something to people and whether they can keep going with it or they're really gave them a power or just a smile that's great and awesome and also, one of your superpowers. If you want to become a better coder, check for understanding, not just with the computers but with people. SAM: People, definitely, yes. AVDI: For my reflection, I'm still just stuck on the remix culture piece of this conversation. I think that's just a really, really powerful concept and a great thing to normalize. JANELLE: We started this conversation talking about superpowers like staying with the problem, patience and delayed gratification, programming as a form of communication and everything is conversation. The other thing I'm hearing in this is everything is music and music is conversation and I feel like this superpower of programming as a form of communication, we really got to feel for what that means, just by seeing that demonstrated of just using software as a metaphor to describe these everyday things that happen in our jobs, in our servers, these things we observed in the world and the humans around us. We're trying to communicate an idea from one brain to another brain if we can use our software skills, our programming skills as a tool to bring clarity to the ideas we're trying to communicate, software becomes a metaphor for so many things. There's so much power in that. Everything is conversation. AVDI: Sam, what about you? SAM: It's a very difficult one. I feel like I'm in an echo chamber in the sense that a lot of the things I'm saying, everyone is agreeing with and it's all very positively enforced. There's not been enough friction, fight back to then -- JESSICA: Well, we did invite for a reason and it's because you're right. SAM: Oh, that was very kind of you. To me, I guess the most poignant thing of the conversation that I'm thinking about going further is Janelle has pointed about the fact that there was value on what I'm saying beyond on just basic music. Actually, she has seen working and asking similar questions in their own way which is very, very closely to mine but in much more professional programming context with [inaudible] artistic context. It's very easy to people to think what I'm doing is weird and esoteric. Actually, there are some really interesting and compelling used cases for thinking about programming rhythmically and can detect rhythmic pattern detection and to hear somebody is actually working in professional context, talking about it in such ways is really inspiring to me and [inaudible]. JANELLE: Yay, me too. AVDI: Sam, where can people find more about a lot of stuff that you do and just your stuff online? AVDI: Google 'Sam Aaron,' two A's. Sonic Pi, that's P-I, mathematical pi like Raspberry Pi. Sonic Pi was developed first than Raspberry Pi but that now was cross-platform and works on Windows and Mac. Google for Sonic Pi and the best place to ask questions and to get more information about Sonic Pi in particular is the Sonic Pi forms in thread and there's link to that on the Sonic Pi website. And of course, you can follow on Twitter and Instagram if you want to see more of the personal things I'm doing, of course. But in just general things and I’m talking about the projects, then Google for 'Sonic Pi.' AVDI: I highly recommend following Sam on Instagram. He is one of the few programmers I know who is an actual rock star. JESSICA: And find Sam on Patreon because he's left academia and is now doing this incredibly awesome Sonic Pi and teaching kids and spreading coding and music and this joy of expression around the world with our support, so Patreon.com/SamAaron. AVDI: And speaking of Patreon -- JESSICA: Technically, you can also support Greater Than Code but today, support Sam. AVDI: Absolutely. Sam, thank you so much. SAM: Thank you so much for having me. It has been absolutely a delight and an honor to have this conversation. I wish we can start [inaudible]. JESSICA: Well, it doesn't have to. Join us on the Greater Than Code Slack channel. AVDI: Which people can access how? JESSICA: If you make any donation to the Greater Than Code Patreon, you will get an invitation to the Greater Than Code Slack team, where we have a very nice, very low-volume but high interest conversations. We always seem to bring around to that. SAM: It was important. JESSICA: It is important because it lets that podcast continue and it lets us introduce more people to you.