"We all aspire to complexity, and then we fight it": an interview with Venkat Subramaniam <{short}> <{full}> <div class="post__text post__text-html js-mediator-article"> <img src="https://habrastorage.org/webt/4f/wf/47/4fwf47ggallnm17cldz
"How many viewers will come to your Java report?" It depends on whether Venkat is performing at the same time in the next room. "
This is a joke with a fair amount of truth: in the Java world Venkat Subramaniam - one of the most famous speakers, so that at conferences it is really capable to draw spectators from other halls. He relentlessly moves around the planet and recently set an impressive record, to his 50th birthday in one year before 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 current Java issues? In October, he will reach St. Petersburg, and on the eve of this we ( <{short}> <{full}>
"How many viewers will come to your Java report?" It depends on whether Venkat is performing at the same time in the next room. "
This is a joke with a fair amount of truth: in the Java world Venkat Subramaniam - one of the most famous speakers, so that at conferences it is really capable to draw spectators from other halls. He relentlessly moves around the planet and recently set an impressive record, to his 50th birthday in one year before 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 current Java issues? In October, he will reach St. Petersburg, and on the eve of this we ( <{short}> ? phillennium
, Olegchir ) Took a detailed interview with him, where they began with "life in the airplane" and advice for beginning speakers, and then switched to technology .
For the life of
On the technologies
wrote in a blog about one of his principles: "Answer now or tell me when you answer."
I really appreciate my time, which means that I appreciate the time of other people. In my opinion, respect for another person is not in the circulation of "sir", but in appreciating each other's time. Therefore, if a letter comes to me, I always reply within 24 hours. But there are times when you can not give a full answer - for example, if the conference organizer asks you to send an abstract or if your industry colleague asks a question about solving a particular problem, asks you to refactor some code or ask about the application of some method. Sometimes the answer can take ten minutes, and sometimes two hours, but even ten minutes can not always be spent. This may sound a little strange, but I still respond in such cases within 24 hours and write: I received your letter, I will work on this problem, say, on September 2 and write you the 3rd. At the same time, my calendar is updated with the appropriate entry the day when I have time in flight or after lunch.
Thanks to this approach, my inbox is always empty, I clean it every night before going to bed. So I'm very disciplined answer letters. People are often surprised that I respond so quickly to their letters, 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 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, we must realize that we can not achieve everything in the world. So sometimes I answer that, unfortunately, I can not help. In turn, I prefer that I was told "no" at once, but did not pull the rubber and said "no" then. In my opinion, this also speaks of respect for a person and unwillingness to waste his time. You do not have to help, but at least do not interfere. Therefore it is important to say "no." So life is arranged, do not try to pretend that you can do everything in the world. For me, the ability to respond quickly and honestly is a sign of professionalism.
- You are very experienced reporter. As organizers of conferences, we meet people who have no experience of public speaking or have very little. Perhaps you have recommendations for them? You tweeted had an interesting advice "to visit the hall in advance, where the report will be held" - are there any more similar?
- My first reports were in user groups, which is why I continue to do 15 reports every year. And I recommend others to start with the same: with the user group in your area, then in the neighboring and so on.
On these reports, for many reasons, there are fewer risks than at a large conference: there is a friendly atmosphere, people come there to share knowledge, after your reports you will easily receive a response. You may well start the speech by saying that you have little experience in this matter and you would like to know the opinions of listeners. This year I had a new report, in preparation for which I was quite worried. I wrote about it on twitter: it seems that everything can be said in two minutes, but in reality the material can not be laid in an hour and a half. And I am very glad that the first time I delivered this report to 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 great opportunity to practice with performances. First, you will get criticism from colleagues, which will allow you to improve the report. Secondly, even if you are not told directly, you will still understand a lot yourself when you start talking. I believe that the report can be really improved from the third time. The first time you just try to bring all the thoughts together. And that's interesting: practice alone will not help here, awareness of problems comes only during speaking before other people. By the third time, the logical chain of your narrative becomes clearer to you, it turns out to be complete. This is not always noticeable, but I sometimes stop during the speech for the third time - at this moment I realize that exactly what I tried to say in the report, comes a kind of moment of truth. So, practice is very important, but not alone with yourself, but with people. The young developer can give the necessary confidence.
True, some make their first reports at conferences. Sometimes it is easier for a person to die than to appear in public, and they are easy to understand - it requires a lot of nerves. Two or three years ago I spoke at one conference. A very interested man came up to me and said that I, I think, are very worried, to which I replied that this is indeed so. He asked "Is this your first report?", And I answered: "No, I'm more than ten thousandth, that's why I'm worried." Every performance before the public 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 ease this stress by several test reports in user groups or in your company. This applies to all speakers, including experienced speakers.
- Is there something in public speeches that, on the contrary, should be avoided?
- I made many mistakes in my life that taught me that people learn best from experience. When you speak in front of an audience, you need to remember a few things. First, you need to maintain confidence: you have worked a lot on the topic, and you know a lot about it. Secondly, remember: knowing everything is impossible, and ignorance of something is not your fault. It simply means that you did not have the opportunity to pay attention to it, and there is nothing shameful about it. It is extremely important to honestly admit this. You can easily answer the question at the conference so: sorry, I can not tell you anything, I did not have 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 from you something new. Others keep themselves a little more cautious, they will listen to you, but are not ready to perceive everything that you say. Finally, there is a third group of people, fortunately, quite a few: those who are hostile and always try to catch you. Sooner or later, there will be one developer on your report who will interrupt you all the time and break the report. In such cases, it is very important to remain calm, let it speak out and return the discussion to the direction that you need, but I must admit that I am also a person, and it's not always possible for me to do this. For example, I can say: I understand that this is important for you, let's discuss this after the report, this topic is important for many here. True, very often you have allies in the audience, and when a person really breaks the course 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, although our nature can resist this. As a young speaker, I quite often entered into this kind of confrontation to the fullest, and it never brought anything good to anyone. It is necessary to show emotional maturity and not to try to prove anything to anybody, entering into this kind of squabble. Instead, in such cases, you should take the topic back to what the audience is interested in.
I would also like to talk about some negative habits during the speeches, which, in my opinion, the developers have. To begin with, people should look into the eyes. I understand that this is very difficult and requires a lot of emotional effort, but this should be practiced. Speakers often look at their monitor or, even worse, on the screen, standing with their backs to the audience. You always have to face the listeners and always look at them. In addition, you need to maintain self-confidence. You speak in front of the programmers' audience, and you can bet that none of them have the code working the first time. If your demonstration did not work during the report - there is nothing shameful about this. All present will most likely think: "Damn, I have everything exactly the same." Over the years, I've learned in such situations to reach out to the audience for help with debugging. Usually, the rapporteurs in such a situation begin to mutter something to themselves and try to solve all the difficulties themselves. Instead, you should ask the audience - friends, do not tell me where I'm drowning? You will immediately receive a lot of suggestions, and very often they will help you find the error. To speak and write the code at the same time to one person is difficult, do not be afraid to ask for help. For the listeners, this experience is also valuable. This is one of the reasons why I visit other people's reports: to see what they are doing, and to understand what exactly one should not do. In my opinion, these habits will help you to refactor your speaker skills.
told us, which suggested simplifying the creation of "Hello world" in Java. Because newcomers at the sight of "public static void main" come across a lot of new concepts at the same time, and it scares away, the more gradual entry is more reasonable.
It's interesting that: Java developers rarely think about the benefits of this, because they already seem to take these things for granted, and Horstmann understands this, because he teaches at the university and personally sees the fright on the faces of students. You as a teacher, author of books and a speaker also teach people. Do you also want to change something in Java because of this? [/b]
- Yes, definitely. Moreover, this is one of those things that attract me in Java - it's not the language that it was in 2000. Over the past few years, language makers have become aware that when a language becomes verbose and pompous, it significantly hinders the work of programmers, and not just beginners.
Suppose you communicate with your colleague, you are visited by some new thought, but it is not immediately obvious to your interlocutor, and he asks you to demonstrate what exactly you mean. You open the editor, and in the first seconds you realize that to implement this idea you need to write 70 try-catch blocks. And, although the idea is good, you decide to leave it for later, because right now there can be no time.
For me, programming is a series of small experiments. As a consultant, I work with teams of programmers, each with its own way of writing code, and I often recommend ideas to them that I have seen from other people. When this happens, they want to not just hear a new thought in words, but see it in the code. In such cases, it is important that they can be quickly demonstrated. In this aspect, I like the least fanciful languages that allow you to implement your idea in several lines of code.
That's why Java 1? 13 and 14 evolve in this direction: the developers realize that, even though Java is an extremely powerful language, it's not easy to experiment with it, and it's hard for it to learn. When you know exactly what you want to write, Java works perfectly, but usually the programming looks different. You always learn and experiment, you always have ideas that previously seemed impossible. If I work in a company with an established code base and a certain code structure, and if I add new features to the application based on existing templates, these changes will not affect me significantly, here Java perfectly works in an already existing form. But if you are an architect, timlid, or just a programmer who writes the code innovatively and experimenting, Java in today's form will in many ways limit you. Therefore, in my opinion, it is important that languages evolve towards a lesser bombast, and I'm a big believer in the direction in which Java is now changing.
Minute of advertising. In October, Venkat will open our Petersburg Joker conference with a performance of "Do not walk away from complexity, run" . And, since each speaker Joker after the speech goes to the discussion area, there will be an opportunity to personally discuss with him and the topic of the speech, and other issues.
- In the context of "less pompous Java", it's impossible not to ask you about Kotlin, which is often called that.
- Yes this is true. And it's not just a less pretentiousness. For me, one of the most exciting things in life is getting to know new languages and their capabilities. One of the possibilities in Kotlin is to run the lambda in the context of the object, even though it is not part of the class. I was very interested when I found out about it, because the same feature is present in jаvascript. There you can transfer 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 possibility is in jаvascript is not surprising, since this language is dynamic. But Kotlin is a static language, and it does the same, while respecting the type of security. Absence of pretentiousness is certainly a great advantage of the language, as well as the fact that it generates a significant part of the code automatically, so that we can not write the same templates again and again. But the benefits do not end there, because this feature allows you to create internal DSL.
I was led into programming by science and mathematics, but 30 years later I remain a programmer because it is an art. Our region combines science and art, this can not be avoided. The ability to simply make the system work is not limited to, here you can draw an analogy with writing poetry: ask two people to write about love, and each will write in their own way. The code for any job can be written in a variety of 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, the quality of the code is of great importance. It's kind of important for everyone, and it seems like everyone wants to write better, but it is known that a significant part of the existing code has problems. Therefore, such a question: so that your code is not hated by your colleagues then, you just need self-discipline, can you give any specific recommendations?
- I'm convinced that the only way to write a readable code is to read it. When people tell me that the code is readable, I ask - who read it? If it was read by the author directly after writing, it does not count. Therefore, I am a strong supporter of code reviews. I want to clarify: I'm against bringing a team into a room with a large screen, showing the code on it and criticizing it. This inevitably leads to resentment, such a public ohayvanie no benefit to anyone.
We must honestly admit: we all write bad code. I'm proud to admit: my code sucks, I do not know how to write good code. If you ask how this goes along with my conversations about the quality of the code, I'll answer: writing code is a process with constant innovations, and when you try to implement some idea, the quality of the code does not bother you too much. It is always necessary to return and refactor, and even when I do this, I usually do not get out. But over the years I realized that, although my own code and base, but I'm 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 it to you for verification, and in the meantime I'll take the colleague's code and check it. As a result, both my code and colleague's 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 sense to compete with each other and find out who is cooler, no. I am ready to honestly admit that my knowledge is rather limited - but what I know, I know well. And my colleague also has very deep knowledge in some other field. Together we become stronger when we are ready to learn from each other. Therefore, I always suggest checking each other's code, and there is absolutely no need for extra pride here. We 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 recognizes that he wrote a bad code - this is normal. We increase the overall bar by offering each other ways to improve the code.
Another important point: do not tell a 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", it's better: "You probably wanted to say that this variable shows the frequency of the distribution - it should probably be called appropriately." This will help you better convey your intentions. This also applies to the editing of books: talk not only about what needs to be improved, but also about what has been done well. We often forget this. When I edit someone else's code and see a place that is quality executed, I write in the commentary that I like it very much, that we need to do this more often, and I explain why. This creates constructive feedback, gives the developer to understand 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 this situation, you just have to leave, and as soon as possible. This sounds wonderful, but often the tool does not have a particular alternative, and what should I do?
- Quite justified question. Indeed, there are situations when there is nowhere to go. But I rather talked about those cases when there is still a choice, and there is only one desire to do it. In my opinion, this is a significant factor.
When there is no choice, instead of complaining, you should identify the pain points: what exactly makes this tool uncomfortable for you. And then you can do it 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 hold a hackathon - gather at the weekend together with several developers, organize a user group, tell them that you spend nine hours a day with this tool, that it is terrible, and ask you to try adding some features to it.
Perhaps you can not solve all the problems alone, but at least you can gather other people and solve them together with them, especially if their interests are similar to yours. Finally, if your tool really gives you so many problems, you can try writing a new one yourself - in the event that you have three or four friends in the community with the same attitude as you.
So, in my opinion, there are still alternatives. You do not need to put up with toxic relationships. Always you need to be able to find a way out - either negotiate with a partner and achieve mutual understanding, or leave.
- You wrote a book about lambdas, and they know you thanks to 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 real 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 there are hidden meanings that differ from the standard definition from Wikipedia.
- This is a wonderful 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 specify what you need to do, but also detail how it should be done. For me, functional programming is a superstructure over a declarative programming style, in which we indicate what needs to be done, but do not say how.
I'll give a primitive analogy: my best friends adore cars, and I'm not interested in cars at all. 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 switch gears spoils my entire ride, and the same applies to the imperative programming style. The automatic transmission slightly simplifies the ride, but for me the best option is for me to drive. In this case, I only say where I need to get to, and along the way I write the code on my laptop in the back seat. For me, in This is the difference between imperative and functional programming. With imperative programming you are driving, you need to know where to go, how to go, where to turn, where you can cut it. With functional programming, you sit in the back seat, tell the driver where to take you, and your attention is entirely focused on your work.
How does the removal of this extraneous complexity take place? Through the composition of functions. When composing functions, your code goes through a series of transformations, during which the data passes from one form to another. And for us it's important not how each of these steps is performed, but what exactly it achieves. For me, the first aspect of functional programming is the functional composition. The problem is that many languages in which the functional composition is implemented - Ruby, Python, jаvascript, Groovy and so on - provide thanks to this elegance and expressiveness, but have very low performance. Functional composition in them is implemented inefficiently. I also think that elegance without efficiency is not viable. Not only that the code was beautiful, it should also work quickly. And here we come to the second, vitally important aspect of functional programming - it's about lazy computing. The result of a certain function is calculated only when it is needed. Thanks to this, a combination of elegance and efficiency is achieved in functional programming. So, for me, functional programming is an emphasis on what to do, not how to do it; use of the functional composition as a series of data transformations; and the ability to perform these transformations effectively through lazy calculations.
Note that I did not talk about immunity and high-order functions. The fact is that they are just the ingredients for obtaining the result described by me. 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 the standard of what functional programming should be: Haskell (and, possibly, F #).
- That's right.
- At least, many people think so. But Java, obviously, is not Haskell, it is largely limited. Does functional programming make sense as a discipline in application to Java? After all, in our language a very limited set of tools for this approach.
- For me rather pragmatic aspect, rather than striving for perfection is important. Perfection is curious to me, but that everything works, I must be a pragmatist. I'm crazy about Haskell and spend a lot of time with it, just to find out how a particular problem is being solved in functional programming. But for my clients, I'm not writing to Haskell. Here you can draw an analogy with the "Cathedral and the 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 put together several different paradigms, we, as programmers, need to be extremely cautious with their implementation.
I do not think that in Java functional programming is impossible at all. In those situations where there is a choice, I will focus on the language most suitable for me. But I'll never tell a client: you should use this language. Most often I ask what exactly they are doing, and I'm trying to find a way to do the same in a more optimal way within 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 it should be done very carefully. Imagine that you have a kind of circle of pure functions around which there will be a ring of impurity. Everything that you want to make mutable must be outside the circle. Within this circle, you can implement your chain of functions, but all changes must be outside of it.
This is one of the reasons why I really like learning new languages. I recently got acquainted with the Elm language, which is the Haskell syntax with F # interspersed, which is compiled into jаvascript. This approach interested me from the very beginning, because jаvascript is a bazaar. When you travel through jаvascript, you constantly step into puddles. Elm, thanks to Haskell's syntax, is uniquely a cathedral. And yet this conciliar code turns out to be possible to run in the bazaar. 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 a user performs an action (presses a key, for example), data from the view is sent to the update function, where the conversion takes place. The data is immutable, and the update function returns the new data that view stores instead of the old ones.
If you think, then exactly the same scheme operates Redux. In it, there are data and converters exist. When data is sent to reducers, you receive a new copy in return, which you save instead of the old one. But if Elm and Redux operate on 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. Learning from Redux and Elm, we can make the Java architecture more functional. I'm talking about this, because Redux compiles in jаvascript, which is definitely a bazaar. jаvascript, I think, is most remote from the ideal of functional purity, here at every step you step into a puddle. And yet, Redux gives you functional purity in this extremely unclean world. This approach influenced me greatly, because it changed my view on functional programming and showed that I can implement these principles in Java.
- Well thank you. In your opinion, is the set of tools that we have in Java is complete and sufficient? Do we need anything else besides lambda expressions, links to methods, collections with streams?
- In my opinion, we still lack a lot. The world of Java is constantly evolving. I recently had a dialogue with a man who said: "I heard that you were in our city a few years ago and argued a lot about generics," to which I replied: "I always argue a lot about generics." I believe that in Java generics are made very badly. I'm always angry with Brian Goetz: "There is always someone who complains about generics," and this someone, of course, me. In my opinion, in this area you can very much improve. Reification, in my opinion, is very important. Much can be done in terms of reducing pomposity, 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 in Java, a pattern-matching is implemented, which makes me very happy - I really like how it is implemented in Scala and Kotlin. I think that it is very important, and the analogy with the banknote processing machine comes to mind. If you pass through it a bundle of notes, it sorts them according to the value of each banknote. Similarly, the pattern matching in programming works. You skip data through parameters that can extract data for processing. I think this could help get rid of the huge number of branch statements that 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 is really curious for me. 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 can not be worse. Then I wrote for a long time in C and C ++, and most of the time from all languages I spent with C ++. After that, I started writing in Java, C #, languages like Ruby. At a certain point, I realized that I always wrote in multithreaded languages. So getting to know Node was a kind of insight - it took me a while before I figured out asynchronous programming. But, in my opinion, asynchrony is one of the most important areas in which the Java language and ecosystem can evolve. Asynchrony means coroutines and continuations. I think that Java is already moving in this direction, and this, in my opinion, is extremely important. And I'm guessing that for Java programmers it will be just as difficult to get familiar with asynchronous programming, as it was for me. My approach to programming is entirely based on parallelism, I wrote a thesis on parallel computing. Going from parallelism to asynchrony required a lot of effort for me. Now, knowing both approaches, I understand that we, as Java programmers, need to find a way to combine them. Given that the world is moving towards things like microservices, asynchrony in the long run is becoming much more important than parallelism. Java is developing in this direction, and I think this is correct.
- But do not you think that asynchronism is extremely complex and it is difficult to reach it? There is no easy way to debug an asynchronous code in the languages of the JVM platform, it can not be easily profiled. It is possible to list difficulties for a long time. What do you think of it?
- This is a very popular question, but it is not easy to discuss it. I'm ashamed to talk about this now, but I spent my youth in a debugger. The reason I'm ashamed of this right now is this: in the morning, when I came to work, I found the cursor at the same position as I left the previous evening, because I was so tired that I could not continue to debug. Over the years I have mastered development through testing, and now I do it very disciplined. I will give an example. In the application that we are currently developing with the client, we probably have millions of lambdas. This project is about Big Data. We run a parallel code that constantly fires a bunch of lambdas. As you understand, the system does not always work as expected. And yet, when this happens, we usually find out about this because the unit test does not work. Then my client places a breakpoint in the test where the error occurred, and debugs this test. Thanks to this, we debug not huge arrays of code, but individual modules.
In other words, often the inability to debug the code is a consequence not of the qualities of a certain technology, but of the insufficient modularity of the code. The more modularity, the more controllable the code becomes. This is true with respect to parallel computations and lambdas, and with respect to asynchrony. If we have several threads and it is difficult for us to debug them, this is quite expected, since multithreading is inherently nondeterministic. In fact, you open the cells in the zoo, and then try to figure out where to run to. Your task is to tame this zoo, gain control over it, and for this you need to make the code modular. The same goes for lambd. When people ask me how I debug lambdas, I answer: no way. You do not need a lambda consisting of 30 lines of code. You need a separate function for which you will have a unit test, which you debug and then call as a method reference via a lambda.
Asynchrony is beautiful, and that's why. You make a call, and indicate exactly what to do when this call is completed. But this next step does not need to be called from within an asynchronous call. The following method can be called separately for debugging and testing. And the asynchronous method itself is not necessary to perform, instead of it you can have a stub that simply checks whether the call is implemented or not. I repeat: the inability to debug the code most often is not a consequence of the properties of a particular technology, but indicates a lack of modularity of the code. And the further I work with many technologies at the same time, the more I become convinced of this and the more I find ways of active debugging, which, at the same time, allows not to lose my mind.
- That is not the case with technology. Perhaps we should change our way of thinking about such code? Rather, it's not just a matter of thoughts, but in their combination with technology. For example, the Reactive Streams specification, the implementation in the Spring Reactor project, or CQRS and event sourcing. Have you ever met with people who really enjoy CQRS?
- Yes, of course, many people use it. But, going back to what you said about changing the way of thinking - I completely agree with this. At one time I was not familiar with Angular ? and the client I worked with asked me to look at this framework. In Angular, you can write a $ character and access the global namespace. When I found out about this, my first reaction was: "What kind of stupidity. You can not do this. " I say this not to praise myself, but to the word about the raised theme of the way of thinking. Because then I started to google, and was completely amazed to learn that everyone does that. I was convinced that I would never write like that. After a few months or years - I do not remember exactly - Angular 2 came out, in which the developers confessed that this thing was really stupid and it was necessary to get rid of it.
We, as developers, are happy to learn how to work with new libraries and new technologies. But, when we do this, it is not enough to study the new syntax and the new API - it is necessary to learn the appropriate way of thinking. What should be a good code? Which anti-patterns should be avoided? These technologies are created by talented people, but it should be remembered that they are still people. And people make mistakes. That's why in Java - and in any language - there are deprecated-methods. Therefore, the time passed Angular 1 - we have found better ways to solve problems. In general, when you master a new technology, it should be done pragmatically and with a share of healthy skepticism.
Returning to another of your questions - event-driven systems, in my opinion, are the future of programming. And they work well with asynchrony, as well as with micro-services. Many of these technologies, applications, APIs and libraries have existed for a considerable number of years, but now a real boom has developed around them. Thanks to their interaction, our vision of how applications will be developed in the future is changing. If you look back in time, you will see that approximately every 5-10 years, our view of what the application architecture should be is changing. From applications for desktop computers, we moved on to server and web applications, then to mobile applications, and now we are thinking about microservices and event-oriented systems. I think that today we are in the next stage of transition. When people ask me if the future belongs to functional programming, I answer - no, it belongs to reactive programming. Because for me, reactive programming is functional programming ++. Reactivity is a composition of functions and lazy calculations in an application to a data stream. So, in my opinion, reactive programming has not fallen from the sky, but is a logical continuation of the functional one. It combines an event-oriented model, a functional composition, lazy calculations, the possibility of asynchrony. Each of these concepts in itself causes curiosity, but together they lead to fundamental changes in the architecture of applications in the future, as they change the tools and techniques that we apply.
- Well, that is, these changes are important not separately, but together.
You are a member of the Java Champions, formerly Microsoft MVP, and now write in jаvascript, so you can see three different ecosystems well. My question is: does the Java ecosystem as a whole develop or not and how does it look likein comparison with other worlds? Can we compare it to .NET, jаvascript, or anything else?
- Much, to which Java is only just moving, has been present in .NET for some time. C # was at first a slightly improved version of Java, and we said that C # is repeating everything. But today the situation is reversed. Lambs appeared in Java a few years later than LINQ, which allows to write lambdas, and which have an action and a function (what they call Func) have been added to C #. Similarly, asynchrony appeared in C # a few years earlier than a promise to add asynchrony to Java was voiced. However, it must be said that in Java since 2014 there is CompletableFuture. But asynchrony appeared in C # long before that.
Similar can be said about Java and jаvascript. I know that the phrase "we have much to learn from jаvascript" can cause fright, but jаvascript programmers have seen a lot and know how much a pound is worth. They have the concept of "callback hell", when the callbacks do not work well together, it becomes extremely difficult to handle exceptions and it is very difficult to build anything on callback functions that need to perform asynchronous calls. In the end, in the world of jаvascript, a solution was found in the form of Promises (promises), which are analogous to CompletableFutures in Java. And yet we must admit: the beauty of our world is that there is no single correct method for all time. One of the advantages of Promises is that the composition of functions is possible there. Another advantage is that they can deal with exceptions and through Promises you can skip the data. However, imagine that in your code, among other things, there are several levels of exceptions. It can become quite complex, and at some point you will realize that it would look much better if it were written in an imperative style, rather than functional. That's why jаvascript was added async and await. In essence, they are imperative shells for Promise. You can write imperative code, and when it calls a function, this call becomes asynchronous, and the code under this function is not executed immediately, but after the asynchronous function has already completed its work. With CompletableFuture, this is not possible, but with continuations in Java in the future this will be possible. And that's exactly what the coroutines in Kotlin do.
If we compare all these languages, it will become clear that I am a polyglot for purely selfish reasons. In a certain sense, programming in different languages is similar to traveling to different countries. I adore being in Russia, Estonia, India, different parts of the US, because during these trips I meet different cultures and see different practices, different ways that people solve the same problems. Therefore, I always tell the developers that one of the most important qualities of a good programmer is the understanding of the fact that there is not one single right way to write code. Of course, some methods have advantages in some situations, others - disadvantages, and we need to choose what is best suited. If you compare async in C #, async /await, and Promises in jаvascript and coroutines in Kotlin, we'll see that in some situations it's better to use a functional style, in others it's imperative, but you can implement asynchrony with both, and with another approach. It seems to me extremely curious. Java in the field of these innovations lags behind other languages. But I believe that Java is changing not only because these changes have already occurred in other languages, but also because the environment in which we create these applications is changing. The language must evolve to provide the ability to create modern applications. I think that a language that ceases to meet business requirements becomes obsolete and out of use. Java must evolve to survive. And I'm not too concerned about the fact that Java lags behind some other languages - it still has time.
I really appreciate another aspect of Java. Let's look at the lambdas. I usually say that Java was late for the holiday, but brought an excellent dessert. Lambda in Java appeared very late, but their implementation with the help of invokedynamic, in my opinion, is amazing. It improves the use of lambdas in all languages running on the JVM. Java is not an innovator in the field of languages, but it is an innovator in the search for better ways of implementation. And, in my opinion, this is a very significant advantage. I think that in the future other languages will continue to outpace Java in terms of the availability of new features, but Java will look for better, more practical and high-performance ways to implement these technologies on the JVM. And that's what we need, after all. We do not need new opportunities just for beauty, we need code that meets the requirements we have. From this perspective, the fact that Java is not developing too fast is an advantage.
- Good. Now, probably, the last question from me, and it will concern the topic of multilingualism. We live in a very complex world, you can not write anything else in 5 lines of assembler. A few lines of assembler is an unattainable ideal. From time immemorial, there were languages with flexible syntax - say Common Lisp, in which you can create your own jаvascript using Meta Object Protocol, and today there are cool ways to write DSLs like Kotlin or JetBrains MPS, with GraalVM you can soon write a Java compiler on Java and so on. If desired, you can write a project in twenty programming languages at once. How can control over complexity in a multilingual world with dynamic and changing rules every day?
- This is an extremely important issue. I always say that you should try to avoid hobbies with technology. Under the hobby I mean the feeling when you see something new and it seems to you that you absolutely must use it in your application right now. Here we as developers need to work on themselves. First, we should not learn new technology just because it is needed on the current project. Secondly, we should not apply everything that we have learned. I say this because many of the things I learned I do not apply for six or seven years. I studied these technologies not for direct application, but to have an idea of their existence. We need a certain wisdom to decide that this technology is not needed in this project. Complexity arises when we dump the various components into a bunch, not fully understanding their dignity. For example, when I come to a client's site, I always ask: why do you use it? Moreover - why are you trying to solve this problem? Why is it as important as the many other problems that you solve? Therefore, I recommend that developers take their time and understand why the technology that interests them was created. I often ask them: can you tell when and in what conditions you would use Angular, and when - React? Sometimes people can not answer, but they use React in their project. My question in this case is whether you really need it here? I'm not saying that it is not needed, but we often do not know why we use it and just do it because someone said it's necessary. Complexity arises when we use technology, not fully understanding their purpose. You can fight it by studying these technologies and comparing them with each other, evaluating the advantages and disadvantages. If the developer can not tell me the five aspects that attract him to some tool, and five - which repel, it means that he has not sufficiently studied this tool. When we see each instrument from different sides and get an unbiased view of it, we will be able to use it successfully.
The last thing I would like to say about complexity. When you evaluate technology, get rid of your emotions and desires. In our discussions, someone usually says: I like this or that technology, I want to use it. I recommend that teams draw a table and list the features that are necessary for your application: testability, scalability, asynchrony, security, and so on, depending on the application. Then opposite each write a number from 1 to 1? where 10 means "extremely important", and 1 means "it does not matter." After that, for each opportunity write a list of existing technologies and for each figure a number from 1 to 1? where 1 means "does not support", and 10 - "performs excellently". Finally, count the points and see which of the existing technologies will earn the most points. Now your emotions are not involved in the assessment, and this allows you to choose the technology you need more sensibly. You do this assessment not on a global scale or even on a firm scale, you do it based on the needs of the current project. Therefore, I do not like the statements of some companies that they have Angular, React or Java is a common standard. I always ask in such cases: for what purpose? We do not even know yet what we will do. It's like saying: our whole company will only move around on bicycles. It's meaningless. It all depends on what exactly we are doing, and this is the question that must be answered first. In general, I believe that complexity can be significantly reduced if we understand correctly what exactly we are doing and why we use this or that technology; if you get rid of emotions and desires and take account of resources and needs; if we correctly estimate the comparability of our solutions.
Finally, the last thing I would like to mention is minimalism. I always tell teams - adding things to the project is easy, removing them from the project is extremely difficult. The cost of removal is ten times higher than the cost of adding. Therefore, when adding something, you need to be sure that you are really cutting costs not only right now, but also in the long term. And you need, among other things, to think about reversibility. It's about the ability to roll back decisions made about the architecture of the application. If the solution is reversible, then tomorrow you can refuse it, and in this case you should not think too long about it. If the solution is badly reversible, then it needs to spend more time, collect more data. If we take into account the degree of reversibility of our solutions, we thereby significantly contribute to reducing the complexity of applications. In general, I believe that in many aspects we must overcome our hobby for technology in order to reduce the degree of complexity.
- Thank you, this is an excellent answer. At our Joker conference, you'll just as well say about the complexity of , so you can continue the discussion there.
- Yes, I will be waiting with enthusiasm.
