Mastodon: Space and Community

Over the past year or so, there’s been a soft but steady drumbeat of information about the social networking platform Mastodon. It got written up in tech circles a couple of times, was mentioned on a higher education site or two, has been loudly praised and more quietly mused about over on Metafilter. But there’s been less hyperbolic coverage than sometimes accompanies these things, and it’s easy to think that the groundless hype that has accompanied other sites and services (cough Diaspora cough) may have made people leery of the next big social media thing. Also, my sense is that it’s only been in the past few months that Mastodon has become really vibrant: I joined mastodon.social back in December 2016, but the vibe then and for several months after I joined was like a lot of niche social networking sites: a lot of promise, but not a lot of people.

There are important things to say about the technical side of the platform– it’s part of the reason that Mastodon has so much potential, and why I continued to fund development of it even when I wasn’t using it all that much. It’s based on ideas of decentralization and federation that have been kicking around the indie/FOSS social media world for a number of years, but which will seem completely baffling if they’re new to you.

But all of this stuff is not the important thing, because something funny has happened in the past few months: Mastodon has become a community, and one that reminds us of what communities are and can be. And a niggling little thing made me realize this: Mastodon gets quiet.

For years, I worked in the public spaces that are most hung out in– coffee shops, public libraries– and one of the things you learn is that these spaces have a life of their own. There’s a rhythm to the day and times when you know it’s going to be busy. But there are also times activity slows to a crawl, and there’s little to do but read or neaten the place up or work on longer-term projects. But an entire human ecosystem moves in tandem with these rhythms: there’s the lonely guy who always stops in during the afternoon lull and stays to talk, there’s the adorable older couple that comes in every day at the same time, the rush of students, the slow-moving retirees. As Gombrich knew, rhythm is woven into our bodies, and there’s something deeply satisfying about places like these that allow for the rhythms of human existence.

In the last few years, however, I’ve realized that I’ve lost that sense of rhythm. If I’m bored waiting in line or on a bus, I can always jump back into reading the news, surround myself with the voices of the smartest podcasters, research something else I might want to buy. Some of this is due to the confluence of technological factors and the human desire for stimulation, but I think it’s the Skinner box of corporate social media that has rewired me. Before the ubiquity of fast internet, I was often alone: I was one of the people who relied on those clean, well-lighted places. But those places only get you so far, and you still have the ache of walking home in the dark by yourself. Or you used to.

Because we now live in a time of paradisiacal and almost unimaginable abundance. With its simple, homey design, Facebook gently guides you to what you want to see, gives you glimpses into the lives of old friends, shows you what’s been going on in the world, or adorable pictures of your nieces and nephews are doing. Twitter, by contrast, is like some galactic hub where the quickest wits, sharpest minds, and most reprehensible dirtbags from known space have gathered together to have a conversation or, more likely, yell at each other. And at any hour of the day, you can check in and feel like you’re in the thick of it: there’s always something going on on Twitter, and there are always more kids and cats and opinions and feels on Facebook, detached in time and presented to you in a single, unending scroll.

But Mastodon isn’t like that at all. There are days almost no one’s around, or evenings people go to bed early. There are times everyone is acting maniacally goofy and you’re not in the mood. There are times you find that you’ve come late to (or totally missed) an interesting conversation, and your belated rejoinders, carefully crafted as they are, can’t quite revive the subject: the moving finger of Mastodon writes, and having writ, moves on.

But the potential of Mastodon is precisely that it restores us, in some sense, to our postlapsarian existence. It reminds us that we are often lonely, bored, or both, that time passes rapidly, and that human connection is hard. But after you have been lonely in a new place for a while, the human connections are all the sweeter: you are immensely grateful to the people who are warm and welcoming at first, you’re impressed by the knowledge and wit of those around you, and you are reminded that a real community, which Mastodon is fast becoming, is an incredibly lucky thing.

Advertisements

Some great Digital Humanities resources

So I’ve been looking around for good materials on the Digital Humanities, and I’ve been a bit disappointed that so many of the resources that are out there don’t quite manage to do justice to either DH in relation to traditional scholarship or DH as a set of technologies. I’ve just come across Ted Underwood’s DH syllabi from earlier this year, though, that nicely cover both aspects of the field. I’m particularly impressed by the second syllabus (“Data Science in the Humanities”), which– though I’m not through all the materials on the syllabus yet– does an excellent job of giving in-depth consideration to the technical and interpretive challenges of the field.

His full blog post on both syllabi is well worth reading, too (as is his blog more generally!):

Two syllabi: Digital Humanities and Data Science in the Humanities.

