“Working on Projects That Combine Book and Interactive”: Kay Horstmann on Books and More

There are a huge number of books about Java - and there are several "those" books about Java. These include Core Java (in the Russian edition of Java. Professional Library) by Kay Horstmann and Gary Cornell. It appeared only a year later than the language itself, immediately becoming one of the main sources of information on the topic. And over the next twenty years, it has withstood ten editions, scrupulously replenished with information about new versions of Java, so that more than one generation of Java developers has grown on it.

Kay is still closely following Java innovations, and in the fall at the St. Petersburg conference, Joker will tellthat in java 9 good. And in anticipation of his arrival, we asked him about many things: both about working on books, and whether online courses can supplant them, and about the differences between the academic world and the industry, and about the future of Java.

- The fact that "Core Java" has become very famous and significant, somehow affects the work on it? For example, do you feel that you need to do fact checking more thoroughly than other authors?

- Thanks for the kind words about “Core Java”. I hope that each author is engaged in fact checking properly, and I know for sure that this is so for many. But when “Core Java” came out for the first time, several books competed with it, simply repeating the API documentation, and the documentation was not always correct then. We discovered this when we wrote small but realistic programs (and not just “toy” examples) that put the API into action. Now it’s hard to imagine how complicated this was: stackoverflow.com wasn’t yet, and access to the Java source code was limited.

Some books, such as “Java Concurrency in Practice”, are written by such eminent experts that you can take what you have said for granted without code examples. But let's admit that many books have to be written in a hurry when a new technology develops. And in this case, it is very important that the authors provide good examples. When I see a book where the classes have animal names, and the methods display “Woof” and “Meow,” I don't like it. I want to see the code in a realistic context. For me, the standard is the classic Kernigan and Ritchie book on C, in which almost every snippet could be from a work program.

When “Core Java” was first published, and it was said that many things in the Java API do not work correctly or are inconvenient for a programmer, they shouted at my editor at Sun Microsystems. But I think it really helped the reputation of the book. Now that I'm working on a Java SE 9 edition, I'm still trying to explain what works well and what doesn't. Fortunately, no one else yells at my editor.

- Work on one book for decades - what is it? Does “Legacy” arise when some fragment seems outdated, but it is simply impossible to “take and throw out”? Does updating a book look like code refactoring? And did something written years ago evoke a feeling of “what stupid thing I wrote”?

- A very good question. When I started writing this book, I was both the author of textbooks and the developer, and it was natural for me to think not just about one version, but immediately about subsequent ones. The book was designed to grow with the language and with the API. But we ourselves were just as amazed as everyone when the API grew by leaps and bounds and Core Java turned into two thick volumes.

And yes, the work on the new edition feels like refactoring. In many cases, the new way of doing something makes other approaches obsolete, and I need to deal with hundreds of sample code. I like to use new features in all examples where they are suitable, so that readers are not confused by a mixture of old and new. A simple case is a diamond operator, it was just required to find expressions of the form "new ... <...> (...)" there. But when lambda expressions were added, I had to rewrite more than half of the sample programs, sometimes reorganizing them a lot.

We didn’t want Core Java to grow to three volumes, so in every edition some things are deleted. Among these are information about bugs in old versions that no one cares about anymore, “workarounds” that are outdated due to improvements in the language, and large-scale “mowing” of the API. Once upon a time we had a very detailed description of CORBA, and getting rid of it was a pretty easy solution. When the RMI description was deleted, some readers were upset, but listen, when was the last time someone used this in a non-toy example? And now the following difficult decision is being selected: what to do with Swing?

Sometimes a technical error makes its way into the text, and I keep a list of the errors I noticed, so that readers can report them. I take these “bug reports” very seriously so that errors do not live longer than one publication. Fortunately, the situation “how stupid I was” arises infrequently, but sometimes my point of view develops over time. For example, when nested classes appeared, I explained in great detail how the capture of local variables worked, citing decompilation results via javap. Later I thought about it. Did I explain in the same detail, for example, how the method call works technically? No, and readers did not require such details. In practice, programmers are fully prepared to trust the compiler in that it is able to deal with both method invocation and local variable capture, so I removed the useless details.

