“I work on projects that integrate a book and an interactive”: Kay Horstmann about books and not only

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

Kay is still closely following the innovations of Java, and in the fall at the St. Petersburg conference Joker will tell you that Java 9 is good. And in anticipation of his arrival, we asked him a lot: about the work on books, and whether online courses could force them out, and about the differences between the academic world and the industry, and about the future of Java.

- Does the fact that Core Java has become very famous and significant somehow influence the work on it? For example, do you feel that factbooking needs to be done more carefully than other authors?

- Thank you for your kind words about Core Java. I hope that every author is engaged in fact-tracking properly, and I know for sure about many that this is so. But when Core Java came out for the first time, several books made up the competition for it, simply repeating the API documentation, and the documentation was not always correct. We discovered this when we wrote small but realistic programs (and not just “toy” examples) that allowed the API to work. Now it’s hard to imagine how complicated it all was: stackoverflow.com did not yet exist, and access to the Java source code was limited.
')
Some books, like “Java Concurrency in Practice”, are written by such outstanding experts that they can be taken 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 classes have animal names, and the methods output “Woof” and “Meow,” I do not like it. I want to see the code in a realistic context. For me, the benchmark is a classic book by Kernighan and Ritchie in 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 did not work correctly or were inconvenient for a programmer, they yelled at my editor at Sun Microsystems. But I think it helped the book’s reputation. Now, when I'm working on a publication timed with Java SE 9, I'm still trying to explain what works well and what doesn't. Fortunately, no one else screams at my editor.

- Working on one book for decades - what is it like? Does “legacy” arise when some fragment feels obsolete, but it is impossible to simply “pick up and throw out”? Does book update look like refactoring code? And did something written years ago cause a feeling of “what nonsense I wrote”?

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

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

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

Sometimes a technical error is sneaked into the text, and I keep a list of the errors I have noticed, so that readers can report them. I very seriously approach these "bug-reports" so that mistakes do not live longer than one edition. Fortunately, the situation “how stupid I was” doesn’t occur often, but sometimes my point of view evolves over time. For example, when nested classes appeared, I explained in great detail how the capture of local variables worked, citing the results of decompiling through javap. Later, I thought about it. Did I explain in the same detail, for example, how does the method call technically work? 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 the call method and with the capture of local variables, so I removed the useless details.

More trouble 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 it like this, but in Java 9 you almost reach nirvana, because now you can do something else." In Core Java for the Impatient, I simply explain how the latest version of Java works, imagining a programmer who already owns, for example, JavaScript. It is very refreshing. But, of course, many users have 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 whose knowledge and experience are very different. Are there any difficulties when you write “for all”? What helps to cope with them?

- There are difficulties, and it is inevitable that one can not wait for an understanding of all advanced material from a novice reader. I expect that a reader who is just learning object-oriented programming will carefully deal with inheritance and interfaces, and will only have a quick glance at reflection or modules, while the expert will do the opposite. It is easier with API chapters; it’s natural for readers to skip those chapters that do not 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 is easily understood in this form, without constant references to other places in the same book.

“When you write about Java over the years and go into details, does the feeling“ how much has been done in Java completely wrong ”arise? Have you tried to improve something?

“Of course, when it comes to such a large and complex platform as Java, there are a lot of things with which something is wrong. But only in rare cases is something horribly wrong: for example, this is the existence of primitive types, which should have been an internal affair of the 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 the API take twenty years to give us a method to read a stream into a byte array? Why is the unicode API so unpleasant? I could name dozens of others.

Unfortunately, they are not so easy to fix. In other open source projects, someone would simply suggest something better, a discussion could arise, a revision could occur, and then the changes would be accepted if there were no sharp objections. And in the case of Java, the complete opposite. We need resources to actively promote any change and so that it passes through the regulatory framework. Of course, there is a benefit from this, which means that your Java 1.0 program has excellent chances to compile successfully. But it also discourages everyone from making any changes.

As an example: I once suggested that you need 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 the VM is not so complicated. Why did I even care about this? Because it would be heavenly manna for students and teachers who would not have to deal with public static void main in the first lecture. "Hello, World!" Would look like this:

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

