Venue: Microsoft Research Cambridge
Felienne talks with Sam Aaron on Sonic Pi. Topics include how to design a programming language with a broad audience, what features enable a language to be powerful and fun for children to play with, what the role of programming and programming education is in the world in general and the world of music in particular.
Show Notes
Related Links:
- Sam’s StrangeLoop talk, https://www.youtube.com/watch?v=YlRTTzlhquo
- Picademy, https://www.raspberrypi.org/picademy/
The four recourses to learn Sonic Pi
- Sonic Pi, (includes a tutorial with the installation), http://sonic-pi.net/
- Sonic Pi book, https://www.raspberrypi.org/magpi/issues/essentials-sonic-pi-v1/
- Sonic Pi Programming Curriculum, https://www.raspberrypi.org/learning/sonic-pi-lessons/
- Sonic Pi Music Lessons Curriculum, http://www.sonicpiliveandcoding.com/
- Sonic Pi on GitHub, https://github.com/samaaron/sonic-pi
Other live coding systems
- Tidal, http://toplap.org/tidal/
Transcript
Transcript brought to you by innoQ
This is Software Engineering Radio, the podcast for professional developers, on the web at SE-Radio.net. SE-Radio brings you relevant and detailed discussions of software engineering topics at least once a month. SE-Radio is brought to you by IEEE Software Magazine, online at computer.org/software.
* * *
Felienne Hermans: [00:01:09.29] Hello everyone, I’m Felienne for Software Engineering Radio, and I’m here today with Sam Aaron. Sam wrote a Ph.D. on domain-specific languages and now works as a post-doctoral research associate at the computer lab in the university of Cambridge. While doing that, he has designed a programming language called Sonic Pi, and that’s what we’re going to talk about today. Sam, what is Sonic Pi?
Sam Aaron: [00:01:33.27] Hi. Sonic Pi is not actually a new language, it’s more like a domain-specific language based on top of the Ruby programming language. It essentially turns Ruby into a musical instrument that anybody can learn, and anyone can experience the creative power of code.
Felienne Hermans: [00:01:47.07] Why did you create Sonic Pi? What is the problem that it solves?
Sam Aaron: [00:01:53.01] This came back a few years ago when the Raspberry Pi first out, and it was incredibly successful as we’ve all seen now, but it surprised everybody at the time. Although they were selling lots and lots of Raspberry Pi’s, the promise of the Raspberry Pi was that it was going to have an impact in terms of how we engage children in learning to program. Part of that problem is making sure that they have affordable hardware at home, which the Raspberry Pi solved, but the other part was making sure there was interesting software to run on it, that they could use to engage themselves with.
[00:02:21.17] In the early days Scratch was on there, but there was an open question to what other piece of software could we potentially build that may potentially help children engage in programming. The Broadcom Foundation – a company which designs the chips – had a small pocket of money for a three-month guerilla project to see if we could have a look at this problem. The questions were revolved around the computer labs – “Does anyone know anyone who potentially could work on this?” and because I’d already been working on music software for a number of years, building something called Overtone, which is a Clojure frontend SuperCollider, it seemed like a natural thing to give me a shot at building something very simple, that was essentially an overtone, a live coding platform. But rather than being aimed at professional programmers, it was aimed at children, to see if we could lower the barrier to entry.
Felienne Hermans: [00:03:11.20] Maybe not all listeners are familiar with what Overtone is. Can you explain that?
Sam Aaron: [00:03:17.00] Probably to understand that, you also need to understand what live-coding music is, and I’m sure we can talk about that later. The idea is in terms of these musical systems that use code as their interface. Instead of hitting sticks on drums or picking strings with your fingers, we write code, we evaluate that code with some system, and the side effect of that evaluation is some music we just produced, or some modification of the music which is currently playing.
[00:03:45.00] Through the definition and redefinition of code, we were able to create musical compositions and performances. Overtone allows this using the SuperCollider synthesizer, which is a really powerful open source synthesizer, but as the interface we use the Clojure program language, which is a Lisp which runs on a JVM, which is one of my favorite programming languages; it’s a really beautiful language. It was interesting to me to explore how a Lisp-like language running on the JVM, with all this access to libraries, which had a real emphasis on concurrency, could be an interesting platform for exploring music performance and compositions. So that was Overtone, which was a project created originally by a chap called Jeff Rose, a close friend of mine. A month into him starting that project, I discovered his existence and he discovered mine, and we’ve worked together very closely since then.
Felienne Hermans: [00:04:35.12] But despite Clojure being your favorite programming language, Sonic Pi is built on Ruby… Why?
Sam Aaron: [00:04:43.17] Maybe because the context in which the Sonic Pi language or environment was created dictated essentially that Clojure wasn’t a really good fit. There were two main reasons for this. One was that [unintelligible 00:04:55.13] Sonic Pi. At the time, the support for JVM was very weak, and starting a Clojure REPL took minutes, not seconds; starting Overtone inside of Raspberry Pi took about seven minutes, probably mostly because of my inefficient programming at the time. That wasn’t really something that was feasible.
[00:05:16.09] Also, the environment has to pass what I would call the head teacher test. Head teachers would often come to me in workshops I’d be delivering, when they were interested, and ask “Why are you not using Python?” I would need to have a very good reason why I wasn’t using Python, because Python is the language in the U.K. that pretty much all schools are focused on; it’s Scratch to Python. Ruby allowed me to answer that question very simply – Ruby is very similar to Python, the U.K. government uses Ruby for its open source projects, Twitter was originally built in Ruby (although it’s not anymore)… These arguments aren’t really necessarily what’s correct and what’s not correct, it’s what passes the head teacher test; the head teacher doesn’t really tend to know that much about software, but wants to be convinced. Ruby allowed me to do that very effectively. Clojure would have been much more of a struggle [unintelligible 00:06:07.29] feel ashamed, but it is the way it is.
Felienne Hermans: [00:06:14.06] Sure. How did you know how to make the language? Are you a musician yourself? Do you play any instruments?
Sam Aaron: [00:06:20.12] That’s a good question. I did a little bit of music at school; I played carrot and saxophone in a jazz band, but nothing more than that. Certainly nothing at university, nothing later in my life, so no professional music knowledge. But it’s just the same as saying to any software developer if they enter a new business domain, “You don’t know about the pharmaceutical industry, so how can you program in that industry if you don’t have any background?” Of course you don’t need a background in the industry; you need to have a background of programming, and you go learn about the programmable aspects of the industry you’re working in. Then you go and work in a bank, or in a sports company, or in an environmental company, and you can still take skills and transform them, and you learn the aspects of the domain on the job. Music is no different.
[00:07:08.25] I learned about the aspects – and I still am very much learning about the structural aspects of music on the job, and as I learn that, I turn that knowledge into workable abstractions within Sonic Pi. That allows me then to share that knowledge with a broader audience.
Felienne Hermans: [00:07:24.18] But if you work in a bank, you have a customer that can introduce you to the domain.
Sam Aaron: [00:07:28.28] Yes.
Felienne Hermans: [00:07:29.27] Who did you have to help you?
Sam Aaron: [00:07:31.02] At the time when I started working in the domain of music, I was working on Overtone… I had one or two years in Amsterdam working on it, then here in Cambridge, and when I really started to apply my knowledge to learn music with fervor was here in Cambridge. I met a number of people who had large amounts of musical knowledge, and I brought them over to my house for a weekend, bought lots of beers. It was important then to get that knowledge from their head into my head. I asked them, essentially, what is a scale, and they would tell me. I would say, “I don’t know what that means”, and I would ask them to give me more and more detail, until I could then codify what they said and present them back what they said in terms of code. Once we reached an agreement, then I knew I understood what they were talking about.
[00:08:24.12] It’s the same as you program for any industry. We try to learn and understand the formal aspects of the domain, the programmable aspects, and then try and represent that in code.
Felienne Hermans: [00:08:35.28] So you really used code there as a means of learning about a domain by implementing it and understanding it.
Sam Aaron: [00:08:41.22] Yes, precisely.
Felienne Hermans: [00:08:44.00] One of the goals of Sonic Pi is to be fun for a very broad audience, that’s your design goal. Can you talk a bit more about that?
Sam Aaron: [00:08:52.15] The most important design goal, which probably doesn’t sound very ambitious, is to be able to give people – not just children, but everybody – an initial experience of programming that doesn’t scare them off. A lot of initial experiences are really quite terrifying or don’t have any direct meaning to people’s lives, and are very off-putting in the long term. That’s quite damaging for a lot of people. So for me, trying to figure out how to make that initial experience friendly and not scary was pretty much the only main goal. Beyond that, the things that you were describing become really important: being fun, engaging and exciting. For me they’re all means of motivating an engagement.
[00:09:39.15] The question to me isn’t about what aspects of programming should we teach. To me the important question is how do we figure out ways to engage people in programming that creates meaning in their lives, that the solution is some programming? They’re learning to-do lists because the idea of a list has value to them right now for what they want to achieve.
[00:09:59.21] A good example of that is we didn’t teach lists, we taught bass riffs. A bass riff itself is a list of notes, and to perform a bass riff you need to teach a duration, or to map a function over that list. There are different ways of achieving that, but essentially you want some process to work over a list. That’s to make a baseline, it’s not to sort a list of numbers or to print out a list of numbers on the screen, because I don’t think that’s necessarily engaging to a broad audience.
Felienne Hermans: [00:10:32.27] So you take a problem or a task that someone already wants to do, like making a song, and you try and express that with [unintelligible 00:10:38.28] That’s a good strategy.
Sam Aaron: [00:10:41.07] You show them new ways that they can do things that they couldn’t do before with code; it gives them new powers.
Felienne Hermans: [00:10:47.10] However, what’s really different from other programming languages for children like Scratch, for example… Scratch isn’t all that fun if you’re a grown-up. After a while, it’s a toy and it stops losing its appeal. But Sonic Pi is also used by adults, especially live performers that perform live coding. We will talk more about that later in the interview. So why is it important to have a language that has such a broad audience? You could make one language for kids and one language for performers, or special versions of the language, or different versions of the IDE. Why do you want a one-size-fits-all solution?
Sam Aaron: [00:11:24.29] There’s probably two main reasons for that that I can think of right now. First of all, there’s just one me building the thing. If there was a hundred of me, then maybe we could explore multiple versions, multiple iterations. The constraint of development time is an important thing to consider. But also, it’s really important to me that to explore the idea, in my head I see Sonic Pi like a piano, or like a violin, or like a guitar. These instruments have evolved over many hundreds of years, it’s not a really fair comparison, but they can talk about where these things can go in a few hundred years; what would be the equivalent of Sonic Pi in a few hundred years and what would it look like?
[00:12:11.03] I hope it would have the similar properties of a guitar, which is anybody can walk up to a guitar, pick it up and make some sounds. Anybody can learn how to play all of the notes on the guitar in five minutes, because you just need to hold your finger on a fret and pluck a note. You move your finger up and down the fretboard and you get different notes. You can move across the strings and you get different notes. And the same with a piano – you can learn how to play all the notes of a piano in a very short amount of time. To master a piano, that’s a really difficult thing. But why would you master piano? That’s because there are pianists who have spent many years, who can do amazing things.
[00:12:51.13] It’s one thing to make something simple and easy to work with, like the piano is, but to me there is no real value in that, unless there’s deep motivation to aspire to something that other people are able to do. Having a simple approach is just a starting point. Having the motivational and seeing what you could do if you spent many years practicing and working on this, I think that’s why people pick up a guitar. It’s not because it’s simple to pick up, it’s because they’ve seen their favorite guitarists doing many interesting things on the stage.
[00:13:23.23] One of the goals of Sonic Pi is to see if that kind of view of the world could be applied to software. Could it be possible that people would pick up software not because they’ve been told to in school, but because there’s people they respect in the world, musicians maybe, that are using similar software, and they think “Well, I want to do that, too.”
Felienne Hermans: [00:13:46.13] That makes total sense, that this showmanship of live performing also has the role of getting children, but maybe also other people that aren’t necessarily programmers by job, but they think “Oh, that looks nice. I want to be like that person.”
That high-level goal of making it simple but also powerful, how does that translate into concrete goals for the language? What decisions did you make in the syntax of the language or the features that helped you achieve that goal?
Sam Aaron: [00:14:15.24] They are very hard constraints to meet. With Overtone, my previous system that I’ve written with Jeff, we just used to think of cool ideas and then we used to think, “Could we build those ideas?” And if we could, we built it. The system expanded quite rapidly and it has a very powerful set of features. If people are interested in learning Clojure and already are professional programmers, then it’s a really great environment to start with.
[00:14:42.06] Sonic Pi is trying to reach a broad audience, it’s trying to lower the barrier to entry. If your barrier to entry is you need to have a compliant IDE like Emacs or IntelliJ, and you need to understand functional programming… There’s a lot of these barriers, so it’s not just good enough to think about, “Is this a cool idea?” It then has to pass through the test of, “Could I implement the idea?”, which then has to pass the test of, “If I do implement this idea, does it test well with other ideas? Does it fit in in terms of a cohesive design?” Most programmers would already understand; for example if you’re designing an API, if you’re going to add a new endpoint, you think “How does this fit in with all the other endpoints?”
[00:15:26.04] There’s another layer, which is really fundamental: if I can have an idea which passes all these tests – so I’ve got the idea, I can implement it, it fits well with the rest of the design – then I have to ask the question “Could I imagine teaching this design, this idea to a ten-year-old child?” And nine times out of ten the answer is no, so then I stop. I have many ideas which are floating around in space right now in my head which I’d like to build, but I haven’t yet figured out how to make it simple enough for a ten-year-old child.
Felienne Hermans: [00:15:59.07] Can you give an idea of something you would want to include, but got deleted because you thought “There’s just no way I can explain this to a child”?
Sam Aaron: [00:16:07.01] Yes. An idea at the moment which I really want to have, is a musical idea called side training.
Felienne Hermans: [00:16:13.02] What is that?
Sam Aaron: [00:16:15.15] This is a technique used in dance music. If you have the kick drum bang, what tends to happen is when the kick drum kicks in, the rest of the music’s volume is reduced just for the duration of the kick drum, and then brought back up again. What that does is it gives space in the music, in the mix, for the kick drum to happen, and something called a compressor is used for this. It’s a little bit technical. But it’s a really nice sound; it’s a sound that children are used to hearing, so it would be great to be able to have a very simple way of just having that effect. But the current way that Sonic Pi implements effects is using closures, and there’s a very clear nesting of closures. I can have a closure inside of a closure inside of a closure, so I can essentially chain effect very easily by having an effect inside of an effect inside of an effect, like an onion ring.
[00:17:04.19] The idea of side training requires you to have two simultaneously, and I haven’t found a simple way of creating a syntax yet that’s going to allow me to do that. I could easily build it, but I couldn’t imagine teaching a ten-year-old child how to essentially create a lambda function and pass it in as an argument to another [unintelligible 00:17:22.03] It’s already too much.
Felienne Hermans: [00:17:25.19] How do you obtain knowledge about what ten-year-old kids understand? If you just say, “I cannot imagine how to do it”… Have you had features that you tested with children and that you removed later because it just didn’t work with them?
Sam Aaron: [00:17:38.28] Actually, no. What happened was that the first version of Sonic Pi took me two weeks to build, because we had a three-month period to do the whole project. After those two weeks, I was in classrooms observing children using the system. So from day one it was built within classrooms, with teachers, with observation of children, so all of the features grew initially for the first year and a half through direct observation of children in a multitude of different projects all over the U.K.
[00:18:08.17] I really can say with assertion that during that period every feature I built the kids could use, because I was very careful to slowly build the features and watch their observation. Since then, there’s been a focus on the music aspects, as much as the computer science teaching aspects, but I’ve used my knowledge and my observations of the children, and also used my relationships with teachers for discussions to figure out “If I did this, do you think that would be okay?” There’s a lot of discussion, a lot of reflection that goes into this process.
Felienne Hermans: [00:18:42.21] Are there features that you regret?
Sam Aaron: [00:18:45.19] That’s a good question. Yes, and I removed them. I have no problem with backward compatibility.
Felienne Hermans: [00:18:51.07] Which ones, and why?
Sam Aaron: [00:18:54.01] For example, I initially implemented the randomization system using… Ruby has rand function, like every other programming language. I used that to great effect to allow people to be able to say “Choose a random note from the pentatonic scale.” That was a great way of easily making compositions without having to compose. You could just say, “Choose me a bunch of notes. If I don’t like them, choose another bunch of notes until I do like them.” That was great, but what it didn’t really allow was things like being able to reproduce my performances across realms of the software; or if I sent my code to somebody else, I wanted them to hear the same piece of music.
Felienne Hermans: [00:19:35.13] Because it would do the randomization again and you would get a different round of notes.
Sam Aaron: [00:19:39.10] Different every time, yes. And there was also things [unintelligible 00:19:40.21]. If I had a line of code in an iteration that called a random value and that produced me my baseline, and then I’d say I wanted to randomize another aspect of the music, say its timbre, if I then called that rand then, I’m calling it twice, which then interferes with the first set of rand, so now I’d get a different baseline. I wanted to be able to undo calls to rand, which is like taking a card from a deck and then putting it back on again, so when I take the next card it’s the same one. Typical programming languages don’t really support undoing the side effect of calling a random value of a random function.
[00:20:18.21] I had to then go back and remove Sonic Pi’s randomization system using a much simpler, less random approach, random enough to allow me to have this kind of features which it has now. What that meant is that early compositions which use randomization now no longer work, because the randomization system has changed.
Felienne Hermans: [00:20:41.12] How did you solve that?
Sam Aaron: [00:20:42.07] Well, you can’t, mainly because my new randomization system isn’t infinitely random. I actually tried to do in-depth search of trying to find that composition in the new random system and I couldn’t find it, so I had to change the composition.
Felienne Hermans: [00:20:57.28] So you just communicate to users, “Sorry people, we’ve changed something and your stored song might sound very different in this new version.”
Sam Aaron: [00:21:05.27] Yes, exactly. Every version of Sonic Pi has a full release list and there’s a full list of changes that are incompatible. This was a big change, and there aren’t that many of them which had as broad an impact as this, but at the time there weren’t that many people that I could observe using this feature anyway, so I didn’t think there was a radical… There certainly wasn’t any lash back in the community. No one really mentioned it.
[00:21:29.13] Obviously, as the software grows, my ability to make these changes is going to diminish, but I’m still in favor of breaking backward compatibility where it makes sense in terms of making it simpler for new users who are going to join the community.
Felienne Hermans: [00:21:42.06] Talking about the user base because you’ve already hinted at it a little bit, you say “I didn’t see people use this feature anyway.” How big is the user base and how do you know what people are using?
Sam Aaron: [00:21:54.10] I have a few ways of observing. Obviously, you can never know this… I know that Sonic Pi calls home to ask if there’s an update, so I can see how many people are asking for updates. Those are people using Sonic Pi that haven’t opted out from that feature. You can turn that off if you want to and remain anonymous. There are about 300,000 users who have done that. Then there’s also the Twitter feed which has an estimate of the people mentioning Sonic Pi on Twitter; every day there’s a number of people who tweet about it, so I get to see the community that way. There’s also the mailing list as well, where people are discussing ideas. These are the three main points that I can observe about the community.
Felienne Hermans: [00:22:32.18] Do you have any idea what the biggest part of the community is? Is it children playing at home, is it in school settings, are there professional musicians?
Sam Aaron: [00:22:45.20] The largest set of people I’ve observed are workshops and lessons in schools. Actually, less on lessons and more on workshops. People giving impact workshops or introductory workshops or exploratory workshops on programming. I see a lot of activity all around the world of that kind. I see some activity which is growing in schools, but that’s a really tough problem which we can discuss if you want to. There are many barriers to that already that we have to find ways through.
[00:23:13.18] In terms of the professional people, obviously I don’t think there were that many professional live coders using Sonic Pi at the moment, or any professional musicians yet. But there is a larger and growing number of people who are using it to have musical outputs, and the kind of music they’re making is increasingly more exciting to me to hear. When people start playing Sonic Pi, just like when people start playing the piano, it all sounds fairly similar, but as people are creating their own stars, that’s really exciting to watch.
Felienne Hermans: [00:23:42.00] That’s nice. Does that impact the language? If you hear a piece of music that someone created, do you think it would be even better if it also had that musical feature? Does that impact the language?
Sam Aaron: [00:23:53.26] Absolutely. Also, when I observe people doings things which I don’t feel are idiomatic, I then haven’t then somehow communicated what idiomatic means, so then I think about how do I try and coerce these people in the future to follow the idiomatic path.
Felienne Hermans: [00:24:09.18] Do you mean idiomatic in terms of how to write the source code, or idiomatic in terms of how the music sounds?
Sam Aaron: [00:24:16.13] Oh, absolutely the source code. I don’t want to make any impact at all on what music people want to make, because I believe that’s their expression of their own personal ideas, and that’s not for me to have any filter over. However, there are a number of times where I know that if someone had written the source code side differently, it would have given them more freedom to be able to move from that…
[00:24:37.20] Another way to think about the kind of music is a bit like exploring or driving/walking around in unknown territory. There are certain places which are like dead ends, and there are certain places which give you five different directions you can go in. I know that certain forms of the code are more like dead ends, and there are points of varied movement.
Felienne Hermans: [00:25:04.00] Can you give a concrete example? Because it’s a bit abstract…
Sam Aaron: [00:25:07.07] Yes, it’s all very abstract. Until you really get involved in these things it’s very hard to see this. One clear thing is the manipulation and management of time. Sonic Pi does a really strange thing to time, it plays around with it in new and exciting ways. That allows you to then work with lots of things which manipulate time at the same time. [unintelligible 00:25:25.28]
Let’s think of a common example. If we have an effect… I can make a sound, which makes a noise, and then I can apply an effect to it – I can add reverb to it, I can add distortion to it (that’s with an actual closure) or I can slice it – that means that I’ve got someone at the volume knob turning it on or off. The rate of the on/off of the slicer is a temporal [unintelligible 00:25:59.24] time.
[00:26:01.19] If I also have a beat, a pre-recorded sample that has a rhythm into it and I play that rhythm at the same time I’m playing my slicing of my sound, if the slicing isn’t in the same tempo as the beat, that might sound incorrect to some ears and in some contexts. Sometimes it might be exactly what you want, but in other cases it might not. The question is “How do I make sure that they actually sound good together?” There are certain constructs and tactics that you can use which can make that much easier to make these the same time than others, and it can also allow you to change the whole bpm, the whole speed of the entire track without having to change the slicer speed or having to change a sample speed; you’re changing them both simultaneously, without having to go and manually control them both independently.
Felienne Hermans: [00:26:51.26] So the syntax allows users to say something like “Align these two things”, and then you don’t have to think about it yourself; the language encourages you to align it, and if you want to have it not aligned, then it’s harder to do in the syntax.
Sam Aaron: [00:27:05.22] Exactly. The non-idiomatic way is to not have them aligned, and then suddenly it’s much harder to then go and align; you have to modify a lot more code. Or people ask, “Why is the sound not very good?”
[unintelligible 00:27:15.27] but I try and solve it more clearly in the documentation and explaining where you should or shouldn’t do this. Or if people tweet for example a little melody, I’ll write them back saying “That’s great, but you might want to consider using this approach” and then link to the documentation so that they’re aware that there are other ways of doing what they do.
Felienne Hermans: [00:27:37.03] It’s very interesting that you do that on Twitter, but this could be something that would be in your IDE as well, where you would suggest refactoring, saying “Hey, this is not the way you do it.” Is this something you’re thinking about?
Sam Aaron: [00:27:46.29] Absolutely. There’s lots and lots of things I’m thinking of, but it’s just the amount of time and effort. If there’s anyone listening who would love to get involved, there’s tons and tons of things to work on. Making the IDE communicate more things to the user is clearly only a good thing. I want to communicate not just what refactorings are possible or what reconfigurations are possible, I also want to be able to enable live refactorings on an AST basis. I want to consider moving away from text representation to more of an AST representation of the code – like Scratch does, for example – and allow edits to be tree transformations. That kind of thing would be really powerful.
[00:28:29.08] I also want the code itself to come alive as it’s executing. The moment you write some code, you press Run and then you hear the music. There’s a little log which describes the process that’s going through, but once you get to a certain level of complexity that level just flies by. If you’ve got a popular website and you look at the Apache logs, it’s just flying by; you can’t really do anything meaningful with it as a human looking at the logs. Are there ways to animate the text that’s in time with the music? Like allowing it to say, “This is live loop which is going really fast, this is going slowly… The source of the sound is here.”
Felienne Hermans: [00:29:08.08] Yes, because there are some programming languages for children, like LEGO MINDSTORMS for example, that highlights the blocks that are being executed.
Sam Aaron: [00:29:16.05] Exactly. Dave Griffiths, for example, does this with his block language, which is a Lisp which uses 3D graphics. It’s a beautiful thing to watch as a performance, but it really does clearly communicate what happens in terms of their execution process.
Felienne Hermans: [00:30:08.03] Talking about code quality, there’s of course, apart from refactoring, also testing. Normally, you have tests for your source code, and if you run it and you’re making a change, then the test will break. I understand that with Sonic Pi you can just listen to the source code, but can you imagine a testing environment, as well? If you do something really funky and your sound changes a lot, is the only way for the listener to listen?
Sam Aaron: [00:30:34.10] That’s a very good question. Obviously, I’ve thought about this in terms of the development of the software itself, but I never think about testing when I’m performing, ever. Not to say it doesn’t have any value, just it hasn’t ever been something that I’ve seen immediate value in, mainly because the liveness of the situation is kind of a testing environment already. People already talk about REPL-driven development as a way of reproducing much of the perceived benefits of test-driven development, and you can see some similarities there. I’m not joining any sides, but you can sort of see it.
[00:31:12.07] When you’re doing live performing, live programming, live coding, the time for you to observe what happened is so short that it’s very easy then to go back and forth and to treat your code like clay and not think of it as a structure that needs to be tested. It’s just a form that has the right form in the moment, or it doesn’t. If it doesn’t have the right form, then you can just tweak it until it does.
[00:31:36.27] I can’t remember who told me this analogy, but it’s a really important one right now: if you imagine the goal to be hitting a target at a remote distance, one approach would be to get a bow and arrow of the same kind of quality in the Olympics, with all of the eyesights and the tuning and the weights. Then you’ll be more like testing, because what you’re doing is you’re saying “I’m going to take into account the wind flow, the distance, the weight of the arrow, and maybe I’m going to do some mathematical calculations to make sure that I’m going to guarantee to get that far” and you’re going to spend a lot of time setting the bow and arrow up, and then firing it, hoping it’s going to hit the target. Or you’re just going to [unintelligible 00:32:18.09] randomly, and then you need to ask the question “Am I going further away or closer to the target?” Then you just keep going closer and closer, and then you hit it.
[00:32:31.28] Live programming to me is much more light approach, it’s much more ad-hoc, but because you have this liveness, you don’t have to do all this beforehand setting up structured testing and creating mathematical models to make sure you’re going to be accurate, because you have the ability to change it
Felienne Hermans: [00:32:48.09] Let’s talk about code as performance art a little bit more, because that’s where we’re going anyway. There are even parties for this, right? I understood there’s something called an Algorave party, where people go to listen to people performing with source code.
Sam Aaron: [00:33:02.18] Absolutely, there’s something called the Algorave movement, which was started by Alex McLean and Nicholas Collins. Apparently, they [unintelligible 00:33:11.00] listening to happy hardcore, and this great term “algorave” came to their head. What that turned into is this large movement of individual people creating parties where the main instrument is code. A lot of that is live coding, so people modifying the code, improvising live, but also people preparing compositions beforehand as well, and going and hitting Execute. It may contain machine learning, it may contain randomization systems, but predominantly the idea is that you have algorithms making the music, which is the algo, of the Algorave. The rave part is pointing back towards the rave movement of parties where dance music was a really big and important thing.
[00:33:55.09] It’s actually very easy typically, relatively, to make dance music from code than it is to make other music, because the repetition is something that code can do quite clearly with loops and iteration. It’s great to see a range of people from all sorts of backgrounds and disciplines – both from the programming backgrounds, academic backgrounds, musical backgrounds – all making music together for the people to listen to. To see the range of languages and tools in use is a beautiful thing.
Felienne Hermans: [00:34:28.19] Often at these parties people aren’t just looking at the performer, but the source code is also on a screen, which is very cool.
Sam Aaron: [00:34:37.06] Saying that to me, it’s like… Imagine going to a guitar gig or a guitarist who hides their guitar behind the curtain. You’d question that. To me, projecting the source code is just like showing people your guitar, it’s just an obvious thing to do.
Felienne Hermans: [00:34:52.11] Yes, saying it like that it makes total sense, but it’s still strange that you go to a party to read source code.
Sam Aaron: [00:34:59.06] Most electronic musicians don’t tend to communicate to the audience the process in which they’re making the music live. Live coding and projecting the source code offers the performer an opportunity to demonstrate the process they’re making can include the audience.
Felienne Hermans: [00:35:15.25] Does that impact the language, again? Because you want to have a readable syntax so people can understand what you’re doing.
Sam Aaron: [00:35:24.22] If you ask a number of people in the live community, people who do perform these things, you’ll hear a variety of answers to that question. I can only give you the answer from my perspective. For me, it’s very important that the audience – if they want to; not all the audience will want to – can perceive some of what’s going on in terms of the code. There’s a number of ways to achieve that. One is to make sure the language is more easily understood. One of the benefits of working in classrooms is I’ve made sure that my language us understood by ten-year-olds, but that also turns out to be making it fairly understandable to audiences who have never seen the system before.
[00:36:03.22] Also, it’s not just about making the language simple, it’s also about making the presentation simple. One of the things I try to do is to work with large fonts, so that code is large on the screen. That means I have to reduce the amount of algorithmic complexity in terms of syntax which is on the screen. Obviously, I’m allowed to use libraries underneath the scene, so I’m able to maintain some level of complexity in terms of the app parts, but in terms of the interaction of the system, I’m trying to make that as simple and readable as possible.
[00:36:31.23] My observations have been – for example, I’ve performed in a gig in America – when I made the code really simple… If we’re talking about sections of the performance, they were so simple in terms of code that it was one or two lines, and I observed in the audience they just stopped and stared. So when I made it simpler for others to read, they could actually read it, and they did read it. Then, when I communicated to them through comments – I’d write a comment in the source code – the audience would laugh and engage and cheer based off what I was saying, so people were actually reading the source code, so it allowed me then to communicate with them. For me that was a really important thing.
Felienne Hermans: [00:37:11.08] Do you want something in the language or in the IDE to very quickly change? Because if you’re performing and it sounds bad, you have to be very reactive. What specific features do you have for that?
Sam Aaron: [00:37:23.14] I have a system called a live loop, which is kind of an inversion of something called temporal recursion, created by Andrew Sorensen.
Felienne Hermans: [00:37:35.23] Not everyone is familiar with that… Could you please explain?
Sam Aaron: [00:37:39.14] Exactly. The live loop was actually easy to explain, so I created it, but I want to make sure that the provenience of it is clear to the audience. The idea of the live loop is that is it’s just a loop – you say loop rounds in code, but the live loop has one important difference, it has a name. So I call my live loop ‘fu’ or ‘bar’ or ‘bass’. The way to think about this is like it’s a performer – Sam’s performing, Sally’s performing… In my band I can have multiple members, but they all have to have unique names, so I’m able to say “Sam, get the bass going. John, you do the drums. Sally, you do the symbols.” In that sense, I already have introduced one strange concept to a lot of programmers – my live loops have a notion of concurrency already. You can have multiple live loops running at the same time. They’re more like agents, or actors in an Erlang context.
[00:38:32.01] In addition, the behavior of the live loop is something you can modify on the fly, too. You can say, “I like my live loop to do this”, like play a bass drum, and then after a while I say “Actually, you know what, bass drum? Can you play a symbol?” So I change its definition, and next time I’m on the live loop it plays the symbol. I’m able then to modify what’s going on on the fly, to be able to change it.
[00:38:58.22] In terms of the features, these features are really important, but also time – live loop manages time, so that it stays exactly on time, depending on how you describe the delays between drums hits. If I say, “I want you to play a drum, wait for half a second, play a drum”, so in Sonic Pi that will be “Sample, drum, sleep for half a second.” I would have a live loop: “live loop/[unintelligible 00:39:21.16]/sample drum/sleep half a second/end.” That would play my drum.
[00:39:26.00] If I then change the “sample” to “symbol”, the next time I’m on the live loop it will play the symbol. If I change the sleep time to be longer, it would slow down the live loop or speed up the live loop.
Felienne Hermans: [00:39:36.01] Do you do that change within the live loop?
Sam Aaron: [00:39:37.22] Yes. For programmers listening at home… I gave a talk at Strange Loop a couple of years ago, if you can look online…
Felienne Hermans: [00:39:46.09] We can add a link to it.
Sam Aaron: [00:39:47.14] Absolutely… I explain all this in detail. But essentially, each live loop is a thread which has a body which is an infinite loop, which calls a function you can redefine. By redefining the function that implements the live loop, you’re able to change its behavior and next time it dereferences that function and calls it.
In terms of how do I deal with mistakes being made – if I have four live loops going, for example, and when I press Run they all start at the same time, because I have this lovely notion of time, which is inherited by all of the threads – again, I can go into detail about this if you want to, but just to try to keep it at this level… When I press Run, everything starts in time. If I put a mistake in one of the live loops, if I put a typo in there and I get a runtime error at this point, that live loop will die. The other live loops will still be running.
If I’m performing, a good tip is to have multiple live loops, so that when you make a mistake – and you will make mistakes – only that one live loop suffers and the rest are still going.
Felienne Hermans: [00:40:55.20] At least there’s no silence in the performance.
Sam Aaron: [00:40:57.11] Precisely, yes. You can pretend that wasn’t what you wanted to do. Then the goal is to fix the mistake and then get the live loop running again – that’s easy – but also to get it running again in time with everything else. When you press the Run button to start the code again, it will start that live loop from when you press the Run button. So you’d have to somehow manually hit run at just the right to get that live loop to start in synchronization with all the others.
Felienne Hermans: [00:41:23.21] You can get it to sync up easily.
Sam Aaron: [00:41:25.07] Again, this is why I built a system called Sync, which allows me to write with syntax to say “This live loop will sync with this other live loop”, so that it will wait for the live loop to go around before it starts the next one. With syntax, I can then fix the problem with having to worry about timing the live loop together. Again, that was quite a complicated system to built, but it’s very simple to use, and this was one of the goals. Simple in terms of interface doesn’t always mean simple in terms of implementation or design.
Felienne Hermans: [00:41:55.06] There could be contrast, even.
Sam Aaron: [00:41:55.19] They’re inversely correlated, exactly.
Felienne Hermans: [00:41:58.26] So performance does indeed influence the syntax.
Sam Aaron: [00:42:02.25] Yes, because you also need to think about, “I’m hearing a music and it sounds nice, I imagine where the music could go to.” I want to try and make sure that the amount of syntax changes I have to write to make that change isn’t too great. I don’t have to introduce accidental complexity in terms of describing that difference, I just want to describe purely that difference as clearly as possible. When you build a design, there’s some level of essential complexity that you have to have for that design to even work. The material we’re using to build that design adds some extra bit of complexity that’s just annoying, but you just have to do it.
[00:42:40.01] The amount of that extra complexity is also a function of design, as well. Worse designs will require more accidental complexity, so trying to reduce that extent of complexity is really key in terms of reducing the amount of syntax I have to write or modify, or things you have to think about when you’re performing. You want to try and make sure you’re just thinking about the music, and not thinking about lots of other things that are just annoying.
Felienne Hermans: [00:43:06.02] From a language design perspective that’s really interesting, because also often if you design a language or even an API, you say “Well, the user just has to do these three calls, and then they have [unintelligible 00:43:16.22] are inside the library”, but you don’t have the luxury…
Sam Aaron: [00:43:20.04] The solution is this training… You can’t train people. Another example would be if I write this function and this function, the system breaks, because there’s a bug in it. One solution in the business context is to train the users never to do that. That’s a perfectly fine, affordable solution if you have the ability to control use. If your users are school children, you can’t train them to not do that; of course they’re going to do that. You have to make sure the system is resilient enough to manage and deal with that, and you want to make it as simple as possible for those things to be achievable.
Felienne Hermans: [00:43:57.00] It’s interesting, because you keep comparing Sonic Pi’s with musical instruments, because it’s a means of performance, which I totally see. However, there’s a variety of musical instruments and they can play together, whereas Sonic Pi is one language to make all the music. Do you envision you would get specialized versions of Sonic Pi and that there would be an evolution into different forms?
Sam Aaron: [00:44:19.29] Absolutely, I just haven’t gotten to the stage of maturity in the project that allows, for example, the equivalent of Java jars or RubyGems for people to add extensions. That’s something that I’m working on, that will be there at some point. The way I see it at the moment is that Sonic Pi has a very good, base set of semantics, which manages timing, it manages effects chains, it manages modification of code, and does it in a really robust way. To me, there are the semantics to build things on top of, so I can totally imagine people building their own abstractions on top of mine, which gives them different affordances, and then sharing those abstractions with others, which then would create new kinds of instruments and new ways of more effectively creating certain kinds of music.
[00:45:10.15] I can imagine functions that people might write which would give them some parameters which would have great control in certain kinds of contexts in music making. And if people share these functions with others, then that’s a great way of collaborating to create new kinds of adapted instruments, in many ways.
There’s also the idea of synchronizing temporally multiple computers together. That’s something [unintelligible 00:45:31.17] has been doing for a long time. But again, this is something which is technically feasible and a bit fiddly, but it’s not something I can imagine a ten-year-old child doing yet, so we need to make something that’s simpler.
[00:45:44.04] Apple just released their new airpod things, and one of their goals was you open up the box, you press a button and you’re listening to music. Although there’s all these complicated protocols going on behind the scenes, from a user perspective you open the box that you just bought, you press a button on your iPhone and you can listen to music. That’s the level of simplicity we need to have for it to be something that teachers are prepared to pick up in the classroom. Teachers don’t want to be doing network synchronization; that’s something that they don’t have a training or knowledge to be able to do.
[00:46:18.22] These things need to be in place first, before we’ll be able to do effective synchronization, which would then lead to things like Sonic Pi orchestras, or being able to have Sonic Pi talking to any of the other fabulous live coding systems that exist.
Felienne Hermans: [00:46:31.22] How do musicians feel about this? Do they see Sonic Pi as a new musical instrument, or have there been composers that have created pieces with normal, traditional instruments and Sonic Pi? How will it change music?
Sam Aaron: [00:46:47.23] A very good question. I could spend probably at least two hours describing this, at least. I have mixed responses. I’ve had conversations with eminent musical educators who have a very traditional view of music, and those conversations have often been almost friction-full or even aggressive in a mild manner of “This is not music. This is music [unintelligible 00:47:12.24]”, which is only one vision of music. There’s must be more to music than just Western notation and dots on a stave. I would then say, “I believe this is actually a new notation for music and I think it would be an interesting direction to go”, and then they would say “Can you do this?” and they would say some fancy Italian word. [unintelligible 00:47:36.22] and I’d say to them, “I have no idea what you’ve just said. Could you explain it to me in simple terms?” They’d go, “Oh, okay…” and they would write this down in simple terms. Then I’ll be able to write the code and it will be able to do that. Then they would go, “Oh… But can it do…?” and this would happen about five or six iterations, and still they would be unconvinced it was music.
[00:48:00.07] There’s that kind of strange, traditionalist view that’s going to struggle to be changed, which is very entrenched in the music world, but then there are musicians who are using it. I have seen operas being written with Sonic Pi that people have talked about, I have seen school children doing assembly performances to the rest of the school, ten-year-old children who have taught themselves how to do this thing, who have been practicing on the internet using Facetime. That’s a fabulous thing to see. Of course, I’ve seen the algoraves you told me about, and people performing with Sonic Pi… So it is entirely possible.
[00:48:38.12] There are also music magazines, for example the Rolling Stone – they covered a Sonic Pi gig and they saw it as a really important future for music; they said that the performance even transcended the present. They also said that the code made the music-making process more transparent, and they were drawing a direct correlation to synthesizers, which they said were much more confusing and complicated. That was a very interesting statement to make. So if even a music magazine, to get that code could actually represent a simpler way of making music and a more approachable way of making music, it was a fabulous result.
Felienne Hermans: [00:49:25.15] Yes, that’s very impressive. Because if people use a synthesizer, you can’t really see what knobs they’re turning. Your knobs are syntax, so it’s easy to follow along. That’s good.
Sam Aaron: [00:49:33.23] Yes, and synthesizers are expensive. They’re really expensive to set up and [unintelligible 00:49:38.12] thing, which are fabulous, but each modules are hundreds and hundreds of Euros…
Felienne Hermans: [00:49:44.21] And Sonic Pi is free, right? And open source, let’s mention that, because it’s just wonderful [unintelligible 00:49:48.14]
Sam Aaron: [00:49:49.20] And it doesn’t need a fabulous MacBook Pro, it runs on a Raspberry Pi.
Felienne Hermans: [00:49:53.15] Talking about programming for children, because you started at the Raspberry Pi to make it very accessible – why is it important for children to learn programming?
Sam Aaron: [00:50:03.20] It’s a very good question, and when you hear answers, they’re often related directly to business and the shortage of programs in the world. Although I have some appreciation of that as a problem, I don’t think that the lack of workforce should really be the thing that directs what people are educated in, to be honest. Is there a lack of footballers in the world, should we emphasize sports, teaching? Are we now teaching mathematics to create more professional mathematicians? Are we teaching English to create more people who write or read? I don’t think that’s the case.
[00:50:41.22] Although I sympathize with the lack of programmers – it would be great to have more programmers – I don’t think that should be the reason people learn to program. What’s important is to see that the world we live in is ever increasingly affected by programming. Programming is affecting all industries, it’s affecting all our creative pursuits, and that’s not a bad thing, it’s a fabulous thing. If we learn how to program, it gives us more power as humans to express ourselves in new ways. To me that’s the main motivation to learn how to program.
[00:51:14.28] Just like we learn to read or write not to be a professional reader or to be a professional writer, we need to read or write because it allows us to communicate our thoughts and ideas, both personally and professionally. Programming has a similar role to play in society.
Felienne Hermans: [00:51:29.10] What other forms of expression do you imagine children could do with source code, apart from music? We’ve talked about it a lot in this podcast.
Sam Aaron: [00:51:38.17] This is an important thing to talk about, because when we talk about programming, we often talk about it directly for industry. I wonder how many of these podcasts we people listen to have been industry-focused, and how much of the programming world in the future is going to be purely industry-focused? We already live in a very skewed world. It’s not just interesting to talk about what expressive forms code could allow today, it’s also important to think about what it could allow tomorrow, and where could it take us.
[00:52:07.03] Already today there are many pursuits you can take, like music, like processing beautiful pictures, there’s lots of ways to use programming to build things that allow you to build robots, or things that can fly, or things that flash and talk… You can imagine something, like a magician, and you can use programming – if it’s useful – to make that thing a reality. There’s many, many ways we can use programming to help us communicate and build our ideas and to share them and to express ourselves.
[00:52:41.02] As a society, but also as a community of programmers, we should be celebrating all of the non-industry pursuits we could take with programming, and placing a huge priority on that. It’s the non-industry pursuits which can cause a larger change in the world than the industry ones.
Felienne Hermans: [00:53:00.18] That’s an interesting and very good thought. I’m really curious to see what all the children that you’ve been teaching or other people have been teaching will come up with in forms of self-expression with code.
We’re in the U.K. right now, and U.K. is one of the countries that has achieved the most in this, because in the U.K. programming at schools has been mandatory for two school years. What is your take on that? Is this already succeeding, is it a good thing? How is it going?
Sam Aaron: [00:53:27.07] It’s a fabulous thing – the peer group that was created competing at school, headed by [unintelligible 00:53:32.19] was listened to by the governments and was turned into a curriculum. That was a fabulous thing. Now we are able to have a conversation which is along the lines of, “Teaching people Office skills like PowerPoint and spreadsheets isn’t just the most important thing about programming. It’s also important to be able to build the next PowerPoint and the next spreadsheets.” That’s a real conversation that people are having, which is fabulous.
[00:54:00.03] It’s not to say that learning how to use a computer and the Office tools isn’t important – that should remain to be important – but there’s another deeper set of skills that should be understood to some level by the majority of people. For me this is a really important thing. The problem is though that although the government – we’re talking politics now – added to the curriculum, to this day it hasn’t provided any financial support for any change to happen. There’s not money to be paying for teachers to be trained.
[00:54:31.16] A lot of teachers are really struggling, because the teachers were teaching how to do Office or how to design a nice logo as part of the IT class, and now have to teach algorithms. That’s a long jump to make for a lot of teachers. Some of those teachers are very happy to self-learn, which is fabulous, but others are going to really struggle and they really need support and help.
[00:54:53.26] It’s fabulous that charities like the Raspberry Pi Foundation offer free training. They have something called Picademy which teachers can sign up to, which is a two-day course which bumpstarts them into having… Again, not to teach them everything, but to make them not scared of programming; that’s really the main goal, and to give them access to a community and to allow them to see that programming isn’t actually that hard, it’s just a bit frustrating and different. A large part of the thing is that you don’t need to have all the answers, you just need to be able to know who to ask the questions to. Every professional knows this; every professional knows that you can’t know all libraries, but you know how to learn the libraries that you need to do your work.
Felienne Hermans: [00:55:35.25] Yes, because teacher are used to having all the answers. They know everything in elementary school about language, about mathematics, and every question a kid can have, they can answer. But that’s something they have to let go in terms of programming.
Sam Aaron: [00:55:48.16] That’s something that’s changing in education in general. The source of knowledge is the internet now, not the teacher. The teacher should be, in my opinion, more a facilitator of learning, rather than deliverer of knowledge. Part of being a facilitator is recognizing that there will be individuals in the class who know more than you. It’s also accepting that you don’t know the answer to something, but you can go and find it out and next week you can come back with the answer, and that’s not a problem. It’s shouldn’t be perceived as being a problem.
[00:56:15.09] Saying “I don’t know something” isn’t a sign of weakness. To me, it’s a sign of strength. A real sign of weakness is saying “I don’t want to know that thing.” That’s a real problem. Or “I don’t get that, and I never will get that.” That should be the thing which is attacked and challenged. What should be encouraged is “I don’t know that, but I’m going to learn. I’m really excited to know what that might be.”
Felienne Hermans: [00:56:36.21] Learning is hard for everyone, of course. Does Sonic Pi have specific resources for a teacher? If there are people listening who are a teacher or know a teacher…
Sam Aaron: [00:56:45.26] There’s four main resources at the moment for Sonic Pi. There’s the tutorial which is built into the application itself, which is being translated to multiple languages – it’s the best way to get started. It’s written assuming you know nothing about music or anything about code either. If you know a little bit about either, you’ll be able to fly through it. If you don’t, you should be able to work through it at a good pace. My promise to the listeners at home is if you’re reading through the tutorial and something doesn’t make sense, that’s my problem, not yours. If you can let me know where there were some difficulties, then I will fix them for next people.
[00:57:18.29] There’s also a written book which is freely available as well, and has a lot of ideas in terms of… It was written as a suite of chapters for the MagPi magazine for the Raspberry Pi. That’s another great resource as well. For teachers, the Raspberry Pi website has a specific computer science curriculum for introductory computing that we’ve written ourselves and Carrie Anne Philbin who’s a teacher I collaborated with. That’s freely available under Creative Commons license. That’s on the Raspberry Pi website. I think they have two resources similar to that.
Felienne Hermans: [00:57:51.28] We’ll make sure we link to all of the things, we promise.
Sam Aaron: [00:57:54.23] Then there’s a project which I worked on, which was [unintelligible 00:57:57.06] which was not focusing on computer science, but music lessons. We have starts of a music curriculum for schools available for people to read as well. That’s on sonicpiliveandcoding.com.
Felienne Hermans: [00:58:13.06] Awesome. I think we covered most of what Sonic Pi is – it’s a language for performing with source code, that’s inclusive of young children. Is there anything you want to add that I forgot?
Sam Aaron: [00:58:27.17] I could talk for hours, but I don’t have hours. I’d like to say thank you for everyone who supported me for the work I’m doing. It’s important that I mention that. Although we’ve talked at great length about Sonic Pi and live coding, Sonic Pi is one of the many live coding systems, and there’s a whole range of different systems that people can play with. If people are already programmers and they already have their favorite language, then you’ll likely find a live coding system in your language that you can play with.
[00:58:54.00] For example, if you’re a Haskell programmer there’s Tidal, if you’re a Ruby programmer there’s other things than Sonic Pi that people have written – I can’t remember that now, maybe you’ll find some links – which actually do this in the system Ruby itself. There’s [unintelligible 00:59:06.16] environments, there’s Javascript environments, there’s Python environments… So go and find an environment for your language.
[00:59:14.05] If you’re interested in a really simple way to get started, that tries its best to make sure everything, every aspect of the design is similar for a ten-year-old child – and there’s not many other languages that try and do that – then Sonic Pi will fit those goals, hopefully. If it doesn’t, let me know and I’ll fix it.
Felienne Hermans: [00:59:31.03] So there’s no excuse for any programmer out there to become a musician with a range of live programming tools out there.
Sam Aaron: [00:59:38.25] Precisely. What I would like people to do, if they’re professional programmers, is to think about how they can use their skills as a professional programmer not just for business. How can you change the world in ways which aren’t necessarily directly correlated to making money? Because are all the good things in the world that we do directly correlated to money? I don’t think they are. Should programming be the same? I don’t think it should.
[01:00:04.03] We should be thinking about how we can use our amazing, fabulous skills that we all have, that most people don’t yet have, to change the world for the good that we see. Part of that is building new things, part of that is educate what we know about programming to people who don’t know about it, so they themselves can do the same things we can do, too.
Felienne Hermans: [01:00:23.03] That’s a fantastic closing statement. Thanks a lot, Sam!
Sam Aaron: [01:00:26.17] Thank you very much.
* * *
Thanks for listening to SE Radio, an educational program brought to you by IEEE Software Magazine. For more information about the podcast, including other episodes, visit our website at se-radio.net.
To provide feedback, you can write comments on each episode on the website, or write a review on iTunes. Mention or message us on Twitter @seradio, or search for the Software Engineering Radio Group on LinkedIn, Google+ or Facebook. You can also e-mail us at [email protected]. This and all other episodes of SE Radio is licensed under the Creative Commons 2.5 license. Thanks again for your support!
