The Aesthetics of Programming Tools (Future of Coding podcast)

Episode 41 of the Future of Coding podcast features guest host Ivan Reese (@ivanreese here and @spiralganglion on Twitter) interviewing Jack Rusher (@jackrusher / @jackrusher) about the design of the tools we use to create programs.

Some of my favorite excerpts are below. Two themes I notice are discussing trade-offs rather than picking a “side” in some constructed dichotomy, and imagining new ways of interaction for the production of software.

I don’t think it’s actually a good thing that people have given up on the idea of improving what they can produce visually, or in terms of interaction, in exchange for not having to think about how they’re going to do any of those things.

Anything that taps into our evolutionary heritage I think is very strong, and that’s been known at least since people like Minsky and Papert were trying to teach children with physical, mechanical turtles and things. Bringing in our intuitions — our physical intuition — is one of the strongest ways to give us a jumpstart on learning a new domain. …you can vary your presentation in order to recruit the user’s visual cortex to do most of the work before their higher facilities begin to try to figure out what’s happening. You have things like relative contrast, relative size, grouping by position in space, all of these different things. I think in programming actually, we make shamefully little use of most of these ways of conveying information to our users.

It is a bit of a tragedy really that the editing environment continues to be… people [writing] new editors for programming languages that offer you a grid of fixed-width type.

If I’m doing graphics programming, it can be very frustrating if I have to marshal a new data structure and return it out of everyone of my functions, because the buffers that I’m moving around then are going to cross these different memory boundaries, there’s going to be a lot of allocation and deallocation happening, and I’m going to have terrible performance. In those situations, I need to be able — if I want to write that kind of code — to drop down to a layer at which I’m just slamming bytes into a byte array. But it’s not how I prefer to write most programs, right? So, optimally, ideally, I want to be able to slide back and forth along that continuum as needed, staying as far towards the declarative side as I possibly can and only dipping down into the rest as needed.

One of the things that I think isn’t talked about enough, when people talk about languages with a strong upfront type discipline like Haskell, is that everyone focuses on this as a way to avoid making certain kinds of mistakes. But they don’t really talk so much about how effective it is as a user interface paradigm, because the more the machine knows about what’s possible, the better sorts of completion and filter it can give you moment-to-moment while you’re editing your code.

Smalltalk is tremendously dynamic and to this day has the best developer tools that any system can really offer. It’s a ridiculous argument that you can’t make good tools on top of dynamic languages.

But don’t trust my quotations; they wander into other computing topics quite a bit.

8 Likes

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.