“We all strive for complexity and then fight with it”: interview with Venkat Subramaniam

“How many viewers will come to your java report? It depends on whether Venkat speaks at the same time in the next room. ”

This is a joke with a fair amount of truth: in the Java world, Venkat Subramaniam is one of the most famous speakers, really capable of pulling audiences from other halls at conferences. It is constantly moving across the planet and recently set an impressive record, speaking to its 50th anniversary one year ahead of 50 different Java User Groups.
')
What is it like when your Java career is not “sitting in the office”, but “constantly moving”? And what does Venkat think about topical Java questions? In October, he will get to St. Petersburg, and on the eve of this we ( phillennium , olegchir ) took a detailed interview with him, where we started with “living on an airplane” and tips for novice speakers, and then turned to technology.


As Venkat answers in detail, the text is very long. If you wish, you can go directly to the second part:

• For a life
• About technology

For a life

- Let's start with your tour, during which you visited 50 Java user groups, hardly anyone has ever done this before. What were your impressions?

“The most interesting thing for me was the realization that in different cultures in different parts of the world, people who speak different languages, despite all these differences, are united by programming as a single connecting thread. When we start talking about programming, it turns out that the problems we face every day are the same. This was a great discovery for me - you can meet a programmer at any airport in the world, and you will certainly find common topics for conversation. I can endlessly list cases where I was involved in Java conversations on the other side of the earth.

Therefore, the experience with these groups was very useful for me. Managing a user group is very difficult ... I don’t want to say “work” because it’s not work, but it takes a lot of effort. I have great respect for all the leaders who, again and again, gather these events every month. Different groups have different dynamics - some at the meetings have 20 or 30 people, others - 200 or 300. Nevertheless, the number, in essence, does not matter, because the main thing is the passion of the developers who come to these meetings, their interest in technology and their desire to learn. So I was very lucky to have the opportunity to meet with these groups, and I am very grateful for her.

- And with the similarities mentioned by you, do user groups in different parts of the world have any noticeable local differences?

- These differences are surprisingly small. I noticed that in some regions more preference is given to heavyweight frameworks, and in others to more lightweight solutions. But, as a rule, all these features are superficial, and deep-seated questions and problems, on the contrary, are universal. I sincerely would like to tell you that at some point on the map people do completely different things than we do, and everything is interesting and unexpected, but I can’t say that.

We all strive for complexity, it delays us, and when it tightens, we begin to fight it. This is a general trend almost everywhere. Another important issue that no one has avoided is the stringent requirements of the business and the lack of time to work on quality. I can talk about some example to people anywhere in the world, and after my story they will ask me: “Did you happen to work in our company?” Our problems are so deep and universal that, judging by everything, they are common to the whole world. Which involuntarily makes us think about our common human essence, about psychology and philosophy, which we ultimately follow. No matter how much we imagine ourselves as geeks, turned on technology, we should not forget about the human aspect in the development of software. Apparently, he is a unifying and universal force.

- I want to ask about the "hiking" lifestyle. When you sit in the office, it may not be obvious if you would like your life. For example, for many, the jetlag is a problem, and because of this constant flights can seem like a nightmare. But perhaps with practice you adapt to this?

- To answer your question, let's recall the integration. If the team performs the integration once a month, then you suggest that they do it all the time, they will consider you crazy. In this relationship travel resemble continuous integration and continuous delivery: if you deal with them quite a lot, your approach to them changes.

Understand me correctly, I am not proud of my lifestyle, in my opinion, it’s not worth living this way. I always say that when I travel I least like traveling. Sitting in an airplane is tiring, the body wears out, and with age these problems go nowhere. But when I find myself at the destination, when I meet with other developers, I see their passion for technology, their inspiration, I get the opportunity to share this passion, learn something new and help them learn, all the difficulties pay off with interest.

If we talk specifically about changing time zones, then it does not bother me at all. Because of the constant flights, in a certain sense, I have no permanent, “home” time. I have a rule: I always wake up at the same local time, around 3.30 at night, and the body very quickly enters a certain rhythm. And, of course, coffee is always very useful.

