ch-ch-changes

A lot has happened in the last year. I left MIT and joined CDG (Alan Kay’s lab), working with Alex Warth. I’ve been going to LA a lot. We are working on an end-user programming tool called Transcript.

My Holy Grail has been to radically simplify professional programming. I now realize that simplification is not fundamentally a technical problem but rather a cultural one. Our nerd culture embraces inhuman levels of complexity. Mastering mind-boggling complexity is our mutant superpower. It is our tribal marker. Complexity is the air we breath, and so it is invisible to us. Simplification will only come from outside this culture. To disrupt programming I first have to reinvent it for a fresh audience of non-programmers.

Here’s a video of our first (very rough and preliminary) talk about Transcript.

 

 

17 Replies to “ch-ch-changes”

  1. Can the syncing be implemented in a decentralized p2p fashion?

    Why not develop it in the open github/etc world?
    Just asking, because I think at best it may advance more rapidly.

    1. Yes we want to be open and decentralized (so it can be free). Don’t know how to do that yet. We could piggyback on Google Docs/Dropbox but we would still need a push notification mechanism. Suggestions welcome.

    1. Yes there are similarities with Wave but maybe more spiritually than technically. They had some really good intentions that went wrong in the end. The competition now is chat apps like Slack and Messenger.

  2. I very much enjoyed the talk. I love the example of the book club. This stuff drives me crazy! It’s great to see you working on bringing your ideas into a product.

    How do you deal w/ changes to the types once you have instances?

    Most of my (non-programmer) friends don’t actually know how to use Excel. Can they really be convinced to learn something like this? Do you believe it’s easier than Excel, or just adds enough power to attract them despite being more abstract?

    1. Changes to types or structure are what the DB people call a schema change. This may require specifying how to migrate existing instances. However making these changes within a GUI designer will capture more information than a textual schema can. For example, renaming a field is explicit in the GUI but in the text can’t be differentiated from deleting one field and adding another.

      Gee, I’d consider being as easy to use as a spreadsheet would as a great success. Probably won’t get quite there.

  3. I think the graphic programming concepts you explored years ago apply here. Construct programs by dragging icons representing containment, actions, and relationships from a sidebar to a program area. Learn icon functionality via single-tap help-text, which changes depending on whether the icon is in a sidebar or in use by a program. Customize characteristics via double-tap pop-up forms with checkboxes.

    The UI can guide programmers (and improve ease-of-use) by highlighting valid sidebar icons when a program element is selected, and highlighting valid drag-to regions when a sidebar icon is selected.

  4. First, congratulations on your new position. I’m sure your ideas will be much appreciated.

    Second, nice nod to David Bowie.

    Third, you might want to investigate the Phoenix Framework written in Elixir that sits on top of Erlang. WhatsApp runs on Erlang and scales to 42 billion messages per day. Couple these tools with the Elm language for a reactive UI.

    Peter

  5. Jonathan, you have come a long way since Subtext. The road has been curvy. Is there anything still common in Subtext and Transcript? Outside of the shallow slogan of ‘making programming simpler’.

    1. Transcript is a Trojan Horse hiding Subtext on the inside. At the moment it is a subset of Subtext but I will fill it out as needed. The strategy with Transcript is that it is a place where new language ideas can succeed: no performance and compatibility constraints, and no ideological commitments to existing ideas.

  6. Very very cool!!

    As I was watching it, I kept asking myself “Is this something nonprogrammers would use?” I hope so but I don’t know the answer. On the one hand, if you could turn this into a super-polished app and had really good marketing and PR, I think there is a chance that you could get something like this adopted by nonprogrammers. That requires lots of capital though, like you mention in your other post. :\

    On the other hand, I am not sure end users will go out of their way to learn something that is even a little bit more abstract or general purpose than what they do now, even if it is elegant, cohesive, saves them some work, etc. The pain has to be high enough to compel them to action, or else you need to make the experience of using Transcript so absolutely delightful that they just *want* to use it even if it isn’t that much more efficient.

    Not sure what I think about your examples, I know not to read too much into any particular example since you are more just trying to convey ideas, but I think there might be a gap here – IMO emails are fine to organize a book club, and people don’t really care to be so systemic about it (and maybe are even resistant to that), because it just doesn’t matter all that much and book clubs are just done for fun. (Everyone sends some freeform emails, then whoever’s turn it is to pick decides, and the freeform discussion is very much part of the experience. It’s a social thing, not a formal voting process.)

    Same deal in the hackathon. Everyone joins a Slack channel, there’s freeform chatting in there, and people self-organize. It’s social, simple, and good enough.

    The need to get systemic arises more at larger scales… and at those scales one starts to need more Professional Programmer (TM) tools to deal with the complexities that arise… but perhaps there are some sweet spot use cases somewhere in the middle where the Transcript approach could really shine.

    Looking forward to seeing where this goes.

    PS: We are kind of working from opposite directions… 🙂 At the moment, I really want to make programming vastly better for expert programmers… people building the next Google, Twitter, whatever. Any ease-of-use improvements of Unison are more of a side effect of working toward that goal. The idea of end-user programming is really appealing to me too, but feels like a harder problem and I’m not super focused on it now.

    I wrote some stuff about tech adoption here related to this.

    1. Thanks for your comments Paul. You raise good questions that I won’t know the answer to till I get feedback from real users. As you say it’s all about finding a sweet spot, like spreadsheets did. I do feel that we are discovering a new point in the software design space that provides surprising power for the learning investment required.

      Indeed we are coming at things from opposite directions. I recently came to the realization that I am fed up with the attitude of expert programmers and so have shifted to non-programmers.

      I liked your essay on designing for experts. If I were to write a response about designing for beginners I would argue that the learning curve is best understood economically. Learning is a capital investment. Many people have limited capital (because of limited talent) and so don’t have the option of investing in arbitrarily sophisticated tools. Other people will make a ROI calculation that the benefits of the software they need doesn’t warrant the investment in such tools.

      1. Yeah, as I said, I look forward to seeing where your project goes. No matter what happens we will all learn something.

        > I recently came to the realization that I am fed up with the attitude of expert programmers and so have shifted to non-programmers.

        Ha, I know what you mean. However, I think you’ll find that any group of people (programmers or end-users) has some resistance to change / unhelpful attitudes that you’ll have to overcome. So the problems don’t go away, they are just different… it all depends what you are willing to deal with.

        > If I were to write a response about designing for beginners I would argue that the learning curve is best understood economically. Learning is a capital investment. Many people have limited capital (because of limited talent) and so don’t have the option of investing in arbitrarily sophisticated tools.

        That is a good point. I did not talk about this in the post but I don’t really think people (or organizations) are so rational about their decisions – they don’t really sit down and do an ROI calculation and decide “it doesn’t make sense to learn this now”. Also, people are often quite capable of learning more than they do, but don’t for lots of reasons (fear of learning, fear of feeling dumb, etc) that are often more emotional. And when people do learn something voluntarily, (not forced to by an employer or in school), it’s often just because it is fun, interesting, and inspires curiosity… the same sort of drive that makes people solve puzzles for fun.

    2. A source of Transcript use case examples might be business process / workflow automation. OK it’s not cool, and not as widely accessible as the book club example. But the comparative advantage of Transcript might be higher.

      If your company manufactures bespoke widgets, there are probably a fair few widget process tracking forms involved, and they probably get passed around for review, to announce updates, and to hand over responsibility between teams as the construction proceeds.

      If you make 1000 widgets per year, then you’ve probably got a custom software tool to manage the workflow. If you make 10-100, you probably haven’t, you probably use spreadsheets plus email, and it’s probably a pain.

      In that situation, you might well be more motivated to learn something new, than someone organising a private get-together using surveymonkey / google forms plus email.

      Another thought about plausibility of the book club use case, is that someone running their club might not ‘code’ the Transcript book club program themselves, but might find online one someone else made earlier, and tweak it. So you don’t have to imagine the whole user base becoming app creators to imagine Transcript making an impact.

Comments are closed.