It looks like you're new here. If you want to get involved, click one of these buttons!
Hi, I’m Nick Montfort and am very glad the organizers have invited a discussion of my recent book, Exploratory Programming for the Arts and Humanities, second edition. The Critical Code Studies Working Group helped me write the first edition of this book, which I’ve now reorganized, updated, and expanded. This edition is open access and freely available in three digital formats.
Programming can be used to explore what computing can do, as millions learned when writing BASIC programs in the home computer era, in the 1970s and 80s. In this book, I focus on how programming can be used as a humanistic method of inquiry and for creative computing.
The book is for people without any programming experience. So, if you’re interested in learning to program, you are really the focus of this week. I invite you to make use of the book using the four methods of learning that I outline in 1.10.
Many of you do know how to program. I’ll ask you to help our new programmers begin to understand not only the mechanics of programming but also how to approach computing and code critically.
I encourage you new programmers to put your copy of Exploratory Programming alongside your computer — you can do that even if you’re using a digital format, if you put the digital text on a phone or tablet. This way you will be compelled to type in the code rather than copying and pasting, and you’ll get a better feel for programming from scratch.
Chapter 1 is the only part of the book meant to be read like a standard textbook, so please read it, and then do the installation and setup in Chapter 2. We can then move on — and I hope that many new programmers will, with effort, be able to get all the way through Chapter 7, which includes some critical discussion of typical introductory programming exercises.
Comments
@nickm: This is fantastic to get to explore your book in this forum! Thanks for offering this to us! It sounds like you want to keep the focus on new programmers, but might we also have a thread for those of us who teach new programmers? I teach introductory programming to BA, MFA and PhD students. In years past, I have relied on different texts, but frequently on those from the Processing community. Lately, because most of my students are film students, I have been developing (with @fabiolahanna and Abram Stern, who I think is not here this year) a series of projects tailored to their interests in the history and future of cinema. See here for a syllabus. We use Khan Academy's talk-throughs for HTML5 as a background resource and have developed our own talk-throughs for each of the projects for the course. Could you start us out (the teachers of new programmers) telling us how you your book differs from other intro texts (like those from the Processing community, etc.) and what and why you changed what you did for the second edition? Thanks!
I’m glad to discuss approaches to using the book as a teacher, @warrensack — thanks for this reply!
Although not a prominent member of the Processing community, I am part of it, having done work in Processing since version 1. In Exploratory Programming new programmers are asked to work in Processing as well as Python. There is a little work in JavaScript and with the arithmetic expressions, originating in C, that are used in bytebeat music.
My approach is to introduce textual work, both generative and analytical, before visual creative coding. However the book moves across different media, so there are interleaved chapters on text as well as image and, near the end, a little invitation to sound/music. The book also covers how one can analyze texts and images in addition to doing textual and visual generation — hence the “Arts and Humanities” of the title.
There are a few reasons for this. I hope to show that programming is a practice that spans particular languages, although some are more suitable than others for particular types of inquiry and creativity. So when a learner finishes going through the book, my hope is that they identify as a programmer, although at that stage a beginning programmer — not just someone who “knows a little Python” or for that matter Processing.
I also hope to show that programming is general to different media. If you’re not as textually inclined as I am, at least it’s easy to do a few fun things with text, and there are also image-based examples, exercises, and projects. Whichever medium is your favorite, there are things to learn from the way computer programs manipulate other ones.
Let me start with that before getting into what was changed in the second edition, in case there are questions about this.
Hi Nick and Warren, and All!
Like Warren, I am also teaching. I taught a class last spring that focused on P5JS (we were entirely online). This semester, I'm excited to be using your second edition as the primary text for an experimental interactive media course with students from a variety of backgrounds—some with experience programming for game design, and others with no prior experience.
I have enjoyed, so far (admittedly, I'm prepped through about the midterm using your materials), the way that you present programming (1) as an approachable creative practice, (2) as you wrote, "general to different media," and (3) as a language-based activity fraught with the legacy of human reasoning, and therefore prime for critical investigation (forgive my interpretation). I know my students will appreciate this, too.
Thank you for this terrific contribution to programming+pedagogy for the arts and humanities. I'm looking forward to following this thread!
Glad you are using the book, @xtineburrough! I hope it goes well.
To answer @warrensack ’s question about changes in the second edition, they range across addition of material, removal of material, revision of sections, technical updates, and reorganization.
I added a significant number of plain old exercises (not the “free projects” I consider most compelling) at the beginning, because of how essential it is that new programmers grasp fundamentals and build strength. I also expanded the glossary and added illustrations. There was a tiny bit about OOP in the first edition, as part of one chapter, and it really wasn’t enough to offer an understanding of this methodology or provide a foundation for interesting projects. So, I removed that. To build on the brief introduction to statistics, probability, and visualization, I added a chapter on classification. I added some more advanced work with text generation that opens up the opportunity for new creative projects. And the Python 2 has been updated to Python 3.
That this edition is open access is a really significant change to me, and I hope to others. That’s thanks to support from the MIT Libraries. While I believe the book presents a holistic approach and is worth going through, I worked to make the book more modular as I revised it, so it would find use in a broader variety of contexts.
This sounds great! I asked my library to order this edition, so I look forward to digging in once it's arrived.
Thanks @nickm for your post! I've been finding it useful to define myself as an "exploratory programmer", such that I am more mindful of my intents while developing projects. Just as code is cultural the identity of programmer may be diverse as well: commercial, (inter)dependent, exploratory, etc..
Sharing my observation on learning programming today, both on modern platforms and platforms from the 70s and 80s: looking at some of the programming manuals / books in the MAL, I had a glance into a very playful home computing culture at that time.
This is an example:
They are playfully illustrated, accompanied with example programs that are modifiable and are fun to be implemented at home. Framing the concept of "home" is important as the programs arose from the space of home: gaming, education, and house chore automation, etc. There is a taste of being an "amateur" in exploratory home computing.
Examples that carry the taste of exploratory play is not only published in book form but also in home computing magazines as well.
It's nice to have a definition of "exploratory programming", and I am saying that against a backdrop of a prevalence of programming education available online. I've used these types of tutorials to get by, and I don't complain about using them instrumentally. I hope that as the book is made accessible, more people can benefit from this modality of learning, build a genuine curiosity towards computer science, and identify themselves as exploratory programmers
This is a great example, @onebigear ! I was influenced both indirectly and directly by such books as I wrote Exploratory Programming: Indirectly because I learned programming originally from these sorts of books, directly because they remain important to my research and creative practice. I’m doing a project now called 101 BASIC Poems which refers to David Ahl’s famous collection of game programs, originally known as 101 BASIC Computer Games. I have to admit that the layout of my book is not as playful. But I was thinking of such examples when I added hand-drawn illustrations.
Related to @onebigear's comment regarding the feeling of 70's/80's programming books, I've recently been revisiting Seymour Papert and Cynthia Solomon's "Twenty Things to Do with a Computer" which is one of my favourite 70's intro to programming texts.
One of the things I love about it is that the first activity is "Make a Turtle" ... and even though it quickly moves on to use their own LOGO Turtle Graphics language, it immediately opens up the possibility that the programmer/user can make their own. It sets up the imagination space of computation as something embodied and open to creation rather than a space to use other people's tools or methods. The Turtle in this case is a transitional object, helping bridge the gap for people between what they understand in the non-computer world with the possibilities of computers.
It also sets up the command based paradigm of LOGO really well by introducing the embodied microworld of the Turtle right away. There's no question of "but what can I do with this language" ... the answer is built in: First you can make the Turtle move and draw, secondly you can invent your own Turtle.
(as an aside, @nickm -- when I got the the "Double, Double" chapter my first association is Tim Horton's ... in Canada a "double double" is a coffee with two milk and two sugar )
That sense of “double double” is even mentioned in the book, @emenel , in 5.1! In the second edition I added a reference to In-N-Out Burger, which features a Double Double on their menu.
Such a nice resource, making me kind of troubled that I'm not teaching this kind of programming but another kind which is not exploratory and not fun and kind of wild. I need to work on my priorities and my position in life to align closer to what I can-as-person-do and want to do and aspire to do and what I think is right, versus what I can-as-an-employee-and-a-cog-in-the-machine-do. We don't always get to have the fun we could, because Reasons. Thanks for inspiration.
Hi Nick! This book is really interesting and of course I think presenting programming as exploratory is so powerful. I particularly like that you spend time in chapter 4 on liberal validation. It can be so easy to pass on the computing “truth” that conservatism is always the safest and best aprroach to code interpretation.
I can’t help thinking though that you were blinded bit by your Javascript hate skepticism into missing maybe one vector it provides that I think is superior to both Python and Processing — code inspection. Web browsers are maybe the most powerful REPLs we have — with built-in debuggers, growing dev tools, and just plain using the console. Javascript is also multi-paradigm which seems to support exploration more strongly than Python’s focus on a single right way to write code. With JS, you can skip OO heavy idioms and never mention the word “class”.
I also find it interesting that so many beginner texts start with for-loops so early, rather than collection methods like
map
. Even as a very experienced programmer, having to think about loops rather than thinking of a function operating on every element is slightly more friction.I wonder what beginners may not be learning when devoting time instead to a more low-level way of processing collections. But maybe I am just an OO skeptic all the way down. Thanks for sharing the text with us!
PS: @warrensack that syllabus makes me a little sad I am not in school any more. Seems like a fun class and jeez, if teaching good critique wasn’t the work the world needs.
Thanks for this reply, @sarahghp ! I do a lot of my own creative programming in ES6 these days and founded an online magazine, Taper, for JavaScript work. And it’s a big plus that browsers are there by default and used by people all the time already; that’s why my very first invitation to programming in the book is via modification of a Web page with JavaScript code.
I encourage you and others who have different perspectives on how to introduce programming to develop resources and to try them out, whether in traditional classes or short workshops!
Do things rather than just shoot off my mouth how dare you. ;P
(Taper looks v. interesting, too.)
@emenel nice! i've been bookmarking a lot of basic computer game books on the internetarchive, i won't be able to run through all of those programs, but the cover art and the content pages are fascinating.
more fun stuff on basic computer games:
Thanks so much for this, @onebigear ! I love the video record of this enthusiasm. Here’s a link to some discussion of that project of mine, 101 BASIC Poems, that I mentioned and that is based on / plays on this book.
I have used this book to teach and can co-sign that it is an excellent teaching resource! I have also found it useful--it not essential--to frame the kind of work that I (and my students) undertake through an "exploratory" framework.
I know this isn't an Exploratory Programming exercise, but I wanted to share this exercise that I use in my class related to @nickm's work.
As background, they read Taroko Gorge and various variations along with Travesty Generator, which we have discussed before on this thread. @lybertram's book shows students the way the data can radically change the nature of a generator.
In our little exercise, first I have students fill out this spreadsheet.
Then, I have them edit the code on this Google Colab.
https://colab.research.google.com/drive/1r-_TNiclYxmvgbofD_aXu2wAwKCP4iGf
I know @nickm isn't a huge fan of using corporate software, but I found these Google tools made things easy for students with little-to-no programming experience. I like that I can have the students work with Nick's python, so we can discuss some of his aesthetic choices for coding.
I’m very glad you do this exercise, @markcmarino , and hope the students enjoy it! When I teach from Exploratory Programming I point students toward the “Memory Slam” pieces on my site, which are reimplementations of classic text generators, rather than text generators I authored—just in case anyone would feel awkward messing with my work. But everything I’ve done is also free for people to study, modify, and share.
Regarding corporate software, I don’t have any distaste at all for corporate software that is free/libre/open-source. Right now I’m running an operating system, the Pop!_OS distribution of GNU/Linux, which is by the corporation System76 and is based on Ubuntu, by another corporation, Canonical. Although Firefox is my default browser, I also use Chromium, a FLOSS Web browser (essentially, the free software version of Chrome) developed by Google. And anyway, what we know now as Firefox was originally developed by a corporation, too!
If you use a company’s Web service that, for the moment, is available and priced at $0, you should ask to what extent you face “lock in.” Does your teaching actually rely on this Web service being available? If it doesn’t, why not use a FLOSS alternative? If it does, how would you be able to cope if the Web services you use end up here?
Yes, @nickm, it is a losing game of software frogger I play, except I'm leaping from log to log. Hopefully, with a bit more Exploratory Programming and a bit more careful selection, I can find my way across to the FLOSS side of the street!
Thanks, @nickm for this overview and all others for the rich discussion, which encourages me to jump in.
What's interesting to observe from a didactical point of view is that the book is a great guide to walk through the code line by line, chapter by chapter, always being able to jump across topics, explore different concepts and examples - what makes it a powerful teaching tool across platforms (love the HTML version...) and learning settings.
I really like that a lot of reflections on teaching and learning practices in this discussion/thread include several examples and snippets. All of them are providing additional context embedded in broader cultural discussions. It is a strong argument of learning to code or program not alone but rather in a community. Exploratory programming is a strong concept, especially when it comes to creative modes of self-expression and I'm very much looking forward working with your book, @nickm!
For me, there is a strong tie between the discussion on how to enable individual learning paths and the structuring of these. Therefore, I was thinking quite a bit about this very interesting point raised by you, dear @sarahghp:
I'm thinking about the benefits In the long term when one does not directly jump into data structures and complex models.
Thinking about conventional modes of learning and exploratory practices at the same time supports my initial impulse to choose multiple fragments over one given path when learning to program. Therefore a bigger set of (low-level and contextualised) examples, topics or concepts offered, might be a door opener to a deeper understanding of other (and more complex) concepts. This all might (or not) come down to a specific learning type. One might be happy with a step-by-step-guide and the other might be good to go with a more exploratory way, I think it is important to build on a wide variety of approaches in order to enhance learning settings to stimulate discussions on the implications of coding or programming concepts (also against the background of historical developments).
@nickm Thanks for the words of wisdom and sage advice.
Are there alternative FLOSS platforms you'd recommend for (near) real-time collaborative editing of python scripts, along the lines of the Jupyter Notebooks of Google Colab?
Very good question, @markcmarino ... Jupyter Notebook is of course FLOSS, and I found a list of free/libre/open-source collaboration resources from early in the pandemic that may be useful.
I’ll confess that I do use corporate Web services myself at times for various reasons, and sometimes ones by megacorporations. I use GitHub, for instance, rather than GitLabs, because part of point of putting code on GitHub is that other people can find it there and fork it. Git itself is free software, so it would be possible to move to a different system or model, although it would be irksome. There are always tradeoffs.
Also — thanks @danvers for your comments about the book!
@sarahghp and @danvers I really appreciate your points about data structures and negotiating complexity while learning to code. I wonder if it is helpful to tie these ideas back to the relationship between the user and the machine. In OOP and procedural programming users focus on the telling the computer 'how' to do the job. This requires users gain intimate knowledge of data structures and all manner of programming ins and outs, and as a result code can be written more like traditional text. In contrast, declarative / logic programming requires the users to specify 'what' to do and leaves the computer to figure out how to execute. Declarative programming treats code more as a function with clear inputs and outputs. I wonder how this fits in with the idea of exploratory programming? How does it balance the tension between learning low level data structures and the high level domain knowledge users aim to express?