The second test 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? By no means. It was rejected as “too complex” and “capable of endangering backward compatibility.”

But be that as it may, over time, many annoying features of the API are fixed. Perhaps because they are annoying to people in Oracle just as much as they are to us.

Also, let's not forget how spoiled we are with 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 that.

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

- No, I have not heard of this from readers. Perhaps they leave such thoughts with them :-) But more seriously, I usually do not persuade to use a particular style. It always annoys me a bit when other authors tell me that I'm doing something wrong, so I try not to do the same. For example, I do not tell 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: a Java programmer who does not want to abandon his object-orientation and switch to pure functional programming. Those readers who share my point of view liked it. Those who do not share - not very.

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


- On your site in the section “memorable quotes” there is a quote that pricks Herbert Schildt. Since your books on Java are competing, I want to know - is this just a joke, or is your competition? :)

- 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 a program with artificial intelligence. 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 rival book. I look at it differently. There are authors whom I admire, and there are 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 gain knowledge. Some prefer, and some authors provide, the illusion of knowledge.

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

- This is also an excellent question. When I started the MOOC course, what happened in the framework of cooperation between my university and Udacity, I was told: “You don’t know anything, we will teach you 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 “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 review the video just to find some specific information.

So, if I had to choose between a video course (be it MOOC or not) and a book, I would always choose a book. But I am currently working on projects where the two parts are combined: an interactive part for the first contact, and a 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 videos. If they are equipped with serious interactive material that forces one to act, think and learn, and if one really acts, thinks and learns, they can be very effective. But if you just click the video and print the certificate, then this is an illusion of knowledge.

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

- Here lies a common 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 teach AngularJS. But as a university course ??? The university is good at teaching things that are still relevant after 20 years. And learn to learn. So after 20 years, when a former student needs to learn the XYZ framework, he will have the background and skills to quickly master it himself.

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

Another big difference between a university and work in an industry is that academic research focuses on originality, and work in an industry focuses on repeatability. Universities value little the quality of code, with the exception of people researching software engineering. It is possible that at universities they too much rest 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 to me a good idea.

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

- I don’t know if it happens that the industry misses many academic works with applied benefits. Many software companies have staff members with advanced degrees who are very familiar with research literature.

For example, look at unmanned vehicles. It began in universities, and then rather organically moved into the 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 environment, it was quickly put into service. So I’m not particularly worried about the priceless intellectual secrets hidden in the ivory tower.

- You taught CS around the world - in the USA, Switzerland, Vietnam and Macau. What caused such a spread?

- I just like to travel.

- And in terms of your work, was there any significant difference between these countries, or computer science and computer science in Macau?

- Everywhere the same thing. Everywhere I had outstanding students, and not very outstanding ones. 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 were very clever (they really were such, they were selected from 1% of the school exam results), and they need to form their own opinion. I think it taught them more than any technical information I gave in lectures.

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

- 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 K & R style and 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 even out curly braces? What if we want both at once? This is where the “Horstmann style” comes into play:

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

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

- Recently, Stanford changed its introductory course on CS, choosing to use JavaScript instead of Java. What do you think about that?

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

So it does not matter what language to use, unless the course itself focuses attention on it. I saw courses with C ++ that bothered students with details about pointers, and this did not contribute to the process. And at Stanford there was always a first-class course; with JavaScript, they can make it no worse than with Java — but, I think, not any better.

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

“Shortly after Java, during its rapid take-off, there was a very clear feeling that Java would be the“ end of history. ” From the tiny smart card to the most powerful server, Java has appeared to command them all.

Now we know what happened at all. Java is rooted in servers, but now Node.js breathes in the back of her head. Not for any technical reasons, but because "full-stack" developers do not want to write the client side in JavaScript, but the server side in Java. Given that Java UI is rare today, this is a problem. If I were the king of Java, I would make sure that Java will remain the language for Android, and also promoted Java-to-JavaScript technology for browsers. But obviously, I'm 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 are not written in it. And they don't write them 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 pleasant languages ​​(both on the JVM and not only) will declare themselves, but not achieve the same popularity. And year after year, the technical press will be surprised by the fact that Java is still very popular, although it has been declared for years 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) tickets for Joker will rise in price - so it makes sense to buy them today.