1. [...] Can you tell us a little bit about the title of your talk and summarize it?
Barry's full question: I am Barry Burd, professor of computer science and mathematics at Drew University in Madison, New Jersey. I am here at QCon New York talking with Gilad Bracha. He works at Google and he is currently working on Dart. He is best known as the co-author of the Java language specification. Gilad, your keynote today was called “Whither web programming”. Can you tell us a little bit about the title of your talk and summarize it?
Sure. The title was a bit of a pun which I am sure nobody got which is the way I like my puns to be. Basically, the point is where is the web going or where it should go in the future and also the idea that there is a risk if it does not address these issues that it might not be as dominant or as popular as it should be as a programming platform in particular because of competition from app stores and things like that which have certain advantages, in particular with respect to the ability to reliably install an application. So, the web has this great advantage of zero install, but it actually does not have a way to reliably ensure that that application is there for you offline or when the network is slow or unreliable, etc, which is an added feature as it were that is one of the weaknesses that I was talking about.
I guess the best – let’s start with the best – the best case scenario is that a series of missing primitives that would allow a great variety of programming languages to be implemented efficiently on the web, get standardized and put into all the browsers in a relatively quick manner. I mean it is a standard process and it does take time. There already is this flowering of all kinds of programming paradigms on the web and I think that is a good thing. I think that mono-lingual platforms either become multi-lingual or they die. Look at the JVM, for example. If we do that, then the web will evolve into something where you really have this ideal combination of the advantages of the network and the advantages of an independent client. So, things will work for you online and offline, your apps will synchronize transparently for you, wherever you go, for multiple devices, your data will synchronize transparently with collaboration and so forth. All these things that the network can enable will work well on the web, in an open fashion, in a standardized fashion. That is what we'd really like to see happening.
The worst case scenario is that none of these things happen and instead you see developer energy focused more on mobile platforms and you get more of these walled garden kind of things like iOS frankly where your ability to innovate is limited but in some sense there are better primitives and they actually become more competitive with the web.
Well, the biggest thing that I addressed is this idea of being able to reliable store a program on the client. So, what happens today is that you, in principle, on the web you download every time. That is why it is zero install, there is no barrier of installation, it just runs. That is great. But that also means that you pay the price of download repeatedly. Now, some of this is addressed with caches and stuff, but this is not really something you can bank on. It does not necessarily work very well if you are offline or it is just hard to predict what it will do. And even if it is cached, there is this issue of parsing the code, so if you have a large application, and what we are trying to get is large, sophisticated applications, not just toy pages, then you find that there is a real cost to that, in terms of startup time and so forth that you are trying to get away from. So, being able to reliably say explicitly that I, the user or the application, want to store this on my client so that it will be there for me in this form, is something that is really, really missing.
Barry: I assume that what you are saying is that there are ways of doing it right now but that they are not standardized. We do not have the tools.
There aren’t ways of doing this right now. I mean, AppCache is very hard to bank in a any reliable way on the fact that something will be cached. There simply isn’t a way of doing that right now. There are other things, among other primitives, there are things that programming languages that are not semantically very close to Javascript, that have different features that are simply hard to implement on top of Javascript and there is often a way of doing it, but it is expensive and costly and sometimes impractical and certainly debilitating to whatever technology you are trying to do because you can do it, but it is not performant.
4. What do we need in order to fix some of these problems?
We need those things standardized by the standards committees, particularly TC 39 which is the committee that is doing Javascript, we need integer, we need weak references, we need some reliable way of accessing the stack in some way which has to be at once secure but flexible so that you can build things like continuations or debuggers or serializing your thread, etcetera, in an effective way. If your language calls for that, tail recursion. A whole bunch of things that are very, very hard to do if you do not have good support in the underlying platform because doing it on top of Javascript, which is a language that has its own semantics and its own high level features is just too costly.
I think for the most part, yes. I mean, de facto, they have to because there is one engine in the browser that they compile to and obviously, there is a way of defining something that works, right? Von Neumann defined the architecture that has worked rather well, that the basic machine code of whatever machine lets you do all these things fairly effectively and the underlying machines can do it very effectively, but when you are programming to the internet platform, between you and the machine there is this abstraction which is essentially Javascript, which does not have - in some ways it is much easier, it is a higher level paradigm, but also it does not have effective ways of implementing some of these things.
Barry: Let me get technical for a minute here. You mentioned something during your talk and then in your last response – weak references. I would like to find out a little bit more about that.
Basically, in a garbage-collected language, the idea is that memory is managed by the implementation and if you have a need for data and you allocate that it is going to be there. If there is any live reference, where you have a set of roots and basically, anything that is reachable from there is retained and something that is not reachable because basically it is an object which you no longer retain a reference to is detected by this implementation, the garbage collector, and it throws it away. Now, the problem is that sometimes you have structures where you want to retain them only if someone else is retaining them. Right? So, the example I gave in my talk was a list of classes which my implementation needs to track because it needs to be able to modify them in response to user changes, but I only want to retain those classes if the user’s code itself retains them. I do not want my data structure to force that thing to be retained and therefore cause a memory leak. There are all kinds of scenarios like that which is why people invented this idea of weak references that most garbage-collective languages support in some form, which are references through which you can reach this data, but they will not force the garbage collector to retain it, if no one else retains it. They will get collected and that is a primitive that is missing in Javascript.
Sure. It was - I would not say it was a random sample, but I chose a few that were interesting largely because there are some common themes there – this idea of live programming which is finally catching on, after decades in the wilderness, as it were. Systems did this in the Lisp world, in the Smalltalk world decades ago. Basically, it gives you much better interactive feedback as a programmer. The changes that you make to your program have immediate effect on your running program, rather than going through a build cycle and so forth, which, if you experience this thing, it is a very powerful thing and it makes programming a real joy. So, I showed several of these. I showed some work of my own on Dart, which is a project that I am working on at Google along with a large team of other people, obviously and Newspeak was a project that I have worked on in the past and still do, as an open source kind of thing. I also showed a couple of others that are less well-known in some cases, but illustrated other points and they all had in common a) this liveness thing and b) the fact that they face unnecessary obstacles, it is harder to implement these, in some cases much harder to implement them than it should be because of those missing primitives that we have been talking about all along.
Oh, it is very much a general purpose idea. Of course, it does not originate with web programming, it originates essentially where much of modern computing originates, in Xerox PARC in the 70’s, along with the Ethernet and GUIs and popup menus and many other things that we take for granted today. Some of the things that we did not get, that were not adopted, were some of the programming technologies that had made it possible, which is basically about shortening the feedback loop so you can see what the effect of your abstraction is very quickly and therefore make progress more quickly because it is just a shorter loop and that is true of all programming.
Barry: I also saw a lot about functional programming.
There was a fair amount. Functional programming has advantages and disadvantages and I have spoken about that at QCon before and I thought that what is good about the web is making more of these things more accessible to people because you can just go to this web site and experiment with something and so forth. The things that I used to show functional programming were a little unusual in the sense that they are not the usual academic thing because I think academics, as a rule, miss the point. In this case – this was functional programming being used in a context where it was particularly applicable. So Elm is a language for UI where UIs are naturally structured in a way that you can introduce them declaratively and you just say “This is how my UI is”. So, it is natural to specify them with a bunch of dependencies in a functional program. So, Elm gives you a live environment for doing that and that is a very nice thing and that is a different emphasis than much, not all, but much of the academic work on functional programming. Obviously it is based on academic work, functional reactive programming and so forth, but it has actually succeeded in making it real which is a great thing.
I think that is very much part of – that is one point and it is certainly one of the points of Elm, but I think that on the web it is very limited what can be done because again, the concurrency primitives are not there. You do not necessarily have very good access to the underlying capabilities of the platform in the web browser. You have to work with web workers, it is all awkward and painful and restrictive and I imagine this will get fixed over time. I hope so.
9. [...] How do you see Dart and Javascript fitting in the world together?
Barry's full question: Now, you said something during your talk about Dart and Javascript and I guess it is a good time for me to ask you to clarify, because there is a lot of talk about the relationship between Dart and Javascript, either as a replacement or not as a replacement or as a this or as a that. Can you give us the word? How do you see Dart and Javascript fitting in the world together?
So, this idea of a replacement for Javascript – personally, as an ideal, I would love to replace Javascript because it has many, many problems, but no one is realistically proposing that because we are not that stupid. The issue is that it is important is to give people alternatives, right? Again, this idea of a monoculture, one programming language to rule them all is a non-starter. So, having options, giving developers a viable choice, something that really works, that is well engineered enough to be used in industry is really what Dart is about. So, in reality Dart compiles to Javascript so that makes our life miserable, but we do it anyway because that is the way, the only realistic way, to get it out there because Javascript is in every browser and will be in the foreseeable future. On the other hand, we do not expect to get rid of Javascript, we just expect that people will have the option, if they want to, not to have to use it directly and they will be better off for it.
Barry's full question: I guess one of the difficulties with multi-lingual programming on the web is that the browser has to support any language that comes along. So, right now Javascript is one of the things that is supported by almost every browser. It makes it a compelling case to write either in Javascript or to compile to Javascript. Am I correct in saying this?
Yes. Certainly, it forces you to do one of those two things. You really have absolutely no other option. Now, writing in Javascript is distasteful to many people for many reasons. It is not, in my opinion, a language that humans should really be programming in. On the other hand, compiling to Javascript is fine, if it just supported a few more primitives, if the focus essentially was on making it a sort of assembly language for the web so that many different paradigms could be compiled to it, as opposed to making it a language for humans to program which, no matter how much you patch it, it never will be a great language for that purpose. So, yes, we expect that and just as a machine code is something that everyone has to compile to on ordinary machines, everyone has to compile to Javascript. Possibly, they will be able to compile to Dart as well because we hope to get Dart into browsers as well but, obviously we cannot have every language in the world have its own virtual machine in the browser. But, what is in the browser should be a good compilation target.
Barry's full question: I want to switch gears for a minute here because, as a writer myself, I want to ask you – you are an author of the Java language specification and writing a language spec is one of the most rigorous and intensive jobs that a technical writer can take on. Do you have any particular tips for tech writing? What are your guidelines? What are your great secrets?
I do not know that I have any tips or secrets. First of all, I do not regard this as a job for a tech writer, honestly, because tech writers have to be generalists, they have to describe all kinds of systems that usually are not described well by their authors because the engineers do not like writing documentation. Now, because writing language specs is extremely technical, I do not think tech writers are usually equipped to do it and that is why language authors and language developers have to do it themselves for better or worse. There are people saying that it should be written in some sort of formal specification language – the problem with that is that the compiler writers will not read it and it is actually important to have wiggle room in these things, as a practical matter so natural language is the way to go, in my opinion, for these specs and you just have to know what you are talking about. They are not really necessarily easy to read because they are relatively technical and rigorous, but I cannot really tell people how to do it. I just do it.
12. And why is it important to have wiggle room, you say
It is important to have wiggle room for the same reason that a legal system has wiggle room because it turns out that no matter what you specify, in the end, for example, there will be bugs that will become features. If it is implemented this way and it is out there, you find that you cannot necessarily force the implementation to conform to the spec, you may want to rather misunderstand the spec the way the compiler writer misunderstood it. Just to take one example: if you make things too precise, you might get them precise and yet wrong and you are going to have to change them anyway. So, it is important to have wiggle room.
13. Can you summarize then your vision for the future of the web and the web applications?
Well, I think we want a world where applications can work online and offline as much as their functionality allows. Obviously, if you are accessing some giant database, you may need real access to the network. Or if you are communicating, obviously there is nothing that can be done. But there are many applications where it is plausible to store your data and the application locally and it will work for you offline and I think the platform should make it easy for you to do that. You should be able to synchronize when you are back online and synchronize your application and your data and again, it should happen in a very lightweight fashion, it should be handled as much as possible by the platform so that developers do not have to solve this rather hard problem over and over again. It should produce an experience that is as good or better than any native application does.
Barry: All right. Thank you so much for being here.
Thank you.