Bio Gilad Bracha is the creator of the Newspeak programming language and a software engineer at Google where he works on Dart. Previously, he was a VP at SAP Labs, a Distinguished Engineer at Cadence, and a Computational Theologist and Distinguished Engineer at Sun. He is co-author of the Java Language Specification, and a researcher in the area of object-oriented programming languages.
Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
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.
3. You used the word “primitives” a few times and I also heard a few words suggesting certain things that I think you were maybe referring to as primitives. Can you elaborate? What is it exactly now that we need that has to be built in, that we do not already have?
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.
5. Is it possible to set up these standards so that all of the languages, the many different languages that we use on the web can all subscribe or can mostly or for the most part subscribe to these standards?
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.
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.
7. Live programming – in other words, you would not only be able to preview but actually to see the programming in action while you are developing it. Is that something that is especially good for web programming or is it simply a good idea in general, for general purpose programming?
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.
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.
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.
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.