- Many people would like to see the world, but they usually go on tourist trips rather than business trips. Do you manage to look at the city, or because of lack of time only at conference rooms?

- Yes, partly there is a problem with time. But besides this, because of the constant flights, I have some principles that I adhere to. If travel is connected with work, then I do nothing except work. I try to spend as much time as possible with the developers. When I have a free Saturday or Sunday, for example, in Europe, I usually spend it in a user group. It gives me great pleasure to communicate with developers, so on my business trips I almost never go to the sights.

But every four or six weeks in the summer, I travel with my family, and we go sightseeing. This is our time for joint rest, and in the other months I am concentrated at work.

In addition, my approach allows me to pay maximum attention to various community events, which also gives me great pleasure. It absorbs a lot of time and is a kind of compromise, but it suits me. Life is sometimes too stressful, and I am glad to have the opportunity to sometimes distract and listen to developers who may not have the opportunity to attend a conference or training course. In addition, I believe that this is also my professional duty, for the reason that these things inspired me in my youth. I visited a user group, listened to speeches and dreamed at one time also to perform myself. If I, in turn, manage to inspire at least one person in the same way, this time will not be wasted.

- The last question about travel. In the film “Up in the Air”, George Clooney's character, constantly flying between cities, knows many tricks to increase travel efficiency: how to stand in line, how to pack luggage, and so on. Perhaps you also have some unobvious knowledge that you would like to share?

- I am ashamed to admit this, but I sometimes send clothes between cities via FedEx, because I simply don’t have time to fly home and take clothes for the next week. Often, when I arrive at the hotel, my clothes are already there, and when I leave, I send them home. Fortunately, this does not happen too often, perhaps three or four times a year, when I am on the road for three weeks in a row. There was one awkward moment when my wife had to go to the airport to hand me bags, because I only had half an hour between flights. But over time, you really learn to do some things more efficiently. I am sometimes surprised when people say “I need to pack up” because my things are collected all the time.

If we talk about efficiency, I have at least one advantage: I am a very single-task person. We live in the world of Facebook, Twitter and various instant messengers, they constantly distract us. I have worked very hard to reduce this influence, because the minutes turn into hours, the hours turn into days, the days turn into weeks, and sooner or later you realize that you could not achieve what you wanted. I usually have a journal in which I write down the things that need to be done for each trip. Thus, I have a schedule for each day (for example, November 7 or October 8), and my phone reminds me of each task on the respective day. For an eight-hour flight, I can easily write most of one chapter of the book, or prepare an example for the course. Therefore, flights for me is an extremely effective time. I never need additional entertainment during the flight - quite enough entertainment related to debugging code. So a professional traveler (if such a term is applicable at all) spends time in flight quite differently than a tourist.

- Probably, because of your fame, you receive a lot more letters than ordinary developers. How much do they write to you and how long does it take to work with mail?

- It is worth adding that I teach at the university and get a lot of letters from students. Usually I receive 20 or 30 letters a day. About a year ago I wrote in a blog about one of my principles: “answer now or tell me when you answer.”

I really appreciate my time, which means that I value the time of other people. In my opinion, respect for another person is not in the treatment of "sir", but in appreciating each other's time. Therefore, if I receive a letter, I always reply within 24 hours. But there are periods when giving a full answer does not come out - for example, if the conference organizer asks to send an abstract or if an industry colleague asks a question about solving a particular problem, asks for some code to be refactored or for some method. Sometimes the answer may take ten minutes, and sometimes two hours, but even ten minutes cannot always be spent. It may sound a bit strange, but I still answer in 24 hours and write: I received your letter, I will work on this problem, say, on September 2 and write to you on the 3rd. At the same time, my calendar is updated with the corresponding entry on the day when I have time to fly or after lunch.

