Transcript for Go Time #305
Angelica Hill:
Hello, and welcome to today's episode of Go Time, which is going to be exploring the use of Go in art, in visualizations, playing a role that we don't usually hear that much about when we're talking about Go, which is why I'm so excited for us to be diving in and chit-chatting today. And I am joined by the wonderful Anthony Starks, who is --
Anthony Starks:
Hello, everyone.
Angelica Hill:
Hello! He is an independent developer, designer, interested in data visualizations, generative art, building tools... And really, just overall the combination of art, visuals and code. His career began in the 1980s as an IT person for pharma, and it's really blossomed since then. He's created several open source tools, including SVG Go, Deck, or Decksh, which is a markup and domain-specific language kind of information display and presentation package, and Dchart which is a charting package built in Deck. And then in 2019 he made a digital recreation of the Du Bois data stories using Decksh, which we're going to be hearing a little bit more about... But welcome to the show, Anthony. How are you?
Anthony Starks:
Thanks, everyone. I'm well.
Angelica Hill:
So we're gonna dive right in with how did you end up combining Go, visualization, and getting into this whole space? I'd love to hear almost the origin story of you using Go in this way.
Anthony Starks:
So the origin story - let's go back to let's say 2008, even before Go came. I attended a conference called Art and Code at Carnegie Mellon, where they were using -- the whole idea was to combine those two domains together. There was a guy there who had co-created something called processing. I don't know if your audience knows about this, but it was created, again to bring designers and coding together. And that's where sort of my eyes really opened about the combination of bringing art and code together. In my work as an IT person, I had to do lots of charts, and graphs, and things like that... And I found out that I realized that the program could do it better than I did, because I hated pushing pixels around. I could never get to what I exactly wanted. But because I was a developer, I could create it myself.
So when Go came on the scene in 2009, I instantly hopped on it, because it seemed like a programming languages that sort of fit my style. I had done C before, and so forth. And that led to - I had written some code to do SVG generation before in Java... I said, "Let me try this in Go." And the rest is history. In fact, that's how I met you, Angelica, in a meetup in New York City. I was explaining SVG Go, and that's where I met you. So the rest is history.
Angelica Hill:
The rest is history. I'd love to hear kind of what that initial exploration of using Go - what worked well, what did you have to kind of work a little bit more hard to make Go play nice doing... I kind of would love to hear how that initial, and then maybe a little bit about how some of the improvements, the changes to Go over the years that you've observed have made it harder, easier...
Anthony Starks:
So you know, things like working from structs, and being able to take data from structs, and then extracting that out and then going from another representation to that... That worked really well for me, because I had created sort of my own markup language to doing those sort of architectural diagrams. I did it in XML at the time. I'm still an XML proponent, although it's kind of fallen on hard times... But being able to marshal and unmarshal that data in XML, and just representing your data in structs, and then being able to walk those structs and then do your presentation from that was a game-changer. That really helped me out.
I'm sort of a command line guy, so being able to write code that can work on the command line, can work in pipelines was also very, very useful... So yeah, so these things have all sort of stayed with Go, and they've just been a lot better. Yup.
Angelica Hill:
So when we're thinking about working with Go to create visualizations of this nature, are there types of visualizations that lend themselves better to the use of Go, versus other languages? Or is it really across all visualizations, as we're thinking about charts, as we're thinking about diagrams, it's really -- there's not a huge delineation between type of visualization and the use of Go?
Anthony Starks:
\[00:06:01.16\] So there really isn't, but let me tell you sort of my philosophy. So one of the things that I did when I did Decksh, was I was very frustrated with things like PowerPoint, and I wanted to take things down to their sort of fundamental levels. What are we working with? We're working with a canvas. Okay, on that canvas, what are we working with? We're working with text, and placing that text. What are we doing? We've got certain graphical elements, we've got circles, and lines, and ovals, and those kinds of things. So that was sort of informed from my work with SVG, where it has elements for each of the elements of your visual. And the sort of pattern that I came to is "Okay, now that we have this canvas, now let's figure out programmatically how do we arrange things on that canvas in an interesting way." And now, because you've got a programming language, you can represent those relationships programmatically. So you can take this element and this element and work them together, right? And then you can also bring in data, structured data, CSVs, TSVs, whatever, marshal them into whatever data structures are appropriate, and then spit out the visual representation at the end. Now, the nice thing is because we're working with markup languages and that kind of thing, you can take other code to create and digitize those markup languages. Like, you can go from SVG, to PDF, to even PNGs... Again, you're working with sort of a vector orientation, and then from there, the way I think about it is all the ways that sort of a particular designer will work with something like Illustrator, they're working in those higher-level concepts. I'm doing it the same way, but in code. And because I'm doing that, again, I can represent things in code that might be sort of hard to do or tedious to do when you're working and pushing pixels around. Does that make sense?
Angelica Hill:
Yes, it does. So you've kind of already made reference to a few of the packages that you've kind of built out for our wonderful community to use, but I'd love to kind of double-click into them a little bit. So could you introduce us to the various different packages that you've created, their purposes, and how our lovely listeners might be able to use them?
Anthony Starks:
So the first one, we can start with SVG Go. That was created -- that's the oldest one. Started in March 2010. So Go was sort of introduced to the world in November 2009, and a few months later SVG Go was born. So that is the ability to, again, take data from whatever, and take those high-level concepts in SVG and make a picture. So sort of the subtype I like is programming pictures. So that's sort of what we've been doing.
Subsequently, I created other tools... So I use that a lot for generating SVG. So just one more thing that I want to say is, in all my packages I really spend a lot of time on the documentation. And because these are visual tools, it's really important to make sure that we've got really nice illustrations for everything. So I just wanted to put that in there. So that's SVG Go.
\[00:09:44.04\] So let's go back to 2013-2014, something like that... Again, in the corporate world things don't exist unless they're on a PowerPoint. Right? \[laughter\] So a lot of the world's knowledge is sort of locked up in PowerPoint. And I've been doing a lot of PowerPoint and that kind of thing, and again, I'd use SVG Go for doing, again, architectural diagrams, I had my own sort of markup language that was specific for those kinds of things... Again, you could have used Visio and those kinds of things, but whenever I wanted to make a tool, I would make a bespoke tool for a particular kind of visual using SVG Go. But it didn't really quite work to make that as a PowerPoint, so I said "What are the things that build a nice PowerPoint?" I became sort of a student of what makes a good presentation, looking at Steve Jobs's keynotes and those kinds of things, using things like Keynote on the Mac... I said "What are the things that really make that?"
So one of the insights was start with a blank canvas. Throw out all of the defaults that the tools give you, and start with a blank canvas. And again, that's another sort of learning, is the defaults that you get with things like PowerPoint, and Excel, and those kinds of things are terrible. They're really bad. Maybe they'll be better in this age of AI, but right now they're bad. And a lot of bad visuals and things have been foisted on the world because people just click on the default, and it's not their fault.
Anyway, so pulling back, I said "Hm..." Remember the Present tool that the early Go developers created? I said "Well, you know what? Let me make a parser for that, so that I can sort of build those kinds of things." And then from there, I said "Wait a second, what am I doing?" Because it was not really specified anywhere, the grammar or anything about that, I said "Let me pull back, and let's create a bespoke markup language just for presentations." So the whole thing is a deck, and then within the deck you've got slides, and then within slides you've got text and graphics. Okay, that's sort of the basics.
So given that, I created this tool to do that, and - it's interesting, the first client was built for Raspberry Pi. Because it had nice graphics, and I had sort of a 2D graphics library that I was working with at the same time. So I could create nice presentations around that on the Raspberry Pi. But because you had a markup language, you can take that as a basis... So hm... Let's make an SVG out of it. Let's make a PDF out of it. Hm... Let's make a PNG out of it. So from there, you can create a whole deck, and then boom, you've got your PDF, and then nobody knows that you didn't do it with PowerPoint, or whatever... It's just a PDF and slides, and you can walk through it. So that's sort of the beginning of that.
And then after that, I built another tool on top of that called Dchart, that uses the elements -- so it turns out those fundamental elements that you can use are also perfectly great for making charts and graphs. So for example, if you wanted to make, let's say, a bar chart, what are the elements of a bar chart? We've got numbers along the bottom, and you've got lines that make the bars, that can go this way or this way... And you just lay them out.
\[00:13:54.04\] So one of the things that I also want to mention is all of these tools use a simplifying thing called a canvas. But that canvas is percent-based. So it doesn't matter what the aspect ratio is, everything goes from x, from y, from 0 to 100. And it uses the coordinate system that you learned in elementary school. X goes from left to right, increasing, y goes from bottom to top increasing... Which is sort of flipped from typical graphics programming, but from sort of a user's perspective, or from my perspective, that was a fundamental sort of insight. Then, you can just sort of say "If I want something in the middle, it's at 50/50. Boom, there it is. And it doesn't matter what size the canvas is. The size of the can be this way, it can be this way... It doesn't matter, it scales to it.
So you only have to remember numbers from 0 to 100. So that makes it easier to think about and to reason about. And it also simplifies your layout, because again, you can think in those very simple terms, of where things are going to go.
So that was -- so we were talking about Dchart. So Dchart is built on Deck, which is the markup language... So therefore, your charts and your other elements are no different. There's no sort of pasting it in, or whatever. It becomes a fundamental part of it. And then from there, that became a library that you can embed. And then again, you can have programs that work together... Again, all of my tools are command line-based. So you work on the command line, you can build your own tools around that... And again, from there -- so before, I'd been writing sort of the markup language in raw XML, like sort of a caveman. But I realized, "Wait a second, I can create a domain-specific language, that will abstract --" In many ways, it's a one to one. So if I want to draw a line, the line command looks like sort of the line markup. But you have other larger things, like if you wanted to draw star, that's actually a polygon, for example. So you sort of work in those kinds of terms.
And I sort of built up the things as I needed them. So if I needed something that wasn't there, I would just create an element in the markup language, and then create a way to express it, and away I went. So that was Deck, Decksh... And again, in - let's see... In 2019 I learned about the work of W.E.B. Du Bois at the 1900 Paris Exposition, where he wanted to tell the world the progress of African Americans since emancipation. And he used a series of charts and graphs to do this, and it was all documented in a book. The name of the book is W.E.B. Du Bois Data Portraits Visualizing Black America. And in this book, they have each of these -- they were large poster-size things, and I said "You know what, developing these tools concurrently with learning about that, why don't I start and try to recreate them?" So I was on vacation, I said "Let me start, see how far I can get."
So there are around 60 visualizations in the book, and I started in July of 2019, and I finished by October. So it took a few months to do it... But once they were done, I had this nice collection, I had learned a lot about how do you develop a domain-specific language... Again, the philosophy is let's start from the minimum, and then let's just build only as we need it, going up further. So that's sort of the journey of those sort of sets of tools.
Break:
\[00:18:16.24\]
Angelica Hill:
So I'd love to hear kind of that Du Bois visualization, and how it grew into which was what I first heard about this through was the Du Bois Visualization Challenge.
Anthony Starks:
Yeah, so I had created the visualizations, done a couple of presentations and things like that about it at local meetups. And one of the persons who was there, Alan Hillary, got on a call with another colleague, \[unintelligible 00:21:22.16\] and he said "You know what? Why don't we sort of do what you did, but let's challenge the rest of the community? The visualization community, social science... To recreate them." And that was in 2021. So part of that process is, again, first thing you've got to do is curation. So of those sort of 60 visuals, you have to pick them that would, one, be appealing for people to recreate, two, that has various skill levels, because everybody's not the same, and have a good visual variety. So the first step is we create them... We started off with actually seven, but then it expanded to ten, and the idea was to create one visual per week, post it -- and we started off just on Twitter. Post it on Twitter, have people use the \#DuBoisChallenge, and then right now we do it by year. So this year, it's \#DuBoisChallenge2024, and you can follow that on social media.
So we just had people say -- and we had very few rules. The only rules were - and we would post the originals, and I would have a little blurb about each one, sort of explaining what the context was, what was the story behind it... And that's really -- you may have heard the term "storytelling with data." That's sort of one of the things that are coming out. Each one of these things tells a story, and it supports the overall story that Du Bois was trying to say was "We're here, we're part of this nation", and he was combatting sort of some racism that said "Well, black people are inferior", but he was trying to show with data, charts and graphs, also photographs, "We're here. We're prosperous. We've made this much money. We own this much land. This is how we spend our time. This is how we spend our money."
So going back to that, there's curation, and we would say "Okay, week one, here's a chart." And the response was completely overwhelming to us. People would take it and they would sort of do what I did, which was try to be very faithful to the original... But other times, people would say "You know what, I'm just going to use this as an example." Let's pour -- so this data was from the 1900. Let's pour some current data into it.
We have people from all over the world... So there's a guy named \[unintelligible 00:24:18.19\] from Brazil. He always participates. So he takes data from his native land, Brazil. So for example, in many cases there are maps of the United States. He will use maps of Brazil. Last year we had someone participate in Romania, and he would do the same kinds of things.
So the idea was, again, learn visualization, learn some history, take it and make it relevant to today. So that's the Du Bois Challenge. It started very small, but right now -- we started off just with Twitter/X. We've now expanded it to the Data Visualization Society Slack, we've expanded it to LinkedIn... You might not think this, but there's a large community on LinkedIn who are really into it as well... We're doing it on Mastodon, and we're also doing it, again, on all of these social media platforms. So it's very nice to be able to see the community come together, and try to recreate and learn the story as well.
Angelica Hill:
And are you seeing most people using your libraries, other libraries, or other tooling that you're seeing a lot of people use - is it all Go-based? I'd love to hear a little bit about like any \[unintelligible 00:25:43.26\] or changes over the years of how people are approaching these challenges technically.
Anthony Starks:
Right, right. I don't know if anybody else is using my tools but me, but that's okay. A lot of people are using things like Tableau, and R... Because again, when you look at the data, it's kind of social science data, and that tends to be used there. So Tableau and R are big ones. People are using things like D3, and Svelte, and... They're using whatever is at hand. But again, for me Go is the best way to do this.
Angelica Hill:
\[00:26:18.28\] For sure. And then I know you're also -- there's another challenge that I only recently found out about from you, which was all around Genuary... So now that we're recorded, we're out of Genuary now. I would love to hear a little bit about what is it, how is it different from the Du Bois Challenge, and just the context of that whole other challenge.
Anthony Starks:
Right. So Genuary is a way to take every day in January, from the 1st to the 31st, and you began with what's called the prompt, where you just describe something... Usually they'll take, for example, a very simple prompt, or they'll take an historical visual and say "This is what the prompt is." And this is where I got to use a couple of other packages that I didn't mention. One's called Giocanvas, which is based upon the GIO toolkit, which is a way to do graphics and UIs natively on Mac, Windows and PC. And I created a package called, again, Giocanvas, which takes those same ideas of using those high-level objects on a percent-based canvas to create those.
A lot of times things in Genuary tend to be a lot more interactive, but Decksh are sort of static things. But with GIO and Giocanvas I get to exercise that aspect of it as well. So it's kind of an interesting kind of process to go from - I may sketch it in Decksh, but then I may run over to GIO and Giocanvas to do it there. Because you can do things like - again, use things like random number generation, using mouse interaction, different palettes, and that kind of thing.
One more package that I want to mention is called fc, which is called the Fine Canvas. Fine is another sort of cross-platform Go platform for doing graphical applications. Again, I take those same ideas from SVG Go, and Decksh, percent-based canvas, graphical objects... And you can, again, add a bit of interactivity, and that kind of thing.
So Genuary, I had never -- I'd sort of heard about it, but I hadn't really participated in it. So this year, I said "Let me try some stuff." So I created a few things for that. So that was very, very useful. Again, I used GIO Canvas primarily for that one as well.
Angelica Hill:
Circling back to the patterns that you're seeing, either in Genuary, and the Du Bois Challenge, or just generally having been in this space for a while, I'd love to kind of chat a little bit about how you're seeing the general community receive Go in this space. If there's been changes since initially you were thinking about -- I know you're a big advocate for Go in this kind of visualization space... But I would love to hear kind of your observations around the broader tech community's receptiveness to Go in this space, where - I mean, I will put my hands up and say, before I met you and had the pleasure of having you open my eyes to Go's uses in this space, I had kind of self-classified Go as a very much backend language.
Anthony Starks:
\[00:30:03.25\] Right. I will say, in the community it's still that way, and I sort of fight the good fight to try to push against that... So for example, one of the things I did a couple of years ago was to try to get -- it was the first time I did a Go proposal, to try to add a very simple thing - when you're doing your API, or you're doing your documentation for your package, it would be nice to have illustrations to those. So that was a proposal. So that's sort of one thing that I'm working on, to try to get people to think sort of beyond the sort of dry language, and that kind of thing.
So let me go off a bit about documentation as well. I find that I spend a lot of time when I'm let's say developing on Decksh. Let's say I add a feature. It will take me, let's say - I don't know, a day to add it. It may take me twice that to do all of the documentation for that, because I take that very seriously. I want people to be able to pick it up -- and again, I do all my documentation in Decksh, of course. I want people to be able to look at that and get a keen understanding of what it takes to do it. So I have lots of examples. I'll have things like colors, and that kind of thing, so that people can use that as reference. I tend to use it myself, even though I've written the language... "Oh, what did I mean for that one? Oh, this way." And again, that sort of talks to how do you build a DSL. And I've gotta claim that Go was perfect for building things like domain-specific languages... Because you've got the things to be able to do parsing, to be able to break up your input, to do your parsing. And then once you have that, how do you do your generation from there?
So yeah... So to answer your question, I can't say that I've got big uptake on using that... There's been a lot of people who, again, over the years, because it's been around for a while of using SVG Go, which has actually been supplemented by a thing called gensvg... All of the things, all of the bad things, decisions that I made back then in 2010 - I wanted to correct with that.
And again, if you'd look on SpeakerDeck.com/ajstarks, you'll see the documentation for all of those. So I always want to have "This is the code, this is the picture", side by side. I always find that a very powerful way to think about it. Again, that was from processing. Processing sort of pioneered that for me, and that idea of having interactivity. And that's another thing that I like to build into my tools. So I'll have a text editor, I'll have let's say a PDF viewer, and I'll hook them up so that if I make a change in the code, I can immediately see the change. And this is where Go is very useful, to be able to build performant code to be able to make that change very quickly, and then see it updated almost immediately.
Break:
\[00:33:34.27\]
Angelica Hill:
So I would love to -- because we talked a little bit about kind of the past, the reception that you've seen... I would love to hear if we've seen any impact, slash your personal thoughts on how -- and yes, I am going to talk about AI. It's the buzzword... Either has already changed the space, or your personal perceptions on how it might.
Anthony Starks:
I think people are just beginning, for example, to see, for example... I mentioned, for example, the bad defaults that you get with tools. And maybe AI can help. So in a lot of ways, AI can be helpful for implementing things like best practices. So if you can say "Make a visualization in the form or style of, let's say, Alberto Cairo." So that is very, very useful, to be able to codify that, and understand what that means. That being said, I'm a huge AI skeptic, the way that it's been implemented in the past year... Especially when you're talking about data-driven graphics, and things like that. If you rely on it too much, the sort of tendency for hallucination is very bad. You can't -- I mean, you can make a pretty chart, but if it's making up data, or doing that kind of thing, that's very, very bad.
So what I'm going to claim is, I think it has a role, especially in codifying best practices, and things like that. I have just very, very minimal use of things like \[unintelligible 00:36:41.12\] I tried it once, and I said "Let's build something with SVG Go." It didn't do well. \[laughter\] Because it's one of those things that it'll get it like 90% of the time, and then you've got to fix it up... So I'm like "Ah, I'll just do it."
So I believe that those things will get a lot better, and a lot of the sort of boilerplate and things like that will go away. I'm all for that, in order to make people productive... But that's sort of where I am on the AI space. I continue to sort of monitor it, but I can't say that I've got much practical experience with it.
Angelica Hill:
For sure. And do you have, just out of interest, similar feelings around AI's use in the formal art scene?
Anthony Starks:
I do. So for example, the sort of money grab that's happening right now that's hoovering up people's work without attribution, and those kinds of things I think is problematic. On the one hand, if you say "Make a visualization in the style of Du Bois", I think that's probably fine. But if all you're doing is just copying and pasting, let's say my work, or other people's work, that's not so great. So I'm monitoring things like the New York Times is suing Open AI for basically just slurping up its content, and pushing it back out. That's not cool for me.
So I think there needs to be some kind of way -- and right now we're sort of in a gold rush right now, but I don't think we need to pause... But I think we need to consider artists' work, and that kind of thing. So just hoovering it up and just pushing it back out - that's not cool.
Angelica Hill:
Yeah. And I think just something that I have been pottering, thinking about before we jumped onto this episode a little bit was around thinking specifically on the work you've done around Du Bois work, how for me a core reason that I thought that was so wonderful and incredible was that not only are you allowing people to experiment with the tooling, explore a new area of tech, but it is the historical relevance, and being able to propagate this really important messaging piece of history, continuing to revisit this point in time to learn... It's just such a core part of that work that I know you've done. And I think one of my core apprehensions is around losing - and this is in the art world, visualization, especially when it's in reference to specific people who have done visualizations, i.e. Du Bois... Missing that historical part, and missing the context around the kind of almost puzzle pieces that you're using when relying on a tool that doesn't have that context... Because you knoow, it's an algorithm.
Anthony Starks:
\[00:39:47.12\] That's correct. And I think that context is a really important word. These LLMs and so forth tend to lack the context. They're ingesting lots of things, and doing predictions.... Which in many cases is fine. Especially, again, if you're sort of codifying "a best practice". But for doing bespoke work, for doing new work - we still need humans for that. And we still can't just suck it up and push it back out. Now, in the future, I believe that there'll be a new genre of work that is just AI. So you sort of know that it's AI-generated, it will have its own style, it will have its own way of looking... I believe that that's probably where we're headed. Instead of just kind of "Let's just imitate what great people have done", it will be its own thing, and it will be its own way. Sort of like -- I'm also a student of photography, and there was somewhat of a backlash against - you know, for painters when photography came on the scene. And in many ways, the early photographers were imitating the painterly miss and so forth of oil paintings, or watercolors. But eventually, it became recognized as its own thing. So people don't really think about "Oh, you're just trying to make it look like a painting anymore." Photography has its own aspects, it has its own things that artists have been able to use. I believe the same thing will happen with AI. And again, it will have its own genre, and so forth. Already, I can sort of look at something and say "Oh yeah, that was an AI thing."
Angelica Hill:
That's a talent. I feel like I've seen some AI-generated imagery that I could not tell.
Anthony Starks:
Right. And I'm sure that that's out there... But in certain cases, certain genre and things like that, I'm like "Oh yeah, I know what you did for there." But I think, again, just like painting, to photography, to film, and those kinds of things, artists will embrace that medium and make it their own.
Angelica Hill:
I am very excited, don't get me wrong. I feel like it being a new medium, a new tool in an almost the artists' toolbelt to use is really exciting. I mean, I personally -- my favorite types of art and theater are the ones where they bring together all these different multimedia forms i.e. when you have an immersive theater piece that has sound, it has video, it has projection, it has live video, it has art, perhaps... And similarly, the kind of multimedia art space has always fascinated me. So I'm excited to see how artists utilize it in that way, but I would agree, your comment around the initial fear where a new medium comes in, the somewhat, I guess, protectiveness around like "This is going to take away", especially for people who make their livelihoods in that space... So I think as with most things around ML, it's like the excited, cautiously optimistic "We'll see where this goes."
Anthony Starks:
Right. Exactly. Exactly. I feel like I could babble about this for hours... But to bring it back to kind of our core topic for today, all around kind of using Go, visualizations... For our listeners who either have software engineering experience, but have never done anything of this nature, or people coming in, entire newbies - this is maybe they listen to this podcast and they're thinking about starting to write Go, and this happens to be the first episode (you're welcome) that they hear... How would you advise them to get into this space, to start learning? What is a good first step?
Angelica Hill:
\[00:43:55.25\] I would say take a look at things or some visuals that are important to you. For example, some kind of metrics or something that's happening on your job. A lot of jobs are metrics-driven. Take a look at how they're produced, and sort of see "How can I make this better?" Take a look at the effort that goes into actually building those, and think "Maybe I can automate this. Maybe I can - again, using the data..." Again, this is where sort of that pipeline of data to program to visual, where Go is very, very useful for doing that. So take a look at that.
So if there's, for example, a dashboard, or a report that you're working with on your job, take a look at that and see "How might I build that myself? How might I automate that? How may I make that better?" That might be one way to begin. Because that's sort of how my journey began. I was just frustrated and then lazy with the tools, and I use what's called "programmer's hubris", because I could build a tool, I did... So again, if you're a developer, especially if you're a Go developer, you can again use this pattern of, you know, read, transform and push out. And again, Go is very, very useful for that. There are tools, for example there's the JSON marshalling, there's XML marshalling and unmarshalling... There's even a CSV package... Those things are part of the Go standard library. So you don't even have to go beyond what's in the standard library to get started. So again, in short, start with some data or visual that's important to you, and go from there.
Angelica Hill:
And then I know you've mentioned kind of a few of your libraries, packages, some of the standard library... Is there a place or one library that's a good starting point for a very simple visualization? Or is it really go in, have a look at all of the ones that you've referenced in this episode, and see which one fits your use case the best? I'm kind of interested, you kind of outlined really nicely how do you start in terms of thinking about use cases. Once you have your use case, "Okay, I have this graph... Yeah, it seems like it took a lot of time to put this together. I want to try and build this with Go." What is almost the first port of call?
Anthony Starks:
So for me, again, for Go, there's not that many tools other than mine to be able to do that. So for example, I would start with the Dchart program. Again, you could just download that and build that, you could just do a go install, and boom, you have it... And then just start with some CSV files or some tab-separated files, and then just start playing with it. So you say Dchart, and you give it a file, and boom, you've got it. Then you can just pipe that to the thing that makes a PDF, and then look at it. "Oh, that's kind of what I want..."
And again, I like to take an iterative approach, because what Dchart does is it gives you a toolbox of stuff. So it will start with what I call good defaults, but again, one of the things that I learned from doing the Du Bois work is throw out the defaults. Be bold, and start to take "Oh, if I do this with this particular piece, it will be better. If I take this piece and put it here, I can do better." So start with the defaults, and then start to tweak as your own.
\[00:47:51.05\] And because they are command line tools, once you've got it, you can automate it. It becomes a script that you just run all the time. So one of the things that I did in my previous job was we were creating lots of tools from ServiceNow, which is sort of what you use for user tickets, and things like that. So I would gather lots of data from there, and I hit a button every week, I would create a whole set of charts and graphs for that. And once I got it the way that I wanted, I just hit the button, and there they go.
So again, use automation, but start, download Dchart, download pdfdeck. Those are the two tools. And again, from there, you can do a lot of things from there. And again, consult the documentation... Because I spent a lot of time on those. I would love to get other people's feedback on how good the documentation, or what I can do to make it better.
Angelica Hill:
So I need to now go back and look at all the documentation, because I feel like -- you've told us how about how much time you spent on it. I'm excited to see stellar documentation -- that being said, I say that, I paused before the end of that sentence... Seeing any documentation is incredible. \[laughs\]
Anthony Starks:
Right.
Angelica Hill:
Awesome. Well, before we move on to our kind of final section of Go Time, which is Unpopular Opinion, I want to make sure that there's nothing left unsaid to our wonderful listeners. Is there any kind of final thoughts, whether it be getting into this kind of work, jumping into the frontend world, perhaps... For some of our backend engineers the apprehension is real... Before we kind of turn over to our final segment.
Anthony Starks:
Again, I'll take the my sort of marching orders from Du Bois. He had "Be intentional about what your work is." Have you know a message in mind, and be bold. He was bold. Again, if you look at the visuals - you know, nice colors and things like that to attract attention. Be intentional and be bold with your work. You can do a lot with very few tools.
Angelica Hill:
It's been an absolute pleasure chit-chatting, and no doubt I'll probably have to come back to you in a few months when AI has taken over graphing and visualizations in whatever way, and we'll have to revisit...
Anthony Starks:
Oh, it started already.
Angelica Hill:
I know...
Anthony Starks:
You can do these things in Tableau, and things like that. So yeah, it started.
Angelica Hill:
It started already. Well, we'll keep our listeners posted... And I for one will be keeping an eye on Twitter to see how it influences the next Genuary.
Jingle:
\[00:50:41.18\]
Angelica Hill:
So, regrettably, or beneficial for you, you are my only wonderful guest today... So you're gonna have to have an unpopular opinion. Otherwise, I'm gonna have to make one up.
Anthony Starks:
I've got a couple. But let's start with a more modest one. This mania for dark mode in your IDE and your editors has to stop. \[laughter\]
Angelica Hill:
Tell me more.
Anthony Starks:
It's terrible. It sort of looks like skittles on black velvet... So I tend to be sort of classical and minimalist in my view. So when was the last time you wrote something on black paper? You just didn't. It's not done. So I prefer a light mode, with very, very minimal syntax highlighting. So the minimal syntax highlighting is -- it's mostly black on a white background. Crimson for your key words, gray for your comments. That's it. That's all you need. And if you look at that, you'll say "Ah, I feel better. It's nice." It's not, again, like Skittles on black velvet. Dark mode can be very useful for visualizations and things like that. I tend to pull that out. But for programming environments, that's a no for me.
Angelica Hill:
I feel like it makes it so much more fun... When you can look at it, and it's bright, and it's rainbow, and it's beautiful... I don't know, maybe it's just me. I look at my VS Code, and when it's like covered in color, it just brings me such happiness.
Anthony Starks:
\[laughs\] Okay, it's like Christmas.
Angelica Hill:
It's like Christmas lights.
Anthony Starks:
It's like Christmas lights at night.
Angelica Hill:
You're not gonna put one kind of Christmas light on your house. You're gonna cover it all over. Maybe this is giving you an insight into how I decorate...
Anthony Starks:
That's true.
Angelica Hill:
I mean, for me, I think dark mode -- actually, let me ask a clarifying question. Is this specific to code editors? Is it specific to doing the work of a programmer? Or do you have qualms to be had with like dark mode on an iPhone, or dark mode on a Mac? I'm intrigued to see how unpopular this opinion stretches.
Anthony Starks:
To me it's mostly in programming environments... But for example, the desktop that I use has a dark mode; you just hit a button and that's dark. Immediately, I want to flee once I turn it on. It's depressing. It's like "Ah...!" I feel like I'm huddled in my basement, and I've got lights winking at me. I'd rather it be open and classic. So yeah, so it doesn't work well for me in sort of desktop environments either.
Angelica Hill:
My gosh... I feel like it might be a comment on our personality there. We've got clean and classy, and then we've got just a -- all over the shop.
Anthony Starks:
But that's okay. I mean, it's a taste, right? But it's, again, an unpopular opinions. So...
Angelica Hill:
No, I think it's a good one. I'm intrigued to see what the gopher community says. Okay, so you've had that one, which turned out to be not as tame as perhaps you thought it might be... What is another unpopular opinion? We have time for one more... So of the many you've thought of, pick the one that you hesitated the most to say.
Anthony Starks:
So everybody talks about the year of the Linux desktop, and that kind of thing... I'm going to claim it's here and it's fine. All of the work that we've been talking about has all been done on a Linux desktop. It works fine. Especially for the kind of work that I'm doing... If I'm doing programming, and visuals, and that kind of thing.
In fact, in 2019 I had a problem -- I've been using a Mac since 2002, right? So for a long time. And I didn't like one aspect of it. For example, I'm doing these visuals, and I'm refreshing the PDF viewer. The PDF viewer just didn't work well. I said "Let me try this on Linux. Will it work?" It worked nicely. And from there, I said "Okay, let me make a switch from the Mac. Let me put, you know, lots and lots of years behind me, and let's see if we can make the Linux desktop work for me." It has. It has. And especially, in my case, my needs are kind of modest, because in any given day, what do you have? You've got a browser, you've got a text editor, you may have some kind of graphic viewer, and you've got a command line; you've got a shell. With those things, you can do a lot. And again, it hangs together, you can argue about what desktop environment to use, GNOME, KDE or whatever... It really doesn't matter that much. But for things like distributions like Fedora, which I use, it's solid. I'm able to do updates just pretty quickly. Every year, for example, Fedora will do -- two times a year they'll do a major OS upgrade. It's a command line, you hit it, you're done. It tends to work well, at least for me. So for me, the Linux desktop has already arrived. There's no point in arguing about it anymore. It just works.
Angelica Hill:
No, I'm intrigued. That's another one that's intriguing to see what people think about. I for one have been Mac always, and the more I hear about it, the more I'm like "Okay, maybe I should give it a go."
Anthony Starks:
No, the Mac is still very exciting, especially with the M series... I've been very tempted. "Hm, that looks really good. It's really fast." And in fact, there are people who are moving things like Fedora to the Mac natively.
Angelica Hill:
Okay.
Anthony Starks:
\[unintelligible 00:57:17.06\] That's coming along pretty well. So maybe we can have the best of both worlds.
Angelica Hill:
I mean, that would be ideal.
Anthony Starks:
Yup.
Angelica Hill:
Awesome. Well, it's been an absolute pleasure having you on.
Anthony Starks:
Thank you.
Angelica Hill:
It's been too long. I feel like we need to check in more often. And on that hopeful note, we're gonna conclude our outro.
Angelica Hill:
Hello, and welcome to today's episode of Go Time, which is going to be exploring the use of Go in art, in visualizations, playing a role that we don't usually hear that much about when we're talking about Go, which is why I'm so excited for us to be diving in and chit-chatting today. And I am joined by the wonderful Anthony Starks, who is --
Anthony Starks:
Hello, everyone.
Angelica Hill:
Hello! He is an independent developer, designer, interested in data visualizations, generative art, building tools... And really, just overall the combination of art, visuals and code. His career began in the 1980s as an IT person for pharma, and it's really blossomed since then. He's created several open source tools, including SVG Go, Deck, or Decksh, which is a markup and domain-specific language kind of information display and presentation package, and Dchart which is a charting package built in Deck. And then in 2019 he made a digital recreation of the Du Bois data stories using Decksh, which we're going to be hearing a little bit more about... But welcome to the show, Anthony. How are you?
Anthony Starks:
Thanks, everyone. I'm well.
Angelica Hill:
So we're gonna dive right in with how did you end up combining Go, visualization, and getting into this whole space? I'd love to hear almost the origin story of you using Go in this way.
Anthony Starks:
So the origin story - let's go back to let's say 2008, even before Go came. I attended a conference called Art and Code at Carnegie Mellon, where they were using -- the whole idea was to combine those two domains together. There was a guy there who had co-created something called processing. I don't know if your audience knows about this, but it was created, again to bring designers and coding together. And that's where sort of my eyes really opened about the combination of bringing art and code together. In my work as an IT person, I had to do lots of charts, and graphs, and things like that... And I found out that I realized that the program could do it better than I did, because I hated pushing pixels around. I could never get to what I exactly wanted. But because I was a developer, I could create it myself.
So when Go came on the scene in 2009, I instantly hopped on it, because it seemed like a programming languages that sort of fit my style. I had done C before, and so forth. And that led to - I had written some code to do SVG generation before in Java... I said, "Let me try this in Go." And the rest is history. In fact, that's how I met you, Angelica, in a meetup in New York City. I was explaining SVG Go, and that's where I met you. So the rest is history.
Angelica Hill:
The rest is history. I'd love to hear kind of what that initial exploration of using Go - what worked well, what did you have to kind of work a little bit more hard to make Go play nice doing... I kind of would love to hear how that initial, and then maybe a little bit about how some of the improvements, the changes to Go over the years that you've observed have made it harder, easier...
Anthony Starks:
So you know, things like working from structs, and being able to take data from structs, and then extracting that out and then going from another representation to that... That worked really well for me, because I had created sort of my own markup language to doing those sort of architectural diagrams. I did it in XML at the time. I'm still an XML proponent, although it's kind of fallen on hard times... But being able to marshal and unmarshal that data in XML, and just representing your data in structs, and then being able to walk those structs and then do your presentation from that was a game-changer. That really helped me out.
I'm sort of a command line guy, so being able to write code that can work on the command line, can work in pipelines was also very, very useful... So yeah, so these things have all sort of stayed with Go, and they've just been a lot better. Yup.
Angelica Hill:
So when we're thinking about working with Go to create visualizations of this nature, are there types of visualizations that lend themselves better to the use of Go, versus other languages? Or is it really across all visualizations, as we're thinking about charts, as we're thinking about diagrams, it's really -- there's not a huge delineation between type of visualization and the use of Go?
Anthony Starks:
\[00:06:01.16\] So there really isn't, but let me tell you sort of my philosophy. So one of the things that I did when I did Decksh, was I was very frustrated with things like PowerPoint, and I wanted to take things down to their sort of fundamental levels. What are we working with? We're working with a canvas. Okay, on that canvas, what are we working with? We're working with text, and placing that text. What are we doing? We've got certain graphical elements, we've got circles, and lines, and ovals, and those kinds of things. So that was sort of informed from my work with SVG, where it has elements for each of the elements of your visual. And the sort of pattern that I came to is "Okay, now that we have this canvas, now let's figure out programmatically how do we arrange things on that canvas in an interesting way." And now, because you've got a programming language, you can represent those relationships programmatically. So you can take this element and this element and work them together, right? And then you can also bring in data, structured data, CSVs, TSVs, whatever, marshal them into whatever data structures are appropriate, and then spit out the visual representation at the end. Now, the nice thing is because we're working with markup languages and that kind of thing, you can take other code to create and digitize those markup languages. Like, you can go from SVG, to PDF, to even PNGs... Again, you're working with sort of a vector orientation, and then from there, the way I think about it is all the ways that sort of a particular designer will work with something like Illustrator, they're working in those higher-level concepts. I'm doing it the same way, but in code. And because I'm doing that, again, I can represent things in code that might be sort of hard to do or tedious to do when you're working and pushing pixels around. Does that make sense?
Angelica Hill:
Yes, it does. So you've kind of already made reference to a few of the packages that you've kind of built out for our wonderful community to use, but I'd love to kind of double-click into them a little bit. So could you introduce us to the various different packages that you've created, their purposes, and how our lovely listeners might be able to use them?
Anthony Starks:
So the first one, we can start with SVG Go. That was created -- that's the oldest one. Started in March 2010. So Go was sort of introduced to the world in November 2009, and a few months later SVG Go was born. So that is the ability to, again, take data from whatever, and take those high-level concepts in SVG and make a picture. So sort of the subtype I like is programming pictures. So that's sort of what we've been doing.
Subsequently, I created other tools... So I use that a lot for generating SVG. So just one more thing that I want to say is, in all my packages I really spend a lot of time on the documentation. And because these are visual tools, it's really important to make sure that we've got really nice illustrations for everything. So I just wanted to put that in there. So that's SVG Go.
\[00:09:44.04\] So let's go back to 2013-2014, something like that... Again, in the corporate world things don't exist unless they're on a PowerPoint. Right? \[laughter\] So a lot of the world's knowledge is sort of locked up in PowerPoint. And I've been doing a lot of PowerPoint and that kind of thing, and again, I'd use SVG Go for doing, again, architectural diagrams, I had my own sort of markup language that was specific for those kinds of things... Again, you could have used Visio and those kinds of things, but whenever I wanted to make a tool, I would make a bespoke tool for a particular kind of visual using SVG Go. But it didn't really quite work to make that as a PowerPoint, so I said "What are the things that build a nice PowerPoint?" I became sort of a student of what makes a good presentation, looking at Steve Jobs's keynotes and those kinds of things, using things like Keynote on the Mac... I said "What are the things that really make that?"
So one of the insights was start with a blank canvas. Throw out all of the defaults that the tools give you, and start with a blank canvas. And again, that's another sort of learning, is the defaults that you get with things like PowerPoint, and Excel, and those kinds of things are terrible. They're really bad. Maybe they'll be better in this age of AI, but right now they're bad. And a lot of bad visuals and things have been foisted on the world because people just click on the default, and it's not their fault.
Anyway, so pulling back, I said "Hm..." Remember the Present tool that the early Go developers created? I said "Well, you know what? Let me make a parser for that, so that I can sort of build those kinds of things." And then from there, I said "Wait a second, what am I doing?" Because it was not really specified anywhere, the grammar or anything about that, I said "Let me pull back, and let's create a bespoke markup language just for presentations." So the whole thing is a deck, and then within the deck you've got slides, and then within slides you've got text and graphics. Okay, that's sort of the basics.
So given that, I created this tool to do that, and - it's interesting, the first client was built for Raspberry Pi. Because it had nice graphics, and I had sort of a 2D graphics library that I was working with at the same time. So I could create nice presentations around that on the Raspberry Pi. But because you had a markup language, you can take that as a basis... So hm... Let's make an SVG out of it. Let's make a PDF out of it. Hm... Let's make a PNG out of it. So from there, you can create a whole deck, and then boom, you've got your PDF, and then nobody knows that you didn't do it with PowerPoint, or whatever... It's just a PDF and slides, and you can walk through it. So that's sort of the beginning of that.
And then after that, I built another tool on top of that called Dchart, that uses the elements -- so it turns out those fundamental elements that you can use are also perfectly great for making charts and graphs. So for example, if you wanted to make, let's say, a bar chart, what are the elements of a bar chart? We've got numbers along the bottom, and you've got lines that make the bars, that can go this way or this way... And you just lay them out.
\[00:13:54.04\] So one of the things that I also want to mention is all of these tools use a simplifying thing called a canvas. But that canvas is percent-based. So it doesn't matter what the aspect ratio is, everything goes from x, from y, from 0 to 100. And it uses the coordinate system that you learned in elementary school. X goes from left to right, increasing, y goes from bottom to top increasing... Which is sort of flipped from typical graphics programming, but from sort of a user's perspective, or from my perspective, that was a fundamental sort of insight. Then, you can just sort of say "If I want something in the middle, it's at 50/50. Boom, there it is. And it doesn't matter what size the canvas is. The size of the can be this way, it can be this way... It doesn't matter, it scales to it.
So you only have to remember numbers from 0 to 100. So that makes it easier to think about and to reason about. And it also simplifies your layout, because again, you can think in those very simple terms, of where things are going to go.
So that was -- so we were talking about Dchart. So Dchart is built on Deck, which is the markup language... So therefore, your charts and your other elements are no different. There's no sort of pasting it in, or whatever. It becomes a fundamental part of it. And then from there, that became a library that you can embed. And then again, you can have programs that work together... Again, all of my tools are command line-based. So you work on the command line, you can build your own tools around that... And again, from there -- so before, I'd been writing sort of the markup language in raw XML, like sort of a caveman. But I realized, "Wait a second, I can create a domain-specific language, that will abstract --" In many ways, it's a one to one. So if I want to draw a line, the line command looks like sort of the line markup. But you have other larger things, like if you wanted to draw star, that's actually a polygon, for example. So you sort of work in those kinds of terms.
And I sort of built up the things as I needed them. So if I needed something that wasn't there, I would just create an element in the markup language, and then create a way to express it, and away I went. So that was Deck, Decksh... And again, in - let's see... In 2019 I learned about the work of W.E.B. Du Bois at the 1900 Paris Exposition, where he wanted to tell the world the progress of African Americans since emancipation. And he used a series of charts and graphs to do this, and it was all documented in a book. The name of the book is W.E.B. Du Bois Data Portraits Visualizing Black America. And in this book, they have each of these -- they were large poster-size things, and I said "You know what, developing these tools concurrently with learning about that, why don't I start and try to recreate them?" So I was on vacation, I said "Let me start, see how far I can get."
So there are around 60 visualizations in the book, and I started in July of 2019, and I finished by October. So it took a few months to do it... But once they were done, I had this nice collection, I had learned a lot about how do you develop a domain-specific language... Again, the philosophy is let's start from the minimum, and then let's just build only as we need it, going up further. So that's sort of the journey of those sort of sets of tools.
Break:
\[00:18:16.24\]
Angelica Hill:
So I'd love to hear kind of that Du Bois visualization, and how it grew into which was what I first heard about this through was the Du Bois Visualization Challenge.
Anthony Starks:
Yeah, so I had created the visualizations, done a couple of presentations and things like that about it at local meetups. And one of the persons who was there, Alan Hillary, got on a call with another colleague, \[unintelligible 00:21:22.16\] and he said "You know what? Why don't we sort of do what you did, but let's challenge the rest of the community? The visualization community, social science... To recreate them." And that was in 2021. So part of that process is, again, first thing you've got to do is curation. So of those sort of 60 visuals, you have to pick them that would, one, be appealing for people to recreate, two, that has various skill levels, because everybody's not the same, and have a good visual variety. So the first step is we create them... We started off with actually seven, but then it expanded to ten, and the idea was to create one visual per week, post it -- and we started off just on Twitter. Post it on Twitter, have people use the \#DuBoisChallenge, and then right now we do it by year. So this year, it's \#DuBoisChallenge2024, and you can follow that on social media.
So we just had people say -- and we had very few rules. The only rules were - and we would post the originals, and I would have a little blurb about each one, sort of explaining what the context was, what was the story behind it... And that's really -- you may have heard the term "storytelling with data." That's sort of one of the things that are coming out. Each one of these things tells a story, and it supports the overall story that Du Bois was trying to say was "We're here, we're part of this nation", and he was combatting sort of some racism that said "Well, black people are inferior", but he was trying to show with data, charts and graphs, also photographs, "We're here. We're prosperous. We've made this much money. We own this much land. This is how we spend our time. This is how we spend our money."
So going back to that, there's curation, and we would say "Okay, week one, here's a chart." And the response was completely overwhelming to us. People would take it and they would sort of do what I did, which was try to be very faithful to the original... But other times, people would say "You know what, I'm just going to use this as an example." Let's pour -- so this data was from the 1900. Let's pour some current data into it.
We have people from all over the world... So there's a guy named \[unintelligible 00:24:18.19\] from Brazil. He always participates. So he takes data from his native land, Brazil. So for example, in many cases there are maps of the United States. He will use maps of Brazil. Last year we had someone participate in Romania, and he would do the same kinds of things.
So the idea was, again, learn visualization, learn some history, take it and make it relevant to today. So that's the Du Bois Challenge. It started very small, but right now -- we started off just with Twitter/X. We've now expanded it to the Data Visualization Society Slack, we've expanded it to LinkedIn... You might not think this, but there's a large community on LinkedIn who are really into it as well... We're doing it on Mastodon, and we're also doing it, again, on all of these social media platforms. So it's very nice to be able to see the community come together, and try to recreate and learn the story as well.
Angelica Hill:
And are you seeing most people using your libraries, other libraries, or other tooling that you're seeing a lot of people use - is it all Go-based? I'd love to hear a little bit about like any \[unintelligible 00:25:43.26\] or changes over the years of how people are approaching these challenges technically.
Anthony Starks:
Right, right. I don't know if anybody else is using my tools but me, but that's okay. A lot of people are using things like Tableau, and R... Because again, when you look at the data, it's kind of social science data, and that tends to be used there. So Tableau and R are big ones. People are using things like D3, and Svelte, and... They're using whatever is at hand. But again, for me Go is the best way to do this.
Angelica Hill:
\[00:26:18.28\] For sure. And then I know you're also -- there's another challenge that I only recently found out about from you, which was all around Genuary... So now that we're recorded, we're out of Genuary now. I would love to hear a little bit about what is it, how is it different from the Du Bois Challenge, and just the context of that whole other challenge.
Anthony Starks:
Right. So Genuary is a way to take every day in January, from the 1st to the 31st, and you began with what's called the prompt, where you just describe something... Usually they'll take, for example, a very simple prompt, or they'll take an historical visual and say "This is what the prompt is." And this is where I got to use a couple of other packages that I didn't mention. One's called Giocanvas, which is based upon the GIO toolkit, which is a way to do graphics and UIs natively on Mac, Windows and PC. And I created a package called, again, Giocanvas, which takes those same ideas of using those high-level objects on a percent-based canvas to create those.
A lot of times things in Genuary tend to be a lot more interactive, but Decksh are sort of static things. But with GIO and Giocanvas I get to exercise that aspect of it as well. So it's kind of an interesting kind of process to go from - I may sketch it in Decksh, but then I may run over to GIO and Giocanvas to do it there. Because you can do things like - again, use things like random number generation, using mouse interaction, different palettes, and that kind of thing.
One more package that I want to mention is called fc, which is called the Fine Canvas. Fine is another sort of cross-platform Go platform for doing graphical applications. Again, I take those same ideas from SVG Go, and Decksh, percent-based canvas, graphical objects... And you can, again, add a bit of interactivity, and that kind of thing.
So Genuary, I had never -- I'd sort of heard about it, but I hadn't really participated in it. So this year, I said "Let me try some stuff." So I created a few things for that. So that was very, very useful. Again, I used GIO Canvas primarily for that one as well.
Angelica Hill:
Circling back to the patterns that you're seeing, either in Genuary, and the Du Bois Challenge, or just generally having been in this space for a while, I'd love to kind of chat a little bit about how you're seeing the general community receive Go in this space. If there's been changes since initially you were thinking about -- I know you're a big advocate for Go in this kind of visualization space... But I would love to hear kind of your observations around the broader tech community's receptiveness to Go in this space, where - I mean, I will put my hands up and say, before I met you and had the pleasure of having you open my eyes to Go's uses in this space, I had kind of self-classified Go as a very much backend language.
Anthony Starks:
\[00:30:03.25\] Right. I will say, in the community it's still that way, and I sort of fight the good fight to try to push against that... So for example, one of the things I did a couple of years ago was to try to get -- it was the first time I did a Go proposal, to try to add a very simple thing - when you're doing your API, or you're doing your documentation for your package, it would be nice to have illustrations to those. So that was a proposal. So that's sort of one thing that I'm working on, to try to get people to think sort of beyond the sort of dry language, and that kind of thing.
So let me go off a bit about documentation as well. I find that I spend a lot of time when I'm let's say developing on Decksh. Let's say I add a feature. It will take me, let's say - I don't know, a day to add it. It may take me twice that to do all of the documentation for that, because I take that very seriously. I want people to be able to pick it up -- and again, I do all my documentation in Decksh, of course. I want people to be able to look at that and get a keen understanding of what it takes to do it. So I have lots of examples. I'll have things like colors, and that kind of thing, so that people can use that as reference. I tend to use it myself, even though I've written the language... "Oh, what did I mean for that one? Oh, this way." And again, that sort of talks to how do you build a DSL. And I've gotta claim that Go was perfect for building things like domain-specific languages... Because you've got the things to be able to do parsing, to be able to break up your input, to do your parsing. And then once you have that, how do you do your generation from there?
So yeah... So to answer your question, I can't say that I've got big uptake on using that... There's been a lot of people who, again, over the years, because it's been around for a while of using SVG Go, which has actually been supplemented by a thing called gensvg... All of the things, all of the bad things, decisions that I made back then in 2010 - I wanted to correct with that.
And again, if you'd look on SpeakerDeck.com/ajstarks, you'll see the documentation for all of those. So I always want to have "This is the code, this is the picture", side by side. I always find that a very powerful way to think about it. Again, that was from processing. Processing sort of pioneered that for me, and that idea of having interactivity. And that's another thing that I like to build into my tools. So I'll have a text editor, I'll have let's say a PDF viewer, and I'll hook them up so that if I make a change in the code, I can immediately see the change. And this is where Go is very useful, to be able to build performant code to be able to make that change very quickly, and then see it updated almost immediately.
Break:
\[00:33:34.27\]
Angelica Hill:
So I would love to -- because we talked a little bit about kind of the past, the reception that you've seen... I would love to hear if we've seen any impact, slash your personal thoughts on how -- and yes, I am going to talk about AI. It's the buzzword... Either has already changed the space, or your personal perceptions on how it might.
Anthony Starks:
I think people are just beginning, for example, to see, for example... I mentioned, for example, the bad defaults that you get with tools. And maybe AI can help. So in a lot of ways, AI can be helpful for implementing things like best practices. So if you can say "Make a visualization in the form or style of, let's say, Alberto Cairo." So that is very, very useful, to be able to codify that, and understand what that means. That being said, I'm a huge AI skeptic, the way that it's been implemented in the past year... Especially when you're talking about data-driven graphics, and things like that. If you rely on it too much, the sort of tendency for hallucination is very bad. You can't -- I mean, you can make a pretty chart, but if it's making up data, or doing that kind of thing, that's very, very bad.
So what I'm going to claim is, I think it has a role, especially in codifying best practices, and things like that. I have just very, very minimal use of things like \[unintelligible 00:36:41.12\] I tried it once, and I said "Let's build something with SVG Go." It didn't do well. \[laughter\] Because it's one of those things that it'll get it like 90% of the time, and then you've got to fix it up... So I'm like "Ah, I'll just do it."
So I believe that those things will get a lot better, and a lot of the sort of boilerplate and things like that will go away. I'm all for that, in order to make people productive... But that's sort of where I am on the AI space. I continue to sort of monitor it, but I can't say that I've got much practical experience with it.
Angelica Hill:
For sure. And do you have, just out of interest, similar feelings around AI's use in the formal art scene?
Anthony Starks:
I do. So for example, the sort of money grab that's happening right now that's hoovering up people's work without attribution, and those kinds of things I think is problematic. On the one hand, if you say "Make a visualization in the style of Du Bois", I think that's probably fine. But if all you're doing is just copying and pasting, let's say my work, or other people's work, that's not so great. So I'm monitoring things like the New York Times is suing Open AI for basically just slurping up its content, and pushing it back out. That's not cool for me.
So I think there needs to be some kind of way -- and right now we're sort of in a gold rush right now, but I don't think we need to pause... But I think we need to consider artists' work, and that kind of thing. So just hoovering it up and just pushing it back out - that's not cool.
Angelica Hill:
Yeah. And I think just something that I have been pottering, thinking about before we jumped onto this episode a little bit was around thinking specifically on the work you've done around Du Bois work, how for me a core reason that I thought that was so wonderful and incredible was that not only are you allowing people to experiment with the tooling, explore a new area of tech, but it is the historical relevance, and being able to propagate this really important messaging piece of history, continuing to revisit this point in time to learn... It's just such a core part of that work that I know you've done. And I think one of my core apprehensions is around losing - and this is in the art world, visualization, especially when it's in reference to specific people who have done visualizations, i.e. Du Bois... Missing that historical part, and missing the context around the kind of almost puzzle pieces that you're using when relying on a tool that doesn't have that context... Because you knoow, it's an algorithm.
Anthony Starks:
\[00:39:47.12\] That's correct. And I think that context is a really important word. These LLMs and so forth tend to lack the context. They're ingesting lots of things, and doing predictions.... Which in many cases is fine. Especially, again, if you're sort of codifying "a best practice". But for doing bespoke work, for doing new work - we still need humans for that. And we still can't just suck it up and push it back out. Now, in the future, I believe that there'll be a new genre of work that is just AI. So you sort of know that it's AI-generated, it will have its own style, it will have its own way of looking... I believe that that's probably where we're headed. Instead of just kind of "Let's just imitate what great people have done", it will be its own thing, and it will be its own way. Sort of like -- I'm also a student of photography, and there was somewhat of a backlash against - you know, for painters when photography came on the scene. And in many ways, the early photographers were imitating the painterly miss and so forth of oil paintings, or watercolors. But eventually, it became recognized as its own thing. So people don't really think about "Oh, you're just trying to make it look like a painting anymore." Photography has its own aspects, it has its own things that artists have been able to use. I believe the same thing will happen with AI. And again, it will have its own genre, and so forth. Already, I can sort of look at something and say "Oh yeah, that was an AI thing."
Angelica Hill:
That's a talent. I feel like I've seen some AI-generated imagery that I could not tell.
Anthony Starks:
Right. And I'm sure that that's out there... But in certain cases, certain genre and things like that, I'm like "Oh yeah, I know what you did for there." But I think, again, just like painting, to photography, to film, and those kinds of things, artists will embrace that medium and make it their own.
Angelica Hill:
I am very excited, don't get me wrong. I feel like it being a new medium, a new tool in an almost the artists' toolbelt to use is really exciting. I mean, I personally -- my favorite types of art and theater are the ones where they bring together all these different multimedia forms i.e. when you have an immersive theater piece that has sound, it has video, it has projection, it has live video, it has art, perhaps... And similarly, the kind of multimedia art space has always fascinated me. So I'm excited to see how artists utilize it in that way, but I would agree, your comment around the initial fear where a new medium comes in, the somewhat, I guess, protectiveness around like "This is going to take away", especially for people who make their livelihoods in that space... So I think as with most things around ML, it's like the excited, cautiously optimistic "We'll see where this goes."
Anthony Starks:
Right. Exactly. Exactly. I feel like I could babble about this for hours... But to bring it back to kind of our core topic for today, all around kind of using Go, visualizations... For our listeners who either have software engineering experience, but have never done anything of this nature, or people coming in, entire newbies - this is maybe they listen to this podcast and they're thinking about starting to write Go, and this happens to be the first episode (you're welcome) that they hear... How would you advise them to get into this space, to start learning? What is a good first step?
Angelica Hill:
\[00:43:55.25\] I would say take a look at things or some visuals that are important to you. For example, some kind of metrics or something that's happening on your job. A lot of jobs are metrics-driven. Take a look at how they're produced, and sort of see "How can I make this better?" Take a look at the effort that goes into actually building those, and think "Maybe I can automate this. Maybe I can - again, using the data..." Again, this is where sort of that pipeline of data to program to visual, where Go is very, very useful for doing that. So take a look at that.
So if there's, for example, a dashboard, or a report that you're working with on your job, take a look at that and see "How might I build that myself? How might I automate that? How may I make that better?" That might be one way to begin. Because that's sort of how my journey began. I was just frustrated and then lazy with the tools, and I use what's called "programmer's hubris", because I could build a tool, I did... So again, if you're a developer, especially if you're a Go developer, you can again use this pattern of, you know, read, transform and push out. And again, Go is very, very useful for that. There are tools, for example there's the JSON marshalling, there's XML marshalling and unmarshalling... There's even a CSV package... Those things are part of the Go standard library. So you don't even have to go beyond what's in the standard library to get started. So again, in short, start with some data or visual that's important to you, and go from there.
Angelica Hill:
And then I know you've mentioned kind of a few of your libraries, packages, some of the standard library... Is there a place or one library that's a good starting point for a very simple visualization? Or is it really go in, have a look at all of the ones that you've referenced in this episode, and see which one fits your use case the best? I'm kind of interested, you kind of outlined really nicely how do you start in terms of thinking about use cases. Once you have your use case, "Okay, I have this graph... Yeah, it seems like it took a lot of time to put this together. I want to try and build this with Go." What is almost the first port of call?
Anthony Starks:
So for me, again, for Go, there's not that many tools other than mine to be able to do that. So for example, I would start with the Dchart program. Again, you could just download that and build that, you could just do a go install, and boom, you have it... And then just start with some CSV files or some tab-separated files, and then just start playing with it. So you say Dchart, and you give it a file, and boom, you've got it. Then you can just pipe that to the thing that makes a PDF, and then look at it. "Oh, that's kind of what I want..."
And again, I like to take an iterative approach, because what Dchart does is it gives you a toolbox of stuff. So it will start with what I call good defaults, but again, one of the things that I learned from doing the Du Bois work is throw out the defaults. Be bold, and start to take "Oh, if I do this with this particular piece, it will be better. If I take this piece and put it here, I can do better." So start with the defaults, and then start to tweak as your own.
\[00:47:51.05\] And because they are command line tools, once you've got it, you can automate it. It becomes a script that you just run all the time. So one of the things that I did in my previous job was we were creating lots of tools from ServiceNow, which is sort of what you use for user tickets, and things like that. So I would gather lots of data from there, and I hit a button every week, I would create a whole set of charts and graphs for that. And once I got it the way that I wanted, I just hit the button, and there they go.
So again, use automation, but start, download Dchart, download pdfdeck. Those are the two tools. And again, from there, you can do a lot of things from there. And again, consult the documentation... Because I spent a lot of time on those. I would love to get other people's feedback on how good the documentation, or what I can do to make it better.
Angelica Hill:
So I need to now go back and look at all the documentation, because I feel like -- you've told us how about how much time you spent on it. I'm excited to see stellar documentation -- that being said, I say that, I paused before the end of that sentence... Seeing any documentation is incredible. \[laughs\]
Anthony Starks:
Right.
Angelica Hill:
Awesome. Well, before we move on to our kind of final section of Go Time, which is Unpopular Opinion, I want to make sure that there's nothing left unsaid to our wonderful listeners. Is there any kind of final thoughts, whether it be getting into this kind of work, jumping into the frontend world, perhaps... For some of our backend engineers the apprehension is real... Before we kind of turn over to our final segment.
Anthony Starks:
Again, I'll take the my sort of marching orders from Du Bois. He had "Be intentional about what your work is." Have you know a message in mind, and be bold. He was bold. Again, if you look at the visuals - you know, nice colors and things like that to attract attention. Be intentional and be bold with your work. You can do a lot with very few tools.
Angelica Hill:
It's been an absolute pleasure chit-chatting, and no doubt I'll probably have to come back to you in a few months when AI has taken over graphing and visualizations in whatever way, and we'll have to revisit...
Anthony Starks:
Oh, it started already.
Angelica Hill:
I know...
Anthony Starks:
You can do these things in Tableau, and things like that. So yeah, it started.
Angelica Hill:
It started already. Well, we'll keep our listeners posted... And I for one will be keeping an eye on Twitter to see how it influences the next Genuary.
Jingle:
\[00:50:41.18\]
Angelica Hill:
So, regrettably, or beneficial for you, you are my only wonderful guest today... So you're gonna have to have an unpopular opinion. Otherwise, I'm gonna have to make one up.
Anthony Starks:
I've got a couple. But let's start with a more modest one. This mania for dark mode in your IDE and your editors has to stop. \[laughter\]
Angelica Hill:
Tell me more.
Anthony Starks:
It's terrible. It sort of looks like skittles on black velvet... So I tend to be sort of classical and minimalist in my view. So when was the last time you wrote something on black paper? You just didn't. It's not done. So I prefer a light mode, with very, very minimal syntax highlighting. So the minimal syntax highlighting is -- it's mostly black on a white background. Crimson for your key words, gray for your comments. That's it. That's all you need. And if you look at that, you'll say "Ah, I feel better. It's nice." It's not, again, like Skittles on black velvet. Dark mode can be very useful for visualizations and things like that. I tend to pull that out. But for programming environments, that's a no for me.
Angelica Hill:
I feel like it makes it so much more fun... When you can look at it, and it's bright, and it's rainbow, and it's beautiful... I don't know, maybe it's just me. I look at my VS Code, and when it's like covered in color, it just brings me such happiness.
Anthony Starks:
\[laughs\] Okay, it's like Christmas.
Angelica Hill:
It's like Christmas lights.
Anthony Starks:
It's like Christmas lights at night.
Angelica Hill:
You're not gonna put one kind of Christmas light on your house. You're gonna cover it all over. Maybe this is giving you an insight into how I decorate...
Anthony Starks:
That's true.
Angelica Hill:
I mean, for me, I think dark mode -- actually, let me ask a clarifying question. Is this specific to code editors? Is it specific to doing the work of a programmer? Or do you have qualms to be had with like dark mode on an iPhone, or dark mode on a Mac? I'm intrigued to see how unpopular this opinion stretches.
Anthony Starks:
To me it's mostly in programming environments... But for example, the desktop that I use has a dark mode; you just hit a button and that's dark. Immediately, I want to flee once I turn it on. It's depressing. It's like "Ah...!" I feel like I'm huddled in my basement, and I've got lights winking at me. I'd rather it be open and classic. So yeah, so it doesn't work well for me in sort of desktop environments either.
Angelica Hill:
My gosh... I feel like it might be a comment on our personality there. We've got clean and classy, and then we've got just a -- all over the shop.
Anthony Starks:
But that's okay. I mean, it's a taste, right? But it's, again, an unpopular opinions. So...
Angelica Hill:
No, I think it's a good one. I'm intrigued to see what the gopher community says. Okay, so you've had that one, which turned out to be not as tame as perhaps you thought it might be... What is another unpopular opinion? We have time for one more... So of the many you've thought of, pick the one that you hesitated the most to say.
Anthony Starks:
So everybody talks about the year of the Linux desktop, and that kind of thing... I'm going to claim it's here and it's fine. All of the work that we've been talking about has all been done on a Linux desktop. It works fine. Especially for the kind of work that I'm doing... If I'm doing programming, and visuals, and that kind of thing.
In fact, in 2019 I had a problem -- I've been using a Mac since 2002, right? So for a long time. And I didn't like one aspect of it. For example, I'm doing these visuals, and I'm refreshing the PDF viewer. The PDF viewer just didn't work well. I said "Let me try this on Linux. Will it work?" It worked nicely. And from there, I said "Okay, let me make a switch from the Mac. Let me put, you know, lots and lots of years behind me, and let's see if we can make the Linux desktop work for me." It has. It has. And especially, in my case, my needs are kind of modest, because in any given day, what do you have? You've got a browser, you've got a text editor, you may have some kind of graphic viewer, and you've got a command line; you've got a shell. With those things, you can do a lot. And again, it hangs together, you can argue about what desktop environment to use, GNOME, KDE or whatever... It really doesn't matter that much. But for things like distributions like Fedora, which I use, it's solid. I'm able to do updates just pretty quickly. Every year, for example, Fedora will do -- two times a year they'll do a major OS upgrade. It's a command line, you hit it, you're done. It tends to work well, at least for me. So for me, the Linux desktop has already arrived. There's no point in arguing about it anymore. It just works.
Angelica Hill:
No, I'm intrigued. That's another one that's intriguing to see what people think about. I for one have been Mac always, and the more I hear about it, the more I'm like "Okay, maybe I should give it a go."
Anthony Starks:
No, the Mac is still very exciting, especially with the M series... I've been very tempted. "Hm, that looks really good. It's really fast." And in fact, there are people who are moving things like Fedora to the Mac natively.
Angelica Hill:
Okay.
Anthony Starks:
\[unintelligible 00:57:17.06\] That's coming along pretty well. So maybe we can have the best of both worlds.
Angelica Hill:
I mean, that would be ideal.
Anthony Starks:
Yup.
Angelica Hill:
Awesome. Well, it's been an absolute pleasure having you on.
Anthony Starks:
Thank you.
Angelica Hill:
It's been too long. I feel like we need to check in more often. And on that hopeful note, we're gonna conclude our outro.