Müller & Guido, Introduction to Machine Learning with Python (O’Reilly, 2016)

From O’Reilly and others, there’s been a profusion of data science books in the past few years. Given that many of these books are intended to introduce readers to data science methods and tools, it’s perhaps unsurprising that many of these books overlap at various points: you’ve got to introduce the reader to NumPy, pandas, matplotlib and the rest somehow, after all.

Müller & Guido’s Introduction to Machine Learning with Python is distinct from many of these other works in both its stated aims and in its execution. In contrast to many of the more introductory books on data science, Müller & Guido give readers with a serious interest in the practice of machine learning a thorough introduction to scikit-learn. That is to say, their Introduction largely eschews coverage of the data science tools often treated in introductory data science texts (though they briefly note the other tools they draw upon in Chapter 1). At the same time, because their book focuses on practice and scikit-learn, they neither discuss the mathematical underpinnings of machine learning, nor do they cover writing algorithms from scratch.

What is here is a comprehensive overview of things already implemented in scikit-learn (which is a considerable amount, as they show). More precisely, they focus on classification and regression in supervised learning, and clustering and signal decomposition in unsupervised learning. If your interest falls in those areas (particularly the former), their coverage is quite good. Chapters 2 and 3 discuss the algorithms for supervised and unsupervised learning respectively, and in considerable detail. That said– and though it’s somewhat less thorough– I might turn to the discussion of some of the same algorithms in Chapter 5 of VanderPlas’ Python Data Science Handbook before Müller & Guido’s; VanderPlas’ treatment is more conversational and less dry. (Note, however, that Müller & Guido do cover more territory.) Similarly, I was left wanting more from Chapter 7’s coverage of working with text.

Müller & Guido’s book really shines, though, when it discusses all of the other things that go into machine learning, beyond their march through the algorithms themselves. Chapter 4 discusses ways to numerically model categorical variables, also (briefly) covering ANOVA and other techniques of feature selection; Chapter 5 covers cross-validation and techniques for carefully tuning model parameters; Chapter 6 compellingly explains the importance of using the Pipeline class to prevent data leakage (during preprocessing, for example); and Chapter 8 discusses where scikit-learn and Python fit within the wider horizons of machine learning. The strongest parts of the book, then– and the parts where it’s the most fun to read– are where Müller & Guido discuss the practical details of machine learning. (One wonders if they felt a bit hamstrung by avoiding the mathematics of the algorithms they discuss.) There are points where the book is less engaging than other introductory data science books, but then it’s not really in the same category; rather than an introductory overview of the entire landscape, Müller & Guido provide a clear, comprehensive, detailed guidebook to one particular part of the map.

Why Twitter has lost; Or, against brevity

In the wake of the rumors that Twitter was going to up its character limit, I started spiffing up my Twitter profiles: I added a few photos, started adding people to my various lists, and even started using it a bit more. Then, of course, it seems that those rumors provoked such a backlash within the hardcore Twitter community that Jack Dorsey was forced to shelve any modifications to the format. Here we have, in a nutshell, the reason that Twitter has lost: it’s utterly unwilling to make any modifications to its established product that might make it attractive or useful to those who aren’t already committed users.

For better or worse, for example, I’m friends with a lot of colleagues on Facebook. This is annoying– sometimes I just want to post something silly or random, and it’s annoying that I have so many professional colleagues mixed up in my FB. (And yes, I know there are ways to tweak that, but who has the time?)

In a way that’s only rivaled by a very few high quality email listservs, Facebook is the place I go to hear what people in my field are talking about and working on (and from a usability standpoint, it’s actually easier to skim and follow discussions on Facebook than in my Gmail). My colleagues make comments about work they’ve been doing, share fellowship, grant, and job postings, pose questions, and generally take advantage of the fact that we’re all working on our computers N hours a day. My colleagues from grad school have a really phenomenal little group that often contains very specialized questions: requests for bibliography, questions about translations, and the like. It would be nice, in some ways, if some of these discussions were on Twitter: we could draw on the breadth of Twitter’s userbase, have discussions in real time to a greater extent, and get away from some of the ickiness that attaches to FB (and perhaps bring in people who stay away from FB because of said ickiness).

But just as a for instance, I was messing around this morning with looking at the character length of these discussions. These aren’t Tolstoyan ruminations or Herodotean digressions: most of these discussions are sparked by a brief, sometimes humorous comment someone has made about their work or something they’ve found in their research. Perhaps unsurprisingly, almost all of them are over 140 characters. Even just setting up the necessary context for many of these comments takes more than 140 characters. The only comments by my colleagues that fall under the 140 character limit are quick, humorous, and usually relate to popular culture (and so don’t have anything to do with professional communication at all).