Thanks to this approach, my inbox is always empty; I clean it every night before going to bed. So I am extremely disciplined to respond to letters. People are often surprised that I respond to their letters so quickly, and I, on the contrary, do not understand how it can be otherwise. I do not want to stand in the way of people, prevent them from developing. In addition, I consider it important to be able to say no. I like to repeat that the more often you say “yes”, the worse you will get what you do. At a certain point you need to realize that we can not achieve everything in the world. Therefore, sometimes I answer that, unfortunately, I cannot help. In turn, I prefer to be told “no” at once, rather than dragging rubber and saying “no” afterwards. In my opinion, this also speaks of respect for the person and unwillingness to waste his time. You are not obliged to help, but at least do not interfere. Therefore, it is important to say no. That's the way life is, don't try to pretend that you can catch everything. For me, the ability to respond quickly and honestly is a sign of professionalism.

- You are a very experienced speaker. As conference organizers, we meet people who have no public speaking experience or have very little. Perhaps you have recommendations for them? You had an interesting advice on Twitter “to visit the hall in advance where the report will take place” - are there more like that?

- My first reports were in user groups, which is why I continue to do in them 15 reports each year. And I recommend others to start with the same: with the user group in your area, then in the next, and so on.

On these reports, for many reasons, there are less risks than at a large conference: there is a friendly atmosphere, people come there to share knowledge, after your reports you will easily get a response. You may well begin to speak, saying that you have little experience in this matter and would like to know the opinion of the audience. This year I had a new report, during the preparation of which I was experiencing quite a lot. I wrote about this on Twitter: it seems that everything can be said in two minutes, but in reality the material cannot be laid in an hour and a half. And I am very pleased that the first time with this report I spoke in the user group, because it gave me the opportunity to better prepare it for the conference.

In user groups or in the company where you work, you have a wonderful opportunity to practice with performances. First, you will receive criticism from colleagues that will allow you to improve the report. Secondly, even if they do not say anything directly to you, you will still understand a lot when you start talking. I believe that the report can really be improved from the third time. For the first time, you're only trying to put all your thoughts together. And what is interesting: practicing alone here will not help, awareness of problems comes only during performances in front of other people. By the third time, the logical chain of your narrative becomes clearer for you, turns out to be complete. This is not always noticeable, but I sometimes pause during a speech for the third time - at this moment I realize what I was trying to say in the report, a kind of moment of truth comes. So, practice is very important, but not alone with yourself, but with people. For a young developer, this can give the necessary confidence.

True, some make their first reports at conferences. Sometimes it is easier for a person to die than to speak in public, and they are easy to understand - it requires a lot of nerves. Two or three years ago I spoke at the same conference. A very interested person came up to me and said that I seemed to be very worried, to which I replied that this was indeed the case. He asked, "Is this your first report?", And I replied: "No, probably ten thousandth, that's why I'm worried." Each performance before an audience requires a lot of emotional stress, even if you have a lot of experience, simply because you care about how the report will go. You will do yourself a great service if you relieve this tension with a few test reports in user groups or in your company. This applies to all speakers, including experienced.

- Is there something in public speeches that, on the contrary, should be avoided?

“I made a lot of mistakes in my life that taught me that people learn best from experience.” When you speak to an audience, you need to remember a few things. Firstly, you need to maintain self-confidence: you have worked a lot on the topic, and you know a lot about it. Secondly, remember: knowing everything is impossible, and not knowing anything is not your fault. It simply means that you have not had the opportunity to pay attention to it, and there is nothing wrong with that. It is extremely important to honestly admit this to yourself. You can quite answer the question at the conference like this: sorry, I cannot tell you anything, I have not had the opportunity to study this problem.

Another important point is that listeners can be divided into three types. There are people who want to learn something new from you. Others keep themselves somewhat more cautious, they will listen to you, but they will not be ready to accept everything you say. Finally, there is a third group of people, fortunately, rather small in number: those who are hostile are trying to catch you all the time. Sooner or later there will definitely be one developer on your report who will interrupt you all the time and disrupt the progress of the report. In such cases, it is very important to remain calm, to allow him to speak out and return the discussion to the direction you need - but, I must admit, I am also a person, and I do not always succeed in doing this. You can, for example, say: I understand that this is important for you, let's discuss it after the report, this topic is important for many here. However, very often you have allies in the audience, and when a person really disrupts the progress of the speech, he is asked to calm down. All this I say to the fact that it is important not to be too conflicted in such situations, even though our nature can resist it. As a young speaker, I quite often entered into this kind of confrontation to the fullest, and this never brought anything good to anyone. It is necessary to show emotional maturity and not try to prove anything to anyone by engaging in such kind of squabbles. Instead, in such cases, you should lead the topic back to what is interesting to the audience.

