Cessen's Ramblings

2018 - 09 - 18

Politics and Open Source Communities

Bryan Lunduke posted a video earlier this year entitled "Divisive Politics are destroying Open Source". I only just now came across it, and it sparked both thoughts and feelings for me. My thoughts are not, I think, terribly complex, but I would nevertheless like to take a moment to write them out. In particular, as an avid Rust programmer, I'd like to give my perspective on the Rust community, since Bryan briefly touched on that.

Bryan's video, if I can summarize it in a nutshell, covers several cases in the open source world where he feels that leftist politics are seeping into communities and actually making them less inclusive. As far as I can tell, Bryan himself seems left-leaning (though I could be wrong), so that's really interesting to me.

(Also, for context while reading the rest of this post: if I were to label my own socio-political views, I would certainly label myself left. Quite far left, actually, I think. Though I try not to take on labels, at least not in a prescriptive way. In any case, I'm not right-wing, voted for Hillary (though would have preferred Lessig), all of that.)

One of the things Bryan's video got me thinking about is what "inclusive" ought to mean with respect to things like open source communities. Much like the word "art", people will disagree on the specifics of what qualifies as "inclusive". Also like the word "art", I do not intend to claim any ownership over what definition should be assigned to it. Nevertheless, I think there is a positive value behind that word that most people can get behind.

Almost everyone has had experiences where they felt excluded, and typically such experiences aren't positive. And I think most human beings with empathy can agree that creating circumstances where people feel excluded and rejected is generally a bad thing. Sometimes that "badness" is a price we pay for some other more important outcome. For an obvious and unnecessarily silly example, I don't want some uncoordinated Joe Shmoe waltzing about the operating room while surgery is being done on me, no matter how excluded he may otherwise feel. But that exclusion is nevertheless a price. It is something we would like to minimize where possible.

I think this very core human experience--of being excluded, of being rejected--is often overlooked in the way people talk about diversity. A lot of people go on and on about how diversity of backgrounds brings diversity of ideas, how it improves productivity, it improves outcomes, etc. But I think all of these things just aren't the real issue (excepting for in politics or similar where representation is important). The real issue is that being excluded sucks. Being told you can't join the club sucks. Being told that you aren't allowed to participate sucks. Being told that people don't want you sucks. And in some cases, being excluded can actually prevent (or at least make much more difficult) exploring something in your life that you want to explore, or from taking your life in a direction that you want to take it, or from connecting with other human beings. These are the things that actually matter about being inclusive.

And I think there's actually a better word than "inclusive" to describe that value: welcoming. I want communities that I'm a part of to be welcoming. There is a warmth to that word that "inclusive" lacks. It brings to mind images of open arms, of encouragement, of supportiveness. It says, come on in, no matter who you are, and sit down by the fireplace and have a nice cup of hot chocolate with us. We want you here. That is what I want in a community (among many other positive traits).

So how does Bryan's video tie into all this? Well, where I find myself agreeing with Bryan is that I think there are plenty of people on the political left that are really shitty at being welcoming, especially when it comes to people that don't share their politics. Of course, this is not an exclusive trait of the political left. But I feel like the language we use on the left about inclusivity and diversity sometimes serves to obscure whether or not we're really being welcoming.

So far this has all been really abstract, so let's bring in a concrete example from Bryan's video. One of the people he talked about is Ashley Williams. I won't go into the whole debacle, but Ashley is (if I recall correctly) currently the team lead of Rust's Community Team. And she posted things like this on Twitter:

never underestimate the wrath of a mildly inconvenienced white dude (and yes it is all dudes complaining)

I want to take a moment to state in no uncertain terms that I don't think Ashley is a bad person. Honestly, I suspect she's probably a great person. And if you look at her more general involvement in things, you'll see that she's really cool! People vent, and sometimes people vent online. And also, sarcasm/hyperbole often doesn't translate well online. I've had plenty of my own mis-steps.

Anyway... it is nevertheless pretty clear that her tweet is not welcoming. In fact, I'd say it's quite the opposite! If a woman overheard some guys complaining about women (even sarcastically and with hyperbole), I'm pretty sure that woman wouldn't feel very welcome. In fact, I'm quite certain articles have been written on that topic. But also, if I overheard some guys complaining about women in a way analogous to Ashley's tweet above, I would feel unwelcome, even though I am not a woman. And that's because it creates an unwelcoming environment.

Whether we care about white men in particular feeling welcome is something we could discuss (and I would argue that, yes, we should care, because we should care about people, but that's a digression for another time). But regardless, I really don't think we get to pick-and-choose what demographics of people we're welcoming towards. Most empathetic human beings dislike seeing other people being shat on (past traumas or brainwashing notwithstanding), and it creates an uneasiness about whether that kind of behavior is acceptable in general. It's like when you're on a date with someone and they're super nice to you, but they're an asshole to the waitstaff.

Now, where I disagree with Bryan's video is in how dire he makes things out to be. My take on these sorts of situations is generally something like, "Yeah, people can be shitty on the left as well--sometimes really shitty." I don't think the world is going to end. Looking at the Rust community, I think overall it does a pretty good job of being welcoming, including towards white men. Is it perfect? Nope. And I do think there's a tendency on the far left to be unaware (sometimes aggressively, seemingly willfully so) of their empathy blindspots. But nevertheless, the Rust community gets a lot of things right.

My biggest concern is failing to be welcoming to people with different political views. Maybe that sounds strange to some people (especially those that vilify the right, "Good riddance!"). But I don't think that should sound strange. I've seen some politically left jargon used in posts from the core Rust team about community management etc. The Code of Conduct also uses some jargon and framing from the left (e.g. "We don’t tolerate behavior that excludes people in socially marginalized groups," instead of just, "We don’t tolerate behavior that excludes people."). And although that's not explicitly unwelcoming, if you put on the other side's shoes for just a moment it's not hard to see how that gives a feeling that Rust is a politically left community in general. And maybe it is. But I don't think it has to be.

And this comes back to why I think inclusivity is actually important. Excluding people hurts. Excluding people is bad. At best, it's a price we pay for some other gain. So what is the gain in this case?

If we want to maintain a welcoming community, then everyone in the community needs to be welcoming. That sounds like a tautology, but what I'm getting at is I do see the value in pushing people out who are not themselves willing to be welcoming--or at least willing to not get in the way of the rest of the community being welcoming. The first bullet of Rust's Code of Conduct has it totally right:

We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.

But I would like to add "political views" to that list, even if only implicitly. If part of someone's political views is literally "black people suck", that obviously won't fly. But neither would it fly if someone's religious beliefs included "gay people should be stoned," even though religion is already on the list. So I guess what I'm saying is, in my mind we should aim for this:

We are committed to providing a friendly, safe and welcoming environment for everyone who is willing to uphold this same commitment, regardless of any other trait they may or may not have.

This is surprisingly subtle, though, because I think there are plenty of people on the far left who think what they're already doing is equivalent. As far as I can tell, they believe that the socio-political views of the left are the only views compatible with being welcoming as above. But they aren't. And neither are they sufficient, as Ashley's tweet above demonstrates. There is something deeper and more human about being genuinely and warmly welcoming to everyone. And it isn't about socio-political views (except those that literally conflict).

This whole post is really rambling, and it's not at all clear that I've even communicated my point very well. But I wanted to put this out there because... dunno, really. Come to think of it, I don't think anyone actually reads my blog.

2018 - 01 - 31

A New Kind of Editor

My first post in four years! And, interestingly, on a similar topic as my last post.

Zed, the editor I raved about in my last post, is now essentially abandoned and unmaintained by its author. This is understandable given the direction his career has taken, but is also a bit unfortunate given its innovative approach to editing.

I've since been bouncing around using some other editors, including Atom, VS Code, and most recently Sublime Text 3. In all three cases I've configured them to function as similarly to Zed as possible, but it's never been quite right. Under the hood, all three editors still assume an "open dirty buffer" model of document management, and this leaks out from time to time.

Despite the shortcomings, I've been mostly okay with this state of affairs. But there are nevertheless some things that annoy me:

  1. Both Atom and VS Code are built on top of web technology. I don't like my editors taking up hundreds of megabytes of RAM with only a couple of text files open. That's just silly. And in Atom's case, it has chuggy performance to boot.
  2. Sublime Text isn't open source. I don't mind paying for software (and happily did in Sublime Text's case), but I always feel nervous about committing my workflow to software that doesn't belong to a larger community.

Because of these annoyances, a few years ago I developed an interest in writing my own editor. This sounds completely silly, and it pretty much is. Nevertheless, the journey of creating my own editor has been really interesting, and I've learned a lot of cool things.

Realistically, I don't think the editor will become anything worth using, but it's a really fun exploration, and I want to share that. I have more to share than will reasonably fit in a single post, so this will be the first post of (probably) many.

Led

My editor is called Led, which can stand for "Lousy Editor", "Loser's Editor", "Laughable Editor", or any number of other derogatory phrases that start with "L" and end in "Editor". In its current state Led is a console-based editor that:

  • Can load text files faster than even Vim. A 1GB file takes approximately 1.5 seconds to load on my machine, vs 2.5 seconds for vim.
  • Can edit said 1GB text file without breaking a sweat. (Including when it's all on one line!)
  • Supports real time word wrapping that you never have to wait for. (Even with the afore-mentioned 1GB all-on-one-line file!)
  • Correctly handles Unicode text, including graphemes and double-width characters. (However, it doesn't do bidirectional text.)
  • Recognizes all Unicode line endings (there are eight of them!).
  • Has basic undo/redo functionality.

All-in-all, it's an extremely bare-bones editor, but that has some really robust characteristics. I would absolutely not want to use it for any real editing tasks, but it feels pretty great that in the realm of bare-bones-only text processing it beats out every other editor I've tested it against. Essentially, Led can open and happily edit any utf8 file you throw at it, as long as it will fit in RAM, no matter how weird. Every other editor I tested (including Vim, Sublime Text, emacs, etc.) chokes in at least some corner cases.

Personally, I think that's pretty cool, and I'm reasonably proud of it. Makes me feel like a good software engineer! But obviously, it has a long ways to go to be useful.

Vision

My lofty vision for Led, which will likely never come true, is basically to create a better Zed. Zed made some great UX decisions, but was implemented on top of web technology. Creating a native-code clone would itself be a nice boost, but in the process of developing Led I've come up with some additional things that I want to explore.

The main thing I want to explore is a more expansive view of what is considered "the thing you're editing". Every editor I've ever encountered considers a text file as the thing you're editing. But I think in reality the thing you're editing is the entire code base.

Now, I'm not saying that code editors aren't multi-file aware. Obviously, most are! In fact, every good code editor I've used allows you to work with some kind of project or directory concept. But editing operations aren't treated at that level. The primary experience I've had that makes this apparent is when you do a project-wide search-and-replace: there's no "undo" operation for that. And that makes such operations pretty scary. For most editors this situation is understandable: an undo operation that applies to multiple files raises a lot of questions, like what the state of all the touched files should be afterwards. Saved? Loaded and dirty? Some other weird special-cased concept?

Zed's approach to editing eliminates most of those questions entirely. Buffers are never dirty, undo is infinite and persistent, etc. With that approach you can treat the entire code-base as a single item that just happens to be subdivided into files. Then operations like multi-file search-and-replace, refactor operations, etc. are like any other editing operation, and can be undone, redone, etc. just like anything else.

In such a system, undo within a single file is just a special case: you're selectively undoing within an area. And you could take that even further: if you can selectively undo within a single file, why not within a selection? I cannot count the number of times I've made some edits in one place in a file, then done some unrelated edits elsewhere in it, and wanted to temporarily undo the first edits while testing the second edits. It actually happens quite a lot. Being able to select an area and undo within that would be great!

With this approach, all operations become something that function within a scope, which can be as large as the entire project, or as small as a tiny selection. This would make everything, not just undo/redo, potentially much more powerful.

The default scope for things should probably still be the currently active file. But this concept unifies a lot of things that are otherwise disjoint and strange. I would like to explore how to make something like this work in practice.

2014 - 10 - 27

Zed: a Code Editor

I like to write code. And like many such people, I am constantly in search of the perfect code editor. Of course, such a tool does not actually exist. But nevertheless, from time to time I like to try new editors that seem to present something new and interesting, to see if I can improve my code editing experience.

Most recently, over the last year or so, I've been playing with editors built on top of web technology. Specifically, I've been playing with Light Table, Brackets, Atom, and Zed.

I started off with Light Table—which is a really cool and innovative project, and I certainly recommend checking it out—but I pretty quickly migrated to Brackets (which is a bit more conventional) for most of my coding.

Brackets is a really cool editor, with an obvious focus on UX concerns. The editor itself looks beautiful, and I appreciated how it eschewed tabs in favor of a simple vertical list of open documents. Despite Brackets being targeted at web development, I primarily used it for C++ coding. And it worked wonderfully. The only real complaints I had about it at the time were that its scrolling and editing were a bit laggy, and it didn't support split views. (Incidentally, it now supports split view.)

Then GitHub announced Atom, and not too long after that released it as open source. Atom has split view capabilities, and in general looked like a nice editor, so I gave it a try. Despite the split view feature, and ostensibly being better suited to non-web-development coding, I found I just didn't like it as much as Brackets. So I went back to Brackets for a while.

Then I somehow stumbled upon Zed. I don't actually recall how I found it, but I did. And boy am I glad I did.

Zed, in my opinion, is the best code editor I have ever used. It makes some really bold UX decisions:

  • There is no manual saving. The editor automatically and continuously saves your documents as you are editing. This takes some getting used to, but it's actually really fantastic. It means documents are never in a "dirty" state, and you never have to worry about saving.
  • Zed has an infinite undo stack that is preserved across editing sessions. You can close a file, close Zed, and restart your computer if you like, and when you open the file again you still have your full undo stack all the way back to the first time you edited that file. This works extremely well in combination with the continuous saving.
  • No tabs or open document lists, just quick-open short-cuts. Since documents are never unsaved, there isn't any need for an "open" set of files. The only files that are open are the files currently displayed on screen for editing. You can jump between documents easily using various short cuts.

This unique (dare I say innovative?) approach that Zed takes means that it takes some getting used to. But after using it for a few weeks, I find it really difficult to go back to other editors. Zed really smooths out the editing workflow in a way that I've never seen before, and it is quite fantastic. It really changes the feel of working with a code base. Trying to go back to other editors now feels very much like a step backwards.

Moreover, despite being built on top of web technologies, Zed is surprisingly snappy. Unlike Light Table, Brackets, and Atom—all of which feel sluggish and laggy—Zed feels almost like a native application. I have yet to experience any lag in scrolling or editing except in really egregious circumstances. Opening files is also extremely snappy for all but the largest of files.

There is plenty more to Zed than what I've outlined above. It is a project-oriented editor (you start a session by selecting a root directory for the editing session), so it is not well suited to editing individual documents. But what you gain from that is project-wide code indexing for jumping to symbol definitions, project-wide search, etc. It is a very capable code editor in general, with things like multi-cursor support, etc. And to top it all off, it's cross-platform and open source.

I forsee this being my code editor of choice for quite some time. I highly recommend checking it out.

2014 - 06 - 25

Psychopath Renderer Website

I've created a blog/website for my 3d renderer: http://psychopath.io

Woo hoo!