Let’s be clear here: these are professional writers, and ones who’ve had a lot of success, too. These are people who write books and articles, and who and communicate for a living, who– as their posts make clear– are constantly engaged in the process of moving their ideas from insights to well crafted arguments, and for a variety of audiences, too. The argument that these people are incapable of concision and brevity strikes me as completely off base. (I make no such claims about my own capacity for brevity, however.)

The reality, I think, is that Twitter works great for subjects where everyone knows what you’re talking about: if you’re just railing about the latest idiotic or offensive thing that Trump has said, or some piece of celebrity gossip (and we all do), you don’t need any context. If you’re have something to say on subjects that require context or nuance, forget it.

But it’s not just that: I’m frequently astonished at how often Twitter falls down at its core functions: many, many times the most salient or compelling quotation on the news just won’t fit into 140 characters: I found a great analysis of some of the religious freedom legislation that’s been going through legislatures around the country a while ago, but the best quotations from and the core insights of the article just wouldn’t fit into 140 characters, and so I never ended up posting that analysis.

The result is that other services are eating Twitter’s lunch. Facebook, as I said, is pretty standard for a lot of scholars in my field. People in visually or design-oriented fields make a lot more use of Instagram than they do of Twitter. But it’s more than the fact that people self-select into platforms tailored to what they do instead of Twitter: it’s that these platforms are constructed in such a way that allows for novel kinds of use, and meaningful discussions beyond (and perhaps in spite of) the intentions of the platform’s designers in particular. I was surprised by how much substantive discussion there was on Instagram, for example, after the Freddie Gray murder and the unrest in Baltimore, and in a way that totally changed my feelings about the platform. Facebook allows for (even if it does not always brilliantly facilitate) real moments of connection: a friend going through medical difficulties, contact after a long period of disconnection, political debate that (sometimes) goes beyond kneejerk reaction. (And these are just things that have happened to me in the past week or so.) Every time I’ve tried to recommit to Twitter, I’ve had the opposite reaction: a lack of users beyond a narrow band of journalists, technology writers, and bots; friends with accounts who never post anything (and whose tweets get lost pretty quickly in the maelstrom); and, above all, the utter lack of any meaningful contact or communication through the platform, and the sheer disinterest of the company in fostering it. Twitter’s decision to stick with the current design of their broken platform may keep its users in the short term, but will do little to win anyone else over.

Cranky about OS X

So I needed a laptop for work, and, perhaps against my better judgment, I decided to go with a Macbook Pro. I’ve had mixed experiences with PC laptops, where I think build quality varies wildly and it’s hard to consistently get a good piece of hardware (though I am somewhat curious about the Dell XPS ultrabook line, though unenthusiastic about its weak keyboard).

Along with this is that I’ve always liked the fact that OS X is built on top of Unix; not a variety of Unix I know well, to be frank, but still. What do a few cosmetic changes matter compared to a shared POSIX heritage?

Welp. I am now regretting my decision, and to a not inconsiderable degree. Where to begin? The lack of a decent package manager? The fact that in El Capitan Apple has made the Disk Utility completely worthless for partitioning? The fact that it’s impossible to write an .iso to a flash drive without mucking around with the dd command?

My naive belief was that OS X is an operating system that hides some of the complexity of its internals from the end user, but that makes up for that with a polished user experience; my hope was that, beneath the hood, OS X still had a lot of good functional tools for the power user. I’m finding myself somewhat disappointed in the first respect, and deeply frustrated in the latter. The iOS-ification of OS X is much, much worse than I thought, and has really made me miss a lot of the functionality of Linux. Hell, I’d settle, in some respects, for the advances that Windows has made in 7 and 10.

Klemens, 21st Century C (2nd ed., O’Reilly, 2014)

As everyone knows, Mark Twain defined a classic as a book that everyone wants to have read and no one wants to read. Everybody who does some programming knows that K&R is a classic, by any standard– it’s the Rosetta stone of modern C programming, but it also helps to clarify the design principles (and of course the syntax) of many of the modern programming languages that are derived from C. Even beyond languages with a clear C lineage, it’s easy to see the way that a whole host of other modern programming languages have been written to simplify things that are tedious or risky in C. At the same time– and like a lot of other people, I’d imagine– K&R sits on my shelf and stares at me most of the time. When I open it, sometimes I think “What an impressively written book! What concision and clarity!” Most of the time, though, I think, “Wow, how gnarly– thank God for Python!”; or I wonder whether any of the details K&R fuss over are relevant today.