I would also like to talk about some of the negative habits during the speeches, which, in my opinion, the developers have. For starters, people should look into their eyes. I understand that it is very difficult and requires a lot of emotional effort, but you need to practice this. Speakers often look at their monitor or, even worse, at the screen, standing with their backs to the audience. You should always face the listeners and you should always look at them. In addition, you must maintain self-confidence. You speak to an audience of programmers, and you can bet that none of them have code that works the first time. If your demonstration during the report did not work - there is nothing wrong with that. All those present are likely to think: "Damn, I have everything the same way." Over the years, I have learned in such situations to turn to the audience for help with debugging. Usually the speakers in such a situation start mumbling something under their breath and try to solve all the difficulties on their own. Instead, ask the audience - friends, do not tell me where I am stupid? , . , . . , : , , , . , .

— Java- , Java «Hello world». «public static void main» , , .

: Java- , , , . , . - - Java?

— , . , , Java — , 2000-. , , , .

, , , , , . , , 70 try-catch . , , , .

— . , , , . , , . , . , .

Java 12, 13 14 : , , Java , , . , , Java , . , , . , , Java . , , , Java . , , , , , Java .

---

. Joker «Don't walk away from complexity, run» . , Joker , , .

---

- In the context of "less pompous Java", it is impossible not to ask you about Kotlin, which is often called that.

- Yes this is true. And it's not just less pretentious. For me, one of the most exciting things in life is meeting new languages ​​and their capabilities. One of the possibilities in Kotlin is to run a lambda in the context of an object, even though it is not part of a class. I became very interested when I found out about this, because the same possibility is present in JavaScript. There you can pass a context object in the call (what is called a receiver in Kotlin), and then execute this arbitrary global function as if it were a function of some object. The fact that this feature is in JavaScript is not surprising, since this language is dynamic. But Kotlin is a static language, and it does the same, while respecting type safety. The lack of pretentiousness, of course, is a big advantage of the language, as is the fact that it generates a significant part of the code automatically, so that we can not write the same templates over and over again. But the advantages do not end there, because this feature allows you to create internal DSL.

Science and mathematics led me into programming, but 30 years later I remain a programmer due to the fact that it is an art. Our area combines science and art, this is not going anywhere. The ability to simply make the system work is not limited, here you can draw an analogy with the writing of poems: ask two people to write about love, and each will write in his own way. The code for any task can be written in many different ways. This is what attracts me in languages ​​like Kotlin and many others: the ability to express some of these ideas, to give the code flexibility and ease. You can think less about the syntax of the language and more about the thought you want to convey.

- For you, quality code is important. It seems to be important for everyone, and everyone seems to want to write better, but it is well known that a significant part of the existing code has problems. Therefore, the question is: for your colleagues not to be hated for your code afterwards, you just need self-discipline, can you give any specific recommendations?

“I’m convinced that the only way to write readable code is to read it.” When they tell me that the code is readable, I ask - who read it? If the author himself read it directly after writing, this is not considered. Therefore, I am a strong supporter of the code review. I want to clarify: I am against bringing a team into a room with a large screen, showing code on it and criticizing it. This inevitably leads to resentment, such a public indulgence does not benefit anyone.

You need to honestly admit: we all write bad code. I am proud to admit: my code sucks, I do not know how to write good code. If you ask how this fits with my talk about code quality, I’ll answer: writing code is a process with constant innovation, and when you try to implement some idea, the quality of the code doesn’t bother you too much. It is always necessary to go back and refactor, and even when I do this, it usually doesn't work for me. But over the years, I realized that, although my own code is low-grade, I am very good at finding flaws in someone else's code. Therefore, instead of pretending that my code is already excellent, I will write it as well as I can, and give you a check, and in the meantime I will take the code of a colleague and check it. As a result, both my code and colleague code will be of higher quality.

