1. We’re here at QCon London 2013, I am sitting here with Ward Cunningham. So, Ward, who are you?
Well, I am best known as the person who made the first Wiki, and I have also contributed to Extreme Programming and Agile software development, the first Wiki was about Extreme Programming and software development and the patterns movement, helped launch software patterns, and all those are things that kind of run together in my mind, programming and Wiki are just two ends of a spectrum of things that are all very closely related, so that’s what I am, I do that stuff.
Oh it won’t go away, period. I think I was kind of surprised when I was learning computer science that simulation played such a central role and the fact that a major programming language would be called Simula, but then I fell in love with simulation and I am scratching my head trying to figure out what is the connection and what it is, is that simulating is a great model for computing. There was a time when you did the simulation at the chalkboard and you figured out what’s the smallest number of instructions we can put in the computer. So the model stayed on the chalkboard and you put the calculator aspect into the computer, but when it got big enough you just put the model in the computer and how do you structure a model? That’s objects, it’s probably one of the most powerful… it’s related to the things that we care about and the methodology for simulating them for a purpose. So, that’s what object oriented programming is. I fell in love with Smalltalk, it kind of landed in my lap, I was working at Tektronix in their research labs, I was a language-a-month sort of guy, I said this is my language, this one does everything that I ever expected of a language and it taught me so much, I worked on it for 15 years. But, it looked like it was going to be number one and it turns out to be number two, below C++, and then when Java snuck in there, Smalltalk became number three, well there really isn’t any room for number three, attention goes to number one and number two and that was really the end of Smalltalk, although like every other one of those languages that I learnt month after month they’ve all had their impact and impact stays. Of course, C++ and Java are continue to contribute, day in and day out and there’s another parade of languages that have interesting things to offer.
Werner: So, you view object orientation as a way to structure programs.
That’s right. And I will say that we felt in this pure object environment that there was a correct way to use objects and objects would give you the most value. Extreme Programming was a process where you could be pretty sure you got it right, if it wasn’t right you refactored it until it really proved itself to be right, so the whole Extreme Programming thing was really to get the best value out of objects. And I think now our programs are so big that they sprawl over dozens or hundreds of computers and it’s less important that it be perfect. People now talk about robustness or resilience as being even more important than correctness, and I think that that is a wisdom that comes from managing the computers we have today. So, it’s not that objects are less important, it’s just that other things are becoming even more important, so our attention is diverted from the leverage you get from really great objects. Really great objects are really just a gift when you have them, they keep on giving.
I think that making sense of something that doesn’t make sense is really the challenge. You are expecting to get a certain thing and you don’t get it, but you don’t want to just quit, you can’t throw a notifier up to the user because there’s no user there to throw up a notifier to, you have to carry on, and that working through all those boundary conditions is where that comes from and accepting that you aren’t going to know everything, you can’t have comprehensive knowledge of everything. I think there was a feeling because even with a megabyte, two megabytes we had at the time, we considered that big, you could know every object, you could know Smalltalk completely. That’s why it was called small, because it was possible to know it completely and I think those days are over. We live in a world where we simply cannot know all the programs that we have to touch and coax into doing our bidding.
Oh, I’ve admitted that in public and people said “oh, one of those?” I’ve done a lot of Ruby code because it has that Smalltalk heritage, I’ve done a lot of Java, I’ve made Java jump through hoops, right now I am working mostly in the browser and I’ve fallen in love with CoffeeScript, and it turns out that I will run into a JavaScript programmer and he’d say “oh, CoffeeScript, well you must be one of those Ruby guys”, and it’s funny that we show ourselves so completely by our preferences, but the shift is of course to much more reactive programming, this event oriented programming and you can ignore it in the browser and it pretty much works, but if you are doing a lot in the browser, you have to pay attention to that and the callback style and so forth. And it just codes up nicer, to my mind, in CoffeeScript. I did say that when I was in CoffeeScript and I have this environment where I am pulling content from all over the web, that reminded me of the power I felt in Smalltalk. So, it’s less about making the program over here and running it over here, it feels more alive to me. And I think that is just because the particular set of tools just happens to be working well for me, in that way. I think that will change in the next big thing I do, I think I will set CoffeeScript aside and get in there and put in all the semicolons to make JavaScript right.
Werner: So, you don’t have a problem with JavaScript as such, with the model of JavaScript.
Remember Smalltalk was pure, and JavaScript isn’t. In fact, I think today we are still figuring out how to properly write JavaScript, one of the things you face is saying “well, what style will we use?”, there are four or five or six styles. C++ had that same problem, there was never a strong community around C++ as there was around Smalltalk, because if you were doing Smalltalk, it was clear what you were doing. But if you were in C++ you might be doing embedded C++, you might be doing Windows C++, you might be doing Unix C++, you might define a bunch of compile time macros and do something that nobody had ever seen before. So, that fracturing makes for a lot of different communities. I think JavaScript is all over the place, but Node is pretty interesting, it takes that sequential, the synchronous calls that we learnt to use in Unix and makes them asynchronous again, and dealing with that, I think we have a lot more power to deal with asynchronous then we did before garbage collectors where accepted. So, yay Java for making the world safe for garbage collectors.
I think, well I like to say the most important words or verbs or operators are the shortest ones, like + is pretty important so it doesn’t take a lot of space, but if you think about a sequencing, putting one thing after another, that sequential nature is that one operation that is just implicit in just about every language. So, yes we think of things sequentially and that was a real advance when Unix came along and said “let’s make simple little things that read from input and write to output and then you can put something at the other end and catch that and read it and write it and that pipeline is an architectural form”, very successful, I consider it the Latin of our discipline, to go back and think in those terms. But, as we build the really high performance data driven multi computer things just the response times that people expect it gets in the way, process is too heavy, so it’s a pendulum that is swinging back and forth, before Unix, people they were doing some synchronous, some asynchronous, you never knew what you were doing, so I think all synchronous, all asynchronous, keep it straight, what idiom you are using. That’s why I say JavaScript is yet to really fully settle down on how it’s properly written. I think Java is way ahead on that regard. But then you’ve got the mavericks there, the Scalas and so forth that say “well, yes, but we can do better too’, and that’s pretty impressive stuff.
Werner: Smalltalk, I think, had this notion of lightweight threads for instance, which I guess is one idea of implementing sequential programming in a lightweight way.
I forgot exactly what it was called but basically there was some way you could reach up and grab your own stack and store it in an object and then you could have another stack do something. One of the coolest things was you could work on an application in Smalltalk and it could throw an exception and you could just look at it in the debugger and just “ah, I don’t care about that”, and throw it away, throw the runtime stack away and your application kept running because there was nothing in the stack that was particularly important, because it was all in the objects and that made it easy to layer on top of Smalltalk, a process model because inconsequential, “oh, yes, we have a process but if you want to throw it away, throw it away, nothing much, it will start back at the window”, windows were more important as a thing that did something than processes and that was educational, part of that was because Smalltalk existed before it had processes, but then when they added processes they said “well, let’s use processes to model simulation” and they said “here’s how to reach up and grab onto your own processes and manage them for the purpose of building a simulator” and so this is going full circle. Remember, I said to understand that computing can be thought of as a simulation and now here we are thinking of computing as simulation again, so the fact that it did that well said something about the clarity of abstraction in Smalltalk. Smalltalk I think has still the best abstractions for a single environment.
Smalltalk wanted to talk to itself, when I left Smalltalk I fell in love with Perl for a while because it wanted to talk to everybody “oh, the internet is here, everything, just rummage through this file hierarchy and send it over there where it will sort into some other file hierarchy and things go back and forth”, and Perl was good for that, you never knew what you got so you regex it for a while until you found something interesting. In fact that was a style that I adopted for Wiki, I said “well, let’s just read this text that the user types in, see if we can find something that looks like a heading or some italics, if you see a bunch of quotes or some italics in there somewhere” and it was pretty casual. Wikipedia suffers with that now because I followed that lead and discovered that “we can write one program that interprets this text, but we can’t write two, because it’s not all that clear, it’s defined by the program that interprets it”.
Of course, nature does that too, our genes are defined by the enzymes and proteins that interpret it, so if it’s good enough for life. And in fact, thinking about Barbara, we were talking about Barbara Liskov, gave an excellent keynote here at QCon, and of course I think of her as the objects that are specified and I thing of Smalltalk as the objects that work. Dan Ingalls described it as training animals, it felt like training dogs, you just keep asking them to do something and tweaking them until they kind of worked right, that’s not a specification, but you can train dogs, maybe we can train computers, maybe we can breed computers to do our bidding in the future, what will that mean?
Werner: Well, lots of cleaning up behind them.
That’s true.
Werner: So, in a way I think what Barbara Liskov did in the 70’s with her style of object orientation having data types...
Data types and you took a body of code and you put an interface on it and that interface had a specification. And then she reminds people that you know that in Java, of course, and she got the Turing award for recognizing that and naming that and describing how to think about that and push things forward. She also described that kind of community that worked in that and the Smalltalk community kind of came and met and I think that they get along, I describe it as more of a peace treaty than a unification, but again now we have ten other things that are demanding our attention so a peace treaty is good enough and then we pick and choose from all of that to build real systems.
I was pretty thoroughly in the dynamic camp so I don’t remember that too clearly, I think that I hung with a crowd that pretty much ignored that work, “ok, so we understand, great, but we don’t have the specs so let’s just carry on”, but then there are a lot of people “if you don’t have a spec, you’ll never know what you have”, and that’s true too. If you think about it, Agile in software development sort of says “let’s put a little less emphasis on spec and a little more emphasis on delighting our customer, if our customer is delighted who cares if we met the spec”. And that works for a certain class of software, there is another class of software where that’s wholly inappropriate.
Werner: It seems to be a dichotomy that is here to stay and there is a rift in the world that’s here to stay.
I think so, and of course it’s one of degrees, because if there are two poles then there’s an interesting space in the middle and some people have accused Agile developers of refusing to think and of course that’s not right, what you want to do is thinking continuously in little spurts of thinking and you’re slowing down or getting stuck you say “maybe we need to think a little harder” and be prepared to think, but the nice thing about it is if you’re doing this kind of sharing that we ask people to do in Agile then there is somebody to think with who knows what you are working on, you can have a conversation and that conversation doesn’t have to be rigid, like a code review where you do your best and then people tell you why that’s not good enough, but more like “I’m having a little trouble, help me do it really great”, that’s what Agile wants. And with that you get, I like to think, a lot of the processes to create an audience that appreciates your skills. And of course, part of that is you are an audience to appreciate other people’s skills and that’s how those skills really spread through the organization, raise the whole organization. It’s positive. I believe, and Barbara mentioned, software crisis, software was in crisis, software people aspired for software and software couldn’t deliver, developers couldn’t deliver, we could not deliver on the promise of software. And I think that has changed, I think we routinely deliver on the promise of software to the point where we are looking “give us a bigger challenge, let us do more, let us show what we can do” and every other department in the organization is a little stressed by that, “how can we get a little of that Agile over here”, and there is a lot of work going on right now in trying to figure out how to get everybody else working with the proficiency of software. It’s fantastic, what a difference from 25 years ago that people would look at the software development team as the model for how the rest of the organization behave as, so, there you go, nice work guys.
Werner: You already mentioned Wiki, and I think we can skip over Wiki because people know about Wiki
Yes, everybody can edit.
7. Is it true that for every Wiki edit that’s made you get 1 cent?
Wouldn’t that be nice?
Werner: So that’s not true.
No, but my name is in the dictionary and I am pretty proud of that.
Werner: Oh, that’s pretty good.
Yes. You look up Wiki and it says “programmer, Ward Cunningham”, if it’s a good dictionary. If it doesn’t have my name in it, look down the aisle for a different dictionary.
Werner: We’re in Britain, so it’s only OED.
I believe I am in the OED.
One of the challenges with Wiki is we expect everyone to get along, and if they don’t get along we kind of lean on them until they do get along. In Wikipedia this shows up as neutral point of view and arbitration committees and stuff like that and it’s kind of its own bureaucracy. That wasn’t really the model of the internet in the beginning and I subverted in a sense the model of the internet, which was a bunch of web servers and you pick and choose and write content in terms of each other, by saying “well, let’s just put everything in one database and then we’ll have internal links that stay within that database and we use regular links to go outside of it”. So, in federated Wiki I just reversed that model, well instead of having a database where everything is in a web interface, let’s put the coming together, the cooperating up above the web, let’s do that in the browser, not on the server. And the challenge there is to make something that feels a little more like a blogging editor, something you could go in and write content on your pages, but that your pages cooperate well with other pages and the sharing habits in the browser, and to do that of course you need a powerful browser, thank you browser manufacturers for giving us a powerful browser, and you need this ability in one page to reach out to multiple servers and that makes you look a little like spyware, so it’s “no, no, don’t do that” unless everybody says “no, no, cross origin, resource sharing is ok, we’re cool with this”, CORS it's called if you can do all that then you can read from everywhere.
So, what I’ve done was I said well, we are going to have a bigger space of conversation, big enough that we can have multiple points of views, big enough that I could rest between those points of views, maybe it’s a static specification people and the dynamic whatever works people, and we get some people in the middle that kind of take the best of both, that should be permissible or the third alternative nobody thought of, making a space where you could come up with a third approach. And I will say that the motivation for jumping into the Wiki game again was trying to find something where we could talk about our sustainable future. And if we are talking about our future, if we are going to be sustainable, you and I have to agree about how we are going to divvy up resources because we can’t all have what we want, there is no neutral position there, but there are positions that are workable and there are positions that aren’t, so my hope was that we could use real data to anchor our conversation and we would be talking about my interpretation of the data versus your interpretation of the data, back to this notion of interpretation again, but that we would use the Wiki environment, the sharing above the internet to find the communities that are creative enough to chart a course for the world going forward. And I think that the Wiki is powerful enough to do that, Wiki methodology I say, but the technology, if we are going to be allowed that diverse forward looking view has to allow people to organize content their own way. It’s exciting to be working in this area because it’s something that people haven’t actually asked for, so it’s hard to be Agile, I can’t just say “well, write down on a card what you want me to do today” because they would say “well, you’re not working on something I even understand”.
So, I have to figure it out myself, I have to figure out what is the principle I am trying to satisfy and is it a principle that is important in the future and then I build something and use it and see if it seems to work, because my ideal is to feel like a Wiki but to not have this limitation of a single database, and that’s been a real challenge, I’ve learnt a lot, I would say the program teaches me something, if not every day certainly every week. Every week I learn something new from the programming. I try to, I haven’t, but maybe every two or three weeks I’ll make a screencast and talk about what it has taught me and I thought I had enough stuff accumulated that it was worth showing up here at QCon and talking to some of the smartest people in the world and saying “let me show you where I am at, what do you think?”, and I hope it’s important I don’t know it’s important, I can’t prove it’s important, but it feels right to me.
9. Where can our readers and our listeners check it out, is it on GitHub or somewhere else?
It’s on GitHub, I try to make sure everything googles well, federated Wiki, I kind of own that term now on Google, and there’s also a lot of both Vimeo and YouTube videos, there is a page that collects, I think I have 22 of them now, it’s a little tedious to go through all of them, but none of them are very long and it’s really the history of the development. If you want to see where I am at, all the cool stuff, you can go at the bottom and watch them backwards. But, yes, screencasts have been good for me, and we also hold a Hangout regularly, a Google Hangout on Wednesday, here in UK it would be Wednesday evenings and it’s mentioned on GitHub and we enjoy really having other Wiki implementers come in and tell us how what we are doing relates to what they are doing and so forth, it’s kind of a community of maybe two or three people that are implementing on this new federated Wiki and people who are on other ones, we get people who have worked years on the semantic web, they have their checklist “it’s not semantic if you don’t do this and this and this” and I say “well, I think I do three out of four” and we talk about and “no, you do four, too”, I’ve gotten the seal of approval from at least one semantic web person. For me it’s interesting because it’s possible to develop software at a very high level by availing ourselves to the community, it’s available, I think GitHub is fabulous, I think the video going back and forth, we use Skype routinely, one on one pair programming on Skype, we do the Google Hangouts, the screencasting, all of that stuff makes it easy to communicate the stuff that doesn’t show up in the code and then we still make that code as clean and as informative as possible.
Werner: That’s a lot to check out, definitely very interesting, and thank you, Ward!
Well, thank you!