Another hassle is the growth of information related to a particular version. "If you have Java 6 (poor thing), you can do this since Java 7, you can do that, and in Java 9 you almost achieve nirvana, because now you can do something else." In Core Java for the Impatient, I simply explain how the latest version of Java works by imagining a programmer who already owns, for example, JavaScript. It is very refreshing. But, of course, many users are forced to deal with different versions, so the classic "Core Java" will still take this into account.

- While some books appeal to a narrow audience, Core Java is opened by a variety of people who have very different knowledge and experience. Do you have difficulty writing “for everyone”? What helps to cope with them?

- There are difficulties, and it is inevitable that you cannot expect an understanding of all advanced material from a beginner reader. I expect that a reader who is only learning object-oriented programming will carefully understand inheritance and interfaces, and will only glance at reflection or modules, while the expert will do the opposite. With chapters about the API, it’s easier for readers to skip chapters that don’t interest them.

Nowadays, few people read a book on programming from cover to cover. Many of my readers use Safari Books, where they simply open pages dedicated to a specific topic. And I structured the books of the Impatient series so that the material was easily understood in this form, without constant references to other places in the same book.

- When you write about Java for many years and go into details, does it feel like “how much has been done in Java completely wrong”? Have you tried to improve something?

- Of course, when it comes to such a large and complex platform as Java, there are many things with which something is wrong. But only in rare cases is something terribly wrong: for example, the existence of primitive types, which should have been an internal affair of a virtual machine. (And I hope that in the future, a new version of Java will fix this.)

But, of course, there are many small annoying factors. For example, why did it take twenty years for the API to give us a method to read a stream into a byte array? Why is the Unicode API so nasty? I could name dozens of others.

Unfortunately, they are not so easy to fix. In other open source projects, someone would simply propose something better, a discussion could arise, a revision would take place, and then the changes would be accepted if there were no sharp objections. And in the case of Java, the exact opposite. Resources are needed to actively promote any change and to go through the regulatory structure. Of course, this is useful, it means that your Java 1.0 program has excellent chances to successfully compile. But it also scares everyone away from any changes.

As an example: I once suggested that you need the ability to run a program by calling the constructor (with the String [] parameter or without arguments) of the class specified on the command line if this class does not contain the main method. I even implemented it - the startup code in VM is not that complicated. Why did I even care about that? Because it would be manna from heaven for students and teachers who would not have to deal with public static void main in the very first lecture. “Hello, World!” Would look like this:

public class Greeter
{
   public Greeter()
   {
      System.out.println("Hello, World!");
   }
}

A second trial program could immediately dive into objects without worrying about “static”.

There was no risk of backward compatibility errors, because previously such a class simply could not be started.

Was my humble offer approved? Not at all. It was rejected as "too complex" and "capable of threatening backward compatibility."

But be that as it may, over time, many annoying features of the API are fixed. Perhaps due to the fact that people in Oracle, they annoy the same way as us.

Also, let's not forget how much we are spoiled by the quality of the Java API. I saw many APIs in JavaScript, Python, and C ++ that made me scratch my head and wonder why anyone could design an API like this.

- Have you heard from Java developers that your books not only taught them Java, but also influenced their programming style?

- No, I haven’t heard this from readers. Perhaps they leave such thoughts to themselves :-) But more seriously, I usually do not persuade you to use a specific style. I'm always a little annoyed when other authors tell me that I am doing something wrong, so I try not to do the same. For example, I am not telling readers that they should be less object-oriented and more functional, or more reactive, or something else. I present the benefits of different approaches, and leave readers the opportunity to choose.

There is an exception. I wrote a book on Scala, where I have a fairly clear point of view: the look of a Java programmer who does not want to give up his object-orientedness and switch to pure functional programming. Those readers who share my point of view liked it. Those who do not share - not really.