It is very important to give up false pride. I always remind the developers that they are part of the team, it makes no sense to compete with each other and find out who is better. I am ready to honestly admit that my knowledge is rather limited - but I know well what I know. And my colleague also has very deep knowledge in some other area. Together we become stronger when we are ready to learn from each other. Therefore, I always suggest checking the code of each other, and extra pride is completely useless here. You need to be honest with each other, this is one of the most important qualities of a good team. Honesty should not be punished if a person admits that he wrote bad code - this is normal. We are raising the general bar by offering each other ways to improve the code.

Another important point: do not tell the person that he made a mistake, I must say that it is possible to improve. Do not say: "God, what a terrible name for a variable," better like this: "You probably wanted to say that this variable shows the frequency of distribution - you should probably call it appropriately." This will help you better convey your intentions. This also applies to editing books: talk not only about what needs to be improved, but about what has been done well. We often forget this. When I edit someone else's code and see a place that is qualitatively executed, I write in a commentary that I like it very much, that we need to do this more often, and explain why. This creates constructive feedback, lets the developer know that you are not hostile to him, and ultimately improves the quality of your team’s code.

- You wrote that using a tool that drives you into anguish is like getting stuck in a toxic relationship: in such a situation, you just need to leave, and as soon as possible. It sounds great, but often the tool has no particular alternative, and what to do then?

- Quite justified question. Indeed, there are situations where there is nowhere to go. But I rather talked about the cases when there is still a choice, and all that is lacking is the desire to make it. In my opinion, this is a significant factor.

When there is no choice, instead of complaining, pain points should be identified: what exactly makes this tool uncomfortable for you. And then you can do in different ways. You can contact the developers and say - thanks for your work, it seems to us that your tool could be much better if you paid attention to such and such an aspect. Or you can spend a hackathon - get together with several developers on a weekend, organize a user group, tell them that you spend nine hours a day with this tool, that it is terrible, and ask them to try to add some features to it.

You may not be able to solve all the problems alone, but at least you will be able to gather other people and solve this problem with them, especially if their interests are similar to yours. Finally, if your tool really gives you so many problems, you can try to write a new one yourself - if you have three or four friends in the community with the same attitude as you.

So, in my opinion, there are still alternatives. You don't have to put up with a toxic relationship. You should always be able to find a way out - either reach an agreement with a partner and achieve mutual understanding, or leave.



- You have written a book about lambdas, and you are known for this book. I also read it, and I think that it is beautifully written, gives what the application developer needs, and does not give anything extra. As a true professional, I would like to ask you: what is functional programming for you? Could you describe it in your own words? I ask this question because everyone defines it a little differently, and each time hidden meanings are revealed that differ from the standard definition from Wikipedia.

- This is a great question. My understanding of this concept has evolved over the years, and now for me the most important thing in functional programming is the removal of extraneous complexity. The point is that in imperative programming you not only indicate what needs to be done, but also spells out in detail how to do this. For me, functional programming is a superstructure over the declarative programming style, in which we indicate what needs to be done, but we don’t say how.

Let me give you a primitive analogy: my best friends adore cars, and I am not at all interested in cars. When we get together, we agree not to discuss cars, because we want to remain friends. I will never drive a car with a manual gearbox - the need to constantly change gears spoils my whole ride, and the same goes for the imperative programming style. An automatic gearbox makes driving a bit easier, but for me the best option is for the driver to drive me. In this case, I just say where I need to go, and along the way I write the code on my laptop in the back seat. For me, this is the difference between imperative and functional programming. With imperative programming, you yourself are driving, you need to know where to go, how to go, where to turn, where you can cut. With functional programming, you sit in the backseat, tell the driver where to take you, and your attention is entirely focused on your work.