Ben Klemens’ 21st Century C is intended to resolve some of this shock, and to serve as an introduction to modern ways of working in C. The first part of the book presents tools and best practices for this (including debugging, testing, and version control), while the second half discusses how to write modern C– C in a world where, among other things, the rigid memory constraints taken for granted in K&R no longer apply. Some parts of the book (like the discussion of pointers) are clearly meant as an introduction or refresher for readers who aren’t comfortable in C, and the book includes a handy appendix on the basics of C. Other parts live up to the book’s billing as an explanation of what has changed in the world of C. The discussion of new structures in modern C, for example, is a highlight of the book. Klemens’ discussion of string handling in Chapter 9 was also interesting, though briefer than it might have been. (Perhaps with good reason: as someone who works almost exclusively with strings– and even though Unicode in modern languages isn’t always fun, either– I remain unconvinced that working with strings in C is something I want to do on a regular basis.)

As my comments above suggest, I am not an experienced C programmer (despite the occasional stab at the exercises in K&R), and am thus rather unqualified to pass judgment on the soundness of any of Klemens’ code. I can only assume that the infelicities and problems mentioned in reviews of the first edition of the work have been resolved. As a C tyro, though, I felt that Klemens effectively explains the ways that different practices– and the C standards, as well– have evolved over the years. It would be tempting, I think, for the book to remain at the level of vague generalities, but the book strikes a nice balance between high-level discussion of the way C programming has changed over the years and detailed discussion of what’s going on under the hood. It helps immensely, I think, that Klemens has a light, humorous touch– he notes that the manual memory model “is why Jesus weeps when he has to code in C”– and the humorous asides help to leaven some of the necessarily technical passages of the book.

Klemens’ book has the unenviable task of competing with K&R, and there are parts where 21st Century C suffers for the comparison. I still prefer K&R’s discussion of pointers; and I felt that there were a handful of sections that add little to what’s already in K&R. Klemens is fond of comparing C to punk rock, and upon reflection, I believe the comparison is an apt one. To push the metaphor further, there are ways in which K&R is, like a classic punk album, indelible in its simplicity and directness. To my mind, Klemens’ book is a worthy attempt to take that simplicity and directness and make it speak to a changed world. Klemens’ book isn’t perfect; if we’re honest with ourselves, though, even the hardiest classics aren’t always, either.

Goodliffe, Becoming a Better Programmer (O’Reilly, 2014): A non-professional’s take

Goodliffe’s Becoming a Better Programmer is marketed to a wide range of readers: to veterans, newcomers, and also to those who do some programming on the side as a hobby (Hi!). This is not entirely accurate– the book clearly has professional developers in mind most of the time– but I found the book to be an interesting discussion of aspects of the art and craft of programming all the same.

The first two parts of the book discuss a number of features of writing and working with code, both the theoretical/philosophical side and lower-level issues like producing and maintaining consistently formatted code. These sections are clearly oriented primarily towards professional developers, who are probably working in a production environment, have an existing codebase to work with, and may well be under pressure to skimp on design or testing in order to ship code more quickly. Even so, in talking about all of the problems that particular code or a particular codebase can have, these parts also talk at length about the principles and design behind good, sane code, and I found these sections useful and interesting. He discusses cohesion and coupling, omitting needless code (the YAGNI principle), and producing simple and sufficient code– along with practical advice about stuff like testing and version control.

The last three parts of the book are concerned with the softer side of being a developer, both personally and interpersonally– working well with your team, responding to superiors, and even personal things like ethical considerations and the importance of good posture. These sections are lighter weight (and often briefer), and sometimes repetitively summarize earlier points in the book. But they’re an easy read, and can be humorous in a way that the sometimes strained jokes of other sections aren’t. (For example, Goodliffe talks about your relationship with your primary language as a marriage, but then notes that, unlike most marriages, it can be quite helpful to play around on your “spouse.”)

It’s worth pointing out that Goodliffe’s book seems much more oriented towards discussion than to armchair reading. Each chapter takes up a subject, discusses different approaches to that subject (sometimes briefly), and then gives a set of questions. In most cases, Goodliffe is undogmatic– he lays out his position in the text, but the questions leave open the possibility that other experienced developers might have a different take. This format seems like it would work well for reading with a mentor (as the book suggests) or even a book club.

Goodliffe’s language-agnostic approach makes the book broadly accessible but also somewhat abstract. I think the book would have been stronger if he were clearer about applying principles to particular languages. Goodliffe’s book will not replace the resources that give advice and best practices for the idiomatic use of whatever language you’re working in, therefore, but it’s a quick read, and may get you thinking about the way you code, even if it’s only something you do in your spare time.