This is the danger of a book with a personal opinion. If it is not so true and convincing that it becomes the majority opinion, then you limit your own audience. In the case of Core Java books, I tell the reader how to use Java effectively, but apart from this, I don’t preach any specific methodologies.


- You have a quote in the memorable quotes section that teaches Herbert Schildt. Since your Java books are competing, I want to know - is this just a joke, or are you competing? :)

- With the Coat of Arms - no. I have never met him. I don’t even know if it exists. Maybe this is the code name for the artificial intelligence program. Just kidding, Coat of arms :-) I just liked the quote.

My editor once said that he could not believe that I shook hands with the author of a competing book. I look at it differently. There are authors whom I admire, but there are also those whose style I would not adopt. But other people buy and apparently love their books, so I communicate with them, learning more about their approaches and their readers.

And besides this, not everyone buys a book or watches a video because he wants to get knowledge. Some prefer, and some authors provide, the illusion of knowledge.

- You participated in the creation of the Intro to Java Programming course on Udacity. Do you feel that the future of programming learning is for online courses? Are books becoming less relevant? What would you recommend first of all to a person who wants to become a developer: a book or MOOC?

- This is also a great question. When I took up the MOOC course, which happened as part of a collaboration between my university and Udacity, they told me: “You don’t know anything, we will teach you how to teach.” And they taught me useful techniques. Limit video segments to three minutes. Do not give an answer, but ask a question. Make everything visual. From the point of view of the “first steps for a person who wants to become a developer” I really like the result.

But Udacity also said: “You cannot require students to read a book. Even individual pages. ” And the students hated it. They were annoyed by the need to revise the video just to find any specific information.

So if I had to choose between a video course (whether MOOC or not) and a book, I would always choose a book. But now I am working on projects where these two parts are combined: the interactive part for the first contact, and the book for a deeper understanding and as a reference. Perhaps this is where the world goes.

MOOCs can be great if you don't just watch a video. If they are equipped with serious interactive material that makes you act, think and learn, and if you actually act, think and learn, they can be very effective. But if you just click on the video and print out the certificate, then this is an illusion of knowledge.

- You have experience in universities and startups, that is, you are familiar with the academic world and industry. What is it like to switch between these contexts? How far are these two worlds from each other?

- Here lies a widespread misunderstanding. Students often ask something like: “Why do I need to learn the theory of automata? What I really need is an AngularJS course. ”

I do not argue that if a student needs AngularJS for a specific project, then he should learn AngularJS. But as a university course ??? The university is good for teaching things that will continue to be relevant after 20 years. And teach to learn. So after 20 years, when a former student will need to learn the XYZ framework, he will have a background and skills to quickly master it on his own.

Some people think that universities go too far with teaching useless material, and they lack flexibility with their four-year programs. That's why all these “hacker academies" and "nanodegree" appear. I myself have come up with some ways to upgrade the curriculum in computer science, and I also admit that some of these methods will not be implemented due to institutional barriers. But non-traditional educational programs go to the other extreme, without providing enough fundamental knowledge. They also differ from universities in another respect: they need to focus only on the most motivated people who can fill many gaps on their own.

Another big difference between a university and work in industry is that academic research focuses on originality, and work in industry focuses on repeatability. Universities have little appreciation for the quality of code, with the exception of people who study software engineering. Perhaps the universities are too focused on original research. A couple of years ago I worked in a small Swiss educational institution, where faculties were awarded for working with local companies. It seemed like a good idea to me.

- And because of the difference between the two worlds, it doesn’t turn out that successful ideas from the academic world that could be useful in the industry simply do not get there?

“I don’t know if it is happening so that many academic works with applied benefits are missed in the industry.” Many software companies have employees with advanced degrees who are very familiar with research literature.

For example, look at unmanned vehicles. It started at universities, and then pretty organically moved into industry.

Or, in the world of programming languages, look at garbage collection. This has been a research topic for years, but when it became suitable for an industrial setting, it was quickly adopted. So I don’t really worry about the priceless intellectual secrets hidden in the ivory tower.

- You taught CS all over the world - in the USA, Switzerland, Vietnam and Macau. What caused this scatter?

“I just like traveling.”

- And from the point of view of your work, was there any significant difference between these countries, or computer science, and Macau's computer science?

“It's the same everywhere.” Everywhere I had outstanding students, and not too outstanding. Well, Vietnamese students were not accustomed to rely on their own judgment. They constantly asked me the smallest questions about how they should act, and I constantly answered that they are very smart (they really were like that, they were selected from 1% according to the results of the school exam), and they need to form their own opinion. I think this taught them more than any technical information that I gave in my lectures.

I think that we in computer science are quite lucky with a field in which achievements can be evaluated fairly objectively, and people from different places successfully collaborate. When they say about Silicon Valley that there is a meritocracy, this is to some extent true. Of course, only in a certain way - we all heard stories of people who were not given an equal opportunity to prove themselves as a programmer. But in computer science this is much better than in other areas where people get the main money from one party.

- Wikipedia states that for several years you used your own indentation style in books, and then abandoned it. Why did they start and why did they stop?

- The story is like that. In the case of C, we have the K&R style and the Olman style:

if (args > 0) {
    printf(args[0]);
}

and

if (args > 0)
{
    printf("%s\n", args[0]);
}

What do we want - to save space, or align curly braces? But what if we want both this and the other at once? This is where Horstmann's style comes into play:

if (args > 0)
{	printf("%s\n", args[0]);
}

People did not like him. There was no apparent rational reason for this; writing so simply seemed strange. In the end, I gave up, because the style did not have support from tuning. The game was not worth the candle.

- Recently at Stanford they changed their introductory course in CS, deciding to use JavaScript instead of Java. What do you think about it?

- An introductory course in computer science is not really a course in a particular language (in any case, it should not be). Difficulties for students arise with loops and arrays, with algorithms, decomposition and debugging. Regardless of whether you use Java, C ++, Python or JavaScript, students are more likely to get stuck on a loop than on public static void main or on the counterintuitive features of JavaScript.

So it doesn’t really matter which language to use, unless the course itself focuses on it. I saw courses with C ++ that bothered students with details about pointers, and this did not contribute to the process. And Stanford has always had a first-class course, with JavaScript they can make it no worse than with Java - but, I think, no better.

- You have been writing about Java for decades and have seen how things have changed over time. What do you think of the future of Java? She has passed its peak and will slowly lose in popularity? Or is it still ahead, and young JVM languages ​​like Scala and Kotlin will help the whole ecosystem?

- Shortly after the advent of Java, during its rapid take-off, there was a very clear feeling that Java would be the "end of the story." From a tiny smart card to a powerful server, Java has come to command them all.

Now we know that it turned out completely wrong. Java is rooted in servers, but now Node.js. is breathing in the back of her head. Not for any technical reasons, but because the full-stack developers do not want to write the client side in JavaScript, but the server side in Java. Given that Java UIs are rare today, this is a problem. If I were the king of Java, I would make sure that Java remains the language for Android, and also promoted Java-to-JavaScript technology for browsers. But it’s obvious that I am not the king of Java.

I also see a lot of enthusiasm around Python in areas like data science. There is no reason why the corresponding libraries could not be written in Java, but they were not written in it. And they don’t write to Kotlin either. Scala has its own notable territories, especially Spark.

My prediction is very boring. I think we will see how C / C ++ will continue to lose ground, Python and JavaScript will grow, and new nice languages ​​(both in the JVM and not only) will declare themselves, but not achieve the same popularity. And year after year, the technical press will be surprised that Java is still very popular, although for years it has been hailed as losing popularity.

---

At the Joker conference , which will be held in St. Petersburg on November 3-4, Kay will give two presentations: “Java 9: ​​the good parts (not modules)” and “Concurrency for humans”.

And although there are still a few months left, tomorrow (August 1) Joker tickets will go up in price - so it makes sense to buy them today.