How does the removal of this extraneous complexity occur? Through the composition of functions. When composing functions, your code goes through a series of transformations, during which the data goes from one form to another. And for us, it is not important how each of these steps is carried out, but what exactly it achieves. For me, the first aspect of functional programming is functional composition. The problem is that many languages ​​in which functional composition is implemented - Ruby, Python, JavaScript, Groovy, and so on - due to this provide elegance and expressiveness, but have very low productivity. The functional composition in them is implemented inefficiently. I think that elegance without efficiency is not viable. Not only is the code beautiful, it also needs to work quickly. And here we come to the second, vital aspect of functional programming - we are talking about lazy calculations. The result of a certain function is calculated only at the moment when it is needed. Due to this, functional programming achieves a combination of elegance and efficiency. So, for me, functional programming is an emphasis on what to do, not how to do it; the use of functional composition as a series of data transformations; and the ability to perform these transformations efficiently thanks to lazy calculations.

Please note that I did not talk about immunity and high order functions. The fact is that they are only ingredients for getting the result I described. We use functional programming not for immunity and high-order functions, they are only a means to achieve a higher goal: getting rid of extraneous complexity.

- Fine definition. Today, there is a language that is a benchmark for what functional programming should be: Haskell (and possibly F #).

- Absolutely.

- At least, many think so. But Java is obviously not Haskell, it is limited in many ways. Does functional programming make sense as a discipline for Java? Indeed, in our language there is a very limited set of tools for such an approach.

- For me, the pragmatic aspect is more important than the pursuit of perfection. I am curious about perfection, but for everything to work, I have to be a pragmatist. I am crazy about Haskell and spend a lot of time with him, just to find out how this or that problem is solved in functional programming. But for my clients, I'm not writing Haskell. Here you can draw an analogy with the "Cathedral and Bazaar". The cathedral is beautiful, but most of the time I spend in the bazaar. The question is how to survive in this world. When languages ​​evolve and when we try to connect several different paradigms together, we, as programmers, need to be extremely careful with their implementation.

I do not think that in Java functional programming is impossible at all. In situations where there is a choice, I will focus on the most appropriate language for me. But I will never tell the client: you should use this language. Most often, I ask what exactly they are doing, and I try to find a way to do the same in a more optimal way within the framework of the environment that they already have. I believe that in languages ​​like Java, the combination of imperative and functional programming is quite possible and even recommended, but this should be done with extreme caution. Imagine that you have a kind of circle of pure functions, around which there will be a ring of sewage. Everything that you want to make changeable must be outside the circle. Inside this circle, you can implement your chain of functions, but all changes must be outside it.

This is one of the reasons why I enjoy learning new languages. Recently, I met Elm, which is Haskell syntax with F # splashes, which is compiled into JavaScript. I was interested in this approach from the very beginning, because JavaScript is a bazaar. When you travel through JavaScript, you constantly attack in puddles. Elm, thanks to Haskell syntax, is uniquely a cathedral. Nevertheless, this cathedral code is possible to run on the market. The Elm architecture is elegant, it has a model (that is, data), there is a view that displays this data, and there is a transformation, update. The first main principle is that the data is stored in the view. When the user performs an action (presses a key, for example), the data from the view is sent to the update function, where the conversion takes place. The data is immutable, and the update function returns new data that the view saves instead of old.

If you think about it, then Redux functions in exactly the same way. There are data in it and there are reducers converters. When data is sent to reducers, you receive in return a new copy, which you save instead of the old one. But if Elm and Redux operate along the same scheme, then the same scheme can be implemented in Java. We can create clean functions that will take data, convert them, and return a new copy. By learning from Redux and Elm, we can make the Java architecture more functional. I am talking about this because Redux is compiled into JavaScript, which is definitely a bazaar. JavaScript, I think, is the most removed from the ideal of functional cleanliness, here at every step you step into a puddle. Nevertheless, Redux gives you functional purity in this extremely unclean world. This approach has greatly influenced me, because it changed my view on functional programming and showed that I can implement these principles in Java as well.

- Well thank you. In your opinion, is the set of tools that we have in Java complete and sufficient? Do we need anything else besides lambda expressions, references to methods, collections with streams?

- In my opinion, we still lack a lot. The Java world is constantly evolving. I recently had a dialogue with a man who said: "I heard that you were in our city several years ago and argued a lot on the topic of generics," to which I replied: "I always argue a lot about generics." I believe that Java generics are very poorly made. Brian Goetz is angry at me all the time: “There will always be someone who complains of generics,” and that someone, of course, is me. In my opinion, much can be improved in this area. Very important, in my opinion, reification. Much can be done in terms of reducing bombast, getting rid of the template code. The code can be made much more fluent. And a certain movement in this direction is already visible today. Now pattern matching is implemented in Java, which makes me very happy - I really like the way it is implemented in Scala and Kotlin. I think it is very important, and the analogy with the banknote processing machine comes to my mind. If you skip a bundle of bills through it, it will sort them out according to the value of each note. Similarly, pattern matching works in programming. You pass data through parameters that can retrieve data for processing. I think this could help get rid of the huge number of branch operators we write in Java. The code will become much more expressive. In general, I believe that Java needs a lot of add-ons, but apparently, it is already moving in this direction.

I want to mention one more aspect, which for me is really curious. I grew up in the world of traditional programming. I'm not afraid to publicly admit that my first language was Visual Basic. In a sense, this is a good language for the first experience, because it cannot be worse. Then I wrote for a long time in C and C ++, and I spent most of all the time in all languages ​​with C ++. After that, I started writing in Java, C #, languages ​​like Ruby. At a certain point, I realized that I always wrote in languages ​​with multithreading. Therefore, acquaintance with Node became a kind of insight - it took me some time before I figured out asynchronous programming. , , — , Java. (coroutines) (continuations). , Java , , , . , Java , . , . . , , , , Java-, . , , , . Java , .

— , ? JVM-, . . ?

— , . , . , , : , , , , , . , . I will give an example. , , , , . Big Data. , . , . , , , -. , , . , .

, , . , . , . , , . , , , . , , , . . , , : . , 30 . , -, .

, . , , , . . . , , , . : , . , , .

— . , ? , , . , Reactive Streams, Spring Reactor, CQRS event sourcing. - , CQRS?

— , , . , , — . Angular 1, , , . Angular «$» . , : « . ». , . , , , . , . — — Angular 2, , .

, , . , , API — . ? - ? , , - . . Java — — deprecated-. Angular 1 — . , , .

— - (event-driven systems), , . , -. , , API , . , . , , 5-10 , . -, , - . , . , , — , . — ++. — . , , , . - , , , . , , , .



— , , .

Java Champions, Microsoft MVP, JavaScript, . : Java ? .NET, JavaScript - ?

— , Java , .NET - . # Java, , C# . . Java , # LINQ, , (, Func). C# , Java. , , Java 2014 CompletableFuture. C# .

Java JavaScript. , « JavaScript» , JavaScript , . «callback hell», , - , . JavaScript Promises (), CompletableFutures Java. : , . Promises , . — Promises . , , , . , , , , . JavaScript async await. , Promise. , , , , , . CompletableFuture , continuations Java . , coroutines Kotlin.

, , . . , , , , , , . , , . , , — , , . async C#, async/await Promises JavaScript coroutines Kotlin, , , — , , . . Java . , Java , , , , . , . , , , . Java , . , Java — .

Java. . , Java , . Java , invokedynamic, , . , JVM. Java , — . , , . , Java , Java , JVM. . , , . , Java , .

— . , , , . , 5 . — . — , Common Lisp, JavaScript Meta Object Protocol, DSL Kotlin JetBrains MPS, GraalVM Java Java . . ?

— . , . , , . . -, , . -, , . , , , . , . , , . , , . , , : ? — ? , , ? , . : , Angular, — React? , React. — ? , , , , - , . , , . , , . , , — , , . , .

, . , . - : , . , : , , , , . 1 10, 10 « », 1 «». 1 10, 1 « », 10 — « ». , , . , . , . , Angular, React Java . : ? , . , : . . , , , . , , , , ; ; .

, , — . — , . . - , , . , , . , . , , . , , . , . , , , .

— , . Joker , .

— , .