James Gosling, often referred to as “Dr. Java”, is a Canadian computer scientist, best known as the father of the Java programming language.
Join the DZone community and get the full member experience. James Gosling, often referred to as “Dr. Java”, is a Canadian computer scientist, best known as the father of the Java programming language. He did the original design of Java and implemented its original compiler and virtual machine. Our DevRel, Grigory Petrov, had the opportunity to interview James, and we have included the entire transcript below. Hope you enjoy it! Grigory: As software developers and software consultants, we’re trying to organize a community in Russia: Python, Ruby, Java, and Go communities. And we want to help our fellow developers by conducting interviews that highlight essential questions for our industry. I think that your experience and your work on Java can help developers to become better. So let’s try to help them! Some languages, like Go, leave out classes and inheritance, while others experiment with features like traits in Rust. As a language designer, what do you think is a modern, general-purpose, reasonable way for a programming language to do composition? James: I don’t think I wouldn’t do classes. I actually find that classes work pretty well for composition. I don’t really have any good, clear ideas for what to do differently. And some of the things that I would do differently are a little strange. In C, there are macros, which are pretty much a disaster because the macros are not part of the language; they’re kind of outside of it. The folks at Rust tried to do a decent job of fitting macros in the language. Other languages, like all of the Lisp family, managed to fit them in more gracefully, but they had a way of defining syntax where the syntax was almost entirely free of semantics. And in most languages, syntax and semantics kind of go hand in hand. As somebody who has written a lot of Lisps in a past life, I am really addicted to the technique of using Lisp programs to manipulate Lisp programs. That’s one thing that I really, really miss. Some languages let you do that in different ways, so like in Groovy, you can directly play with the AST. And Rust has some sort of syntactically integrated macros. But it’s always felt to me like there’s an interesting research question in there: can you do more? Can I get the feel of Lisp doing computations on code fragments to generate new code? And in the Java world, people do that. It’s one of the more popular features, except that it’s really low level. Because people use a combination of annotations and the fact that you can generate bytecodes with some of the different languages. That is super powerful. It gets used in places like you wouldn’t expect, like in Jackson. It gets a lot of its performance by computing the serializer. On one hand, it’s a very powerful technique. On the other hand, it’s just super hard to use. The fact that it’s possible is great. But how far can you go? They can be kind of limited. So if you look at something like Lombok, it’s one of the things that I find to be… well, I have a strong love-hate for it. Because it adds a bunch of Java features that are pretty nice, but on the other hand, it shows weakness. Partly in the process, as this is a set of features that should be just built-in. And the Java Community Process has become somewhat less community than it should be. I’m on the outside these days and have been for quite a few years, but there are things you could do that are just all over the map. Grigory: That’s why we prepared questions about your fantastic experience with creating languages, and not some modern Java enhancement proposal. Five years ago, I can confess, I manipulated some Java bytecode. For good, of course, but creating domain-specific languages out of it is kind of tricky. With Ruby, it’s much easier. We at Evrone are proficient with Ruby, we have dozens of Ruby developers. And Ruby developers are great, but they require lots and lots of years of training to learn all the DSL magic. James: One of the things with features like computing code fragments, the reason why it’s awkward in Java, is that Java tries to go all the way to compiled machine code. And Ruby is pretty much always interpreted. When you’re doing that, when you’re not trying to get all the performance that you can, then life is easy. But if you’re trying to get both powerful features and ultimate performance, life becomes much harder. Grigory: Recently, we interviewed Yukihiro Matsumoto, the author of Ruby, and he mentioned that he had performed an experiment with his latest major Ruby 3.0 version. He tried to release this version without breaking changes to see what would happen. A major language version that doesn’t break anything. I know that Java is cautious about not breaking things. Is it a good idea for all the languages to evolve without incompatibilities? Or is it a limited approach that can be used only for specific languages, like Ruby or Java? James: It is almost entirely a function of the size of the developer community. Every breaking change induces pain in the developer community. If you don’t have many developers, then breaking changes aren’t a big problem. And you also have to think about the cost-benefit tradeoff. If you do a breaking change, it adds some pain, but it also brings some benefit. For example, if you change the subscript operator from square brackets to round brackets, it probably buys you absolutely nothing and induces terrific pain. That would be a dumb idea. In JDK 9, there was a change, one of the very few breaking changes that were ever introduced, and what it broke was: if you’re using some of the supposedly hidden APIs, the encapsulation mechanism gets scrambled, and people who were breaking encapsulation boundaries and using things that shouldn’t be used in ways that shouldn’t be used, they had some pain moving from 8 to 9. But once we get beyond that, it allows the platform a lot more freedom to innovate. And in this particular case of 8 to 9 transition, it means that the platform can be sliced and diced, and you can actually make custom packaging so that the Java Runtime Environment will be smaller. One other area where there is always a fair amount of discomfort is: when there’s a bug in something, and people do workarounds for the bug, if you fix the bug, you may break the workarounds. There have certainly been instances in the Java world where we decided either not to fix bugs or introduced a method that does the correct thing. That even shows up in hardware. There’s an issue with sin and cos, they were slightly incorrect, so you have to have correct and incorrect instructions. Grigory: Twenty-five years ago, when I started my own career as a software developer, I wrote a lot of C and C++ code. And I remember these mysterious pointer bugs that happened once a month. Debugging such bugs was a pain. But now, as a software developer, I see lots of tools integrated into our workflow, like static type checkers. Modern developers use IDEs, like NetBeans, IntelliJ IDEA, or even Visual Studio Code. They write the source code, and a static type checker parses the program, constructs an abstract syntax tree, and checks everything it can. And then possible errors are highlighted right within a text editor. And such tricks are available, not only for statically-typed languages, but even dynamically-typed languages, like Python, Ruby, and TypeScript. What is your opinion on these static type checkers we use today? Are they a step forward to writing better software, or do we need to put more inside the language syntax? James: Well, both. I’m a big fan of languages with static type systems because they provide a scaffolding for the static type checkers and IDEs to work. I spent most of my life as a software engineer, and the least satisfying way for me to spend my time is hunting down obscure bugs that happen at weird times. And anything I can do to make bugs disappear before they waste my time is a good thing. So, I’m a big fan of just about anything that IDE can do to reduce the probability of a bug. So when we look at the dynamically-typed languages like JavaScript and Python, they have less of an inference framework to work that out because they don’t necessarily know what the type of anything is; they’re just kind of guessing. Strongly-typed languages, like Java, provide a much more rigorous framework for the type checkers to use. And, going up another level, there are things that do full auto theorem proving. So there are systems like Dafny, which has a really sophisticated theorem prover. So if you want to build an encryption algorithm, you will be able to mathematically prove properties. You can do that. That may be a little too far, but for some code, it’s really useful. And a lot depends on what your goal really is. If you’re a university student and you’re trying to get your assignment done, or you’re a Ph.
