“Comparing programming languages ​​on a better-worse basis is a completely idiotic occupation.”





Disclaimer : yes, on Monday we published a habrapost with just such a comparison of languages. No, we are not crazy. Everything goes according to plan.


Vitaly Bragilevsky combines knowledge of theoretical computer science and current programming practice. He teaches disciplines related to theoretical computer science, is a member of the Haskell Standardization Committee and is a member of the supervisory committee for the development of the HHCell compiler GHC.



This habrastatya is a great interview with Vitaly on the following topics:





Interviews are conducted by members of the Program Committee of the HolyJS 2019 Moscow conference, Alexey Zolotikh and Artyom Kobzar. If the interview is not enough for you, then very soon, at the next HolyJS, Vitaly will tell and show with examples how to connect JavaScript with the theory of algorithms.



About Teaching and Getting to Know JavaScript



Artyom : Among our listeners, especially among the JavaScript community, you are not widely known, please tell us about yourself, what you do, what your hobbies are - workers, professional, perhaps non-working.



Vitaliy : I mainly teach, give a course at St. Petersburg State University and periodically participate in other works. Since I am a teacher, I had to study a lot of different topics. As it usually happens in a university, there is a need to read a particular course, and for this you need to understand all this.



It so happened that I taught a lot of things. For example, one of my very first special courses, which I was assigned in the very first year of my work, when I was very young, was called "Web XML-technologies." Then these were hot topics, Ajax just appeared in JavaScript, and there was really no literature. I explained how to use all of this.



Since then no one really understood how to use it, everything was limited to examples like this: there are two drop-down lists, a user selects an item in one of the lists, a request is sent to the server, and you receive data to fill out the second drop-down list. It was a novelty; there were so few places on sites. Then only Google search appeared in beta mode, when, while you start typing some kind of query, he tells you to continue. Ajax stuff was new, and I taught them.



What I did not teach only after that: both mathematical and programmer things. Once upon a time I came across Haskell, and since then it has become the main area of ​​attraction, which I did. In addition to teaching, studying everything in computer science in general, in order to teach, I began to collaborate with the publishing house "DMK-press", translated several books for them (with other people, I edited something myself). It was all around Haskell too. Perhaps these two types of activity - teaching and what is associated with the translation of books into Russian - this is the main thing that I did.



Artyom : That is, we directly called a JavaScript veteran to us. I found Ajax and, probably, even PHP.



Vitaliy : Yes, I even programmed in PHP in the very early years, wrote several sites.



About the reasons for choosing Haskell





Artyom : You are most famous in the Haskell community. Why did you stop at Haskell and this ecosystem?



Vitaliy : Since I never considered a programming career for myself, I was free in what I like. I did not need to be interested in what they pay more for. When I found out about Haskell, I really liked it. It’s not very good to talk about this, and somehow I even allowed myself to say something like “Haskell is a language for smart people in the English-speaking community, and the community is on average smarter”. The Americans beat me for this, and they are right. But that was exactly what I was interested in.



That is, at the time, while I was still studying at a university, I was engaged in rather rigorous mathematics, so switching to a relatively harsh programming topic was very natural for me. In general, it’s clear that now, of the programming languages ​​used in production, Haskell is one of the most science-intensive, or resource-intensive. All this abstraction that is there is closest to mathematics. Therefore, for me it was a natural choice.



About functional languages ​​and their place in the world of programmers



Alexei : How do you feel about dynamic and functional languages? What about Lisp-like things?



Vitaliy : I like to position myself not so much as a Haskellist, but as a lover of programming languages ​​in general. Firstly, it is clear that all languages ​​have a right to exist. I believe that comparing programming languages ​​on a “better-worse” basis is a completely idiotic occupation. Unfortunately, this is often done in social networks and not only, but this makes no sense.



I like to learn the features of programming languages ​​and somehow classify programming languages ​​by these features. But to consider that this is a good feature, and this is bad is stupid. Therefore, it is clear that languages ​​with dynamic typing certainly have a right to exist. For example, I now in my course for freshmen took the Julia programming language as a basis. This is a dynamic language, there is a type system. It was interesting for me to teach him, at the same time to see this area of ​​applicability.



In general, the first functional language I came across was Lisp. When I read the book “The Structure and Interpretation of Computer Programs” many years ago, of course, this all impresses. Therefore, I have great interest in all of this. For example, I also have great love for JavaScript, because I know its history well.



I know that when it first appeared, it should have been something like Lisp, because at first the original syntax was Scheme-like. And then, rather, for some marketing reasons, it was replaced by a C-like one, but, of course, Lisp languages ​​are sitting inside, and it impresses me.



In general, I have the feeling that many JavaScript lovers do not know this, and they are fine, but I know, so I am even better. So all languages ​​are good, and it’s interesting for me to study them, it’s interesting to study the field of applicability, it’s interesting to see what is easier and more convenient on them. In general, such a comparison of languages ​​for individual tasks is also a separate interesting area, which I like to deal with.



What's good about JavaScript



Artyom : While you were preparing the report, you were in contact with the new versions of JavaScript, so that they were embedded in it. From the point of view of the theory of programming languages, what can you single out good, bad, perhaps some interesting solution?



Vitaliy : Evaluating from the point of view of the variety of programming languages, of course, the most interesting thing in JavaScript is its object model. This is what was from the very beginning. The prototype model has a very rich history, it is super interesting because almost no other modern languages ​​have it now.



In languages ​​like C #, using extension methods, they solve the problem of adding methods to existing objects. This is what JavaScript has been from the very beginning, and there it looks much more natural. That is, we have a prototype to which we add methods and then create new objects based on it. In languages ​​like C #, this is more artificial, in my opinion.



I was interested to see how modules are added to JS. In JavaScript, for a very long time there have been problems associated with modules, for decades, you can say, and I wonder how they started to do all this. Because modules are a deep theoretical topic, there are many different approaches to their implementation. True, I cannot say that I thoroughly studied this, but this is what seems to me an interesting case in the field of development of programming languages. That is, how to add features to the existing language that were not there before.



This is still interesting, because several years ago in Haskell there was an attempt to add, say, more correct modules. Now we can say that this attempt failed, no one began to use it. This is the so-called backpack project, that is, it seems to be implemented, but the use is so insignificant that it became clear that they made a good new modular system, but it did not work out very well.



I have the feeling from talking with different guys who are engaged in JavaScript that the modules in JS turned out better. True, I know this very superficially. I think the opinion about JavaScript is very much influenced by the fact that you can write very bad code there. And if you can write very bad code, someone must write it in large quantities. This negatively affects the assessment of the language. From the point of view of the theory of programming languages, this, of course, is not very good.



Alexey : Did you manage to see the latest JavaScript versions? What surprised besides the module system?



Vitaliy : I can’t say that I succeeded. I flipped through something, but not very deep. I can not list.



What will appear in programming languages ​​in the near future





Artyom : The theory of programming languages ​​is a rather academic environment and, in principle, interesting. What are the new features in languages ​​that are about to appear in 10-15 years? What research is being done in this area?



Vitaliy : I would say that the hottest topic right now is gradual typing. This is when both the typed parts and the untyped parts exist in the program at the same time. It is for Python, for JavaScript, it is done for toy languages. That is, we can, firstly, combine typed and untyped parts, and secondly, we have a simple way to expand typing.



That is, we are doing a prototype implementation of something, as it has always been done in dynamic languages ​​without any types, and then we start to hang types on individual components, more and more. Ideally, we get a typed program with all the benefits. There are fewer errors at run time and so on.



This is perhaps one of the most important developments. Some elements are already in the form of libraries, but so far this is still an area of ​​research. If we watch leading conferences on programming languages, there are sure to be several sections devoted to gradual typing, typing. This is something that will almost certainly be included in most dynamic languages, because it is very convenient. It turns out the combination of two worlds.



For ten years now, research has been going on dependent types, when the type depends on the values. The biggest problem is that it erases the line between the compilation stage and the execution stage, because at the compilation stage specific values ​​are not yet known, but types need to be checked. That is, specific values ​​appear in runtime, but the types should already be correct.



And there you already need to write a function in which, depending on the value passed, the type of result changes. This blurring of the border between runtime and compilation time is a very interesting thing, it is also now in theory already being actively studied for 10-15 years and will almost certainly fall into many languages, primarily statically typed ones, because the expressive type system thanks to this development is significantly increased.



True, there is a downside. It turns out that writing programs can be too complicated. It seems that the types control everything, but writing is very difficult, so sometimes you think that to hell with these dependent types, take some type any and program it.



Artyom : They do it here.



Vitaliy : This can also be done with a great desire, just sometimes there is nowhere to go. When you get from the server, don’t understand what, and until you start the program, you don’t know, you still have to use such things, even in Haskell, there’s nowhere to go.



How Vitaly develops Haskell





Artyom : Funny. Back to Haskell. You are a member of the Haskell 2020 committee. At Podlodka, you said that you didn't do anything there, but in one interview you mentioned that you are still working on simple, limited families of functions. What other specific things do you implement, oversee or participate in the implementation of, perhaps, the new Haskell standard?



Vitaliy : These are two different committees. I have two committees. One is Haskell 2020, in which nothing really happens, it is a dead committee. Its purpose is to write a language standard, and it will certainly not be written. It sounds better - “Committee for the development of a language standard”, but does not work.



The second committee is called the “GHC Compiler Supervisory Committee” - the Glasgow Haskell Compiler. I have been in it for a little over a year, his task is much less ambitious. This committee considers features, suggestions for changing the compiler and the version of the language that is implemented in this compiler. There is a standard Haskell, but there is a Haskell implemented by a specific compiler. Here is an example of such a language extension: “simple type families”. This is an attempt to facilitate type-level programming by adding additional controls.



True, I have to say that there is a fairly free environment, that is, I probably did not follow any props all summer and owed a lot of my time to this committee, I plan to return to this.



My task there is this - shefed it: I have the described proposal, I need to look, maybe advise the author to finalize something and finally go to the committee with a proposal either to recommend inclusion in the compiler, or refuse. After I submit this proposal, the committee discusses and makes a decision - everything is decided collectively there.



One of the sentences that I owe is related to the underscore in standard annotations. When you can not specify the type completely, that is, there are holes there, and there is a proposal to reform this system in order to somehow analyze everything uniformly. Holes can be in standard annotations, in the implementation of functions. A certain unified approach is proposed.



This committee considers narrow changes in the compiler.



Artyom : We also have a standardization committee - TC39. At first, a certain one comes and he is looking for a champion. A champion is a person from a committee who is ready to oversee this site. Then, as far as I know, we have a graduation by stages. There are 4 stages on which the feature moves. Zero is when there is only a proposal, one is when a champion is found and a high-level API is described, and so on. Fourth - it is already recorded in the language. The person who did the preposing, and the curator participate in the meetings of this committee and promote this propoundation. How is this going on with you? Is it just a committee then decides internally?



Vitaliy : All our activity is open, it is conducted on GitHub and partially in open mailing lists. The author of the proposal comes in - while we are considering the proposal, we are not very interested in the implementation. It may be, it may not be, we do not analyze it in any way, nothing depends on it. First, there is a discussion by the wide community, everyone can comment on this proposal.



Then, when he settled down, the author submits it to the committee, that is, asks the committee to consider it. The committee secretary appoints a shepherd who will oversee him. He looks, analyzes, maybe offers improvements or, on the contrary, tries to justify why this does not have a right to exist, after which he comes out with a proposal to reject or, maybe, send for revision, or accept. The committee discusses, makes a decision.



And when the committee decides that we agree with this pre-site, and it passes into the status of accepted, in principle, anyone can take up its implementation. Up to this point, there may be no implementation, we just make a decision - yes, it would be nice to have such a feature in the language or compiler, and we have such a list of accepted, but not implemented, sub-nodes.



Further, this is no longer the task of the committee, then anyone makes a pull request to the source code of the compiler, there are engineers there, the team partially intersects with the committee, those who will already decide whether this pull request is accepted or not.



Since the committee agrees to accept this, that is, in principle, it is necessary to accept the merge request, but there are engineering questions, it is not encoded there, some performance problems are solved by the team that directly develops the compiler. This is no longer our job.



Alexei : It turns out that now Haskell has quite old standards. I see there is Haskell 2010.



Vitaliy : Yes, 2010, very old. There have been several attempts to write a new one. There was an idea to issue standards every year, but, unfortunately, it all failed. In 2016, a 2020 committee convened, but he also did nothing. There are several reasons of varying degrees of difficulty, why this work is not ongoing. Yes, the latest standard of 2010, there is no new one and it is not visible that it will appear.



About courses and new projects



Artyom : Let's get back to your main activity, to teaching. I personally met you at the course of category theory, which I really like. You say you don't like him. What other courses do you have that you might be proud of and the ones you think it would be nice to meet? For example, the course may have been with jambs, but in principle, the narrative program itself is very good.



Vitaly : Firstly, I have published on YouTube all the courses that I have. There I have a course on Idris - this is such a programming language with dependent types, and even two versions, I read it twice. I also have a couple of Haskell language compiler courses there. One is devoted to model-theoretical issues. I don’t remember exactly the name, but there it is about how type theory works directly in the Haskell compiler.



The idea is simple: all Haskell code is compiled into some fairly simple λ-calculus, the so-called F system with small extensions. This is actually in the compiler code, and the course focuses on how these elements of type theory are used directly in the compiler.



And there is a course in which I generally tell about the history of type inference and how type inference was arranged at the very beginning, when it was invented in the 60s, before type inference is arranged in the Haskell language, what are the difficulties how it all works.



There is a short course that I taught at the summer school of mathematics. There, from time to time, as I was told, they take computer science courses so that the children rest. And high school and junior students gather there, and the Olympiads, they are all terribly smart, all cool mathematicians, they have terrible courses on the most modern things: algebraic geometry and all that. I was taken there with a course on Curry-Howard correspondence - this is such a correspondence between mathematical logic and type theory. This is an entertaining course of four lectures, I separately tell the elements of the logic, separately the elements of type theory and then show how they are closely related.



Perhaps this is what is recorded. That's how I read many courses in my life, but these are usually university courses, and they weren’t written, because I honestly don’t really like to write courses, because it’s something so dead. When you read a course, sometimes you’ll talk some nonsense, and then all that is written down is exposed to the whole world. I read the course, and then they poke you for many years that you said stupidity in such and such a place in such and such a lecture. I really don't like it.



With a course in category theory, there is exactly such a story. Firstly, it’s very difficult when you read a course for the first time, read it normally, you don’t know how to finish it. It is necessary to take into account all its methodological features, dependencies. It’s like writing a program, only there is some big stage of planning, some features, but here it’s kind of like planning something, but the course is on, it develops by itself independently of you. And then you read something wrong, didn’t tell, something should have been there, what you need now. Well, there are a lot of such dependencies and holes. If I read it a second time, I probably would have done it much better.



But now the first copy has remained on the Internet, which, in my opinion, is terrible. The organizer of this course, who wrote down, said that the first lecture has many views, this is the most popular in terms of the number of views in this category in RuNet, but I do not like it, I do not revise this course.



Alexei : Is it worth the wait for something new? Because, as we see, sometimes it helps a lot. Artyom was inspired, in general, I liked it, we would like to see something else.



Vitaliy : I just recently started planning a new course for Computer Science Club. It happens to me that for the last three springs I have been reading courses in St. Petersburg there, they are being recorded, so the material remains in eternity. Again, there I pursue my interests.



This will be a course of 10 lectures. I came up with the name "GHC Haskell Compiler: Introductory Course". I have a few short stories about the GHC compiler, a couple of stories at the conference, about 40 minutes each, and this is an introductory course of 10 lectures. I want to talk about all aspects of the compiler from the very beginning: from parsing text to code generation.



That is, this course seems to be about the development of a specific compiler, but in fact with the specifics of Haskell, this is what will be new. I still have an idea to do the second iteration of the course on category theory, maybe in the spring. But with a little emphasis.



The first time I read it, so that students of 1-2 courses who were interested in mathematics could understand it. There were examples with math and all that. And in the second iteration, maybe I would have stolen the idea of Bartosz Milewski on courses for programmers. I don’t really like the way he says: well, teachers are such guys, they don’t like their courses, but others’s even more so. So I want to make my version of the category theory course for programmers, so that anyone can figure it out.



True, I don’t know whether I will do it or not, there are such thoughts. After the first year in category theory, I vowed that I would never tell anyone the category theory again, but it pulls me a little. This is what the plans have.



The compiler will definitely work out, because I needed a place where I would send students who sign up for projects with me so that they would look at first before coming. And as for category theory, I don’t know if I’ll get together or not.



Artyom : As far as I know, you also say some things related to academic disciplines in JetBrains. Are there any entries from there? Maybe you can see something from there?



Vitaliy : In JetBrains I made an internal report once, it was dedicated to Haskell and the like, how JetBrains tools can be used in Haskell development, but did nothing else.



Artyom : Haskell tools in JetBrains?



Vitaliy : I mean developing on Haskell using the JetBrains tools, I did an overview of plugins. But this was an internal report, it is not published.



Artyom : Is there any Haskell in JetBrains?



Vitaliy : In the sense, does anyone program on Haskell in JetBrains products? I think not.



Artyom : Sorry, they do not know the charms. (laughs)



Vitaliy : There are mostly Javists. There are other guys, but mostly Java, they are not up to Haskell.



Artyom : As far as I know, did you resize inside JetBrains?



Vitaly : I officially have it called JetBrains Education. That is, JetBrains Research - separately, and Education - separately.



About JavaScript





Alexey : How do you feel about the things that live in the browser, for example, compilation in JavaScript? And, accordingly, related things, such as Elm, which cannot be called pure Haskell.



Vitaliy : First of all, all the movement in this direction makes me very happy. I did not come across GHCJS, or rather, I came across stories about how bad everything is. About Elm, I kinda heard that everything is fine and this is a stripped-down Haskell, all that. I have a very positive attitude, and in general I like the idea that you write in some language and translate it all into another language.



As I understand it, performance problems often arise there, that is, the generated code is so heavy that it runs slowly. But I look at all the compilation experiments in JavaScript with great interest.



For example, the Idris language has many backends - and they can compile Idris in PHP, in JavaScript, and this is very interesting. Interlanguage life is beautiful. You can probably compile JavaScript in Haskell.



In general, programming languages ​​are interesting, and some kind of compiler that compiles native code is a well-known area for everyone, and when we compile one language into another, it’s super interesting, millions of tasks.



Millions of programming languages ​​are, say, tens of millions of tasks, and each is very original, because everywhere its own aspects arise. And interestingly, it has long-standing roots. Again, in a report on HolyJS I will talk about different calculation models, and for calculation models the main theorems are that two calculation models are equivalent, and in order to prove this equivalence factor, you need to program the second one on the calculation model and vice versa . When they are made in both directions, we obtain the theorem that both models are equal.



The first such work was done at one time by Alan Turing, who expressed the Turing machine in the λ-calculus, and the λ-calculus in it, and proved that these are two equivalent models, because in time it happened. He came up with his Turing machine, and then he was shown the λ-calculus, and he needed to prove that these are equivalent things.



It was in 1936, and since then, in a sense, the task of converting from one language to another is a continuation of exactly the same task of proving the equivalence of calculi. Since there are many languages, the task is also interesting.



What languages ​​are used in production and why





Artyom : And what general languages ​​can you single out that are used everywhere in production? So, you singled out Swift in the Submarine, said that there enum are very interesting, which are equivalent to Union, what other similar languages ​​are theoretically very well designed?



Vitaly : I don’t know, in general, a very holistic question. I recently became convinced: what one person calls well-designed from the point of view of theory, the other considers ugly designed. For example, just recently, I heard such a statement that Python was designed in full accordance with the theory of programming languages, and that Guido van Rossum was engaged in this theory and decided to make a language that fully complies with these principles.



I was very surprised because I can roughly imagine what Python is and what the theory of programming languages ​​is. In general, I would not correlate one with the other, but nevertheless, such an opinion also exists.



I have to say that the languages ​​that have been appearing for the last ten years, especially the languages ​​that are developed by large companies, all look very good. Of the most notable and big languages, I want to mention C #. How C # appears: firstly, Microsoft took into account all Java problems, invited super-smart people, for example, Anders Halesberg , who at one time made Delphi, helped with C #, Eric Meyer, who was known from the first Haskell committee person in our community.



That is, they gather large scientists, and they make decent languages ​​without holes. It's clear that the JetBrains, which makes Kotlin, also try to do well. Kotlin, C #, Swift from Apple, which has no complaints from the point of view of theory. At least I haven’t heard anything like this.



C ++ lives its own life, and, in general, it is somehow difficult to evaluate it, because many decisions in it cannot be made otherwise, and there really very smart people deal with it, they know better. By the way, I don’t really understand how JavaScript is developing, so I can’t appreciate it. That’s probably all.



Now I trust in this matter large companies that make new languages, because they are serious about this.



Artyom : For some reason, when you started talking about a large company that makes a good language, I immediately thought about Mozilla and Rust.



Vitaliy : Well, Mozilla is not that the company is, it is still an open source community, it is a little different. I trust them to a lesser extent. But on the other hand, I know very little about Rust, I heard good and bad reviews. Sometimes there is a feeling that they make such a Frankenstein from Rust, connecting some unconnected things, we'll see.



On the other hand, recently there was a discussion on Twitter - someone from one of the Microsoft security code divisions said that we need to leave C ++ and all Microsoft should switch to Rust. Possible opinion, yes. But there it was due to the fact that safe programs are easier to write in Rust. They, in general, know better, but I do not think that this will happen in the foreseeable future. In any case, such opinions do arise.



But in general, Rust refers to languages ​​that I will need to look very carefully at some time, while this is in the plans.



How scientific conferences differ from programming





Artyom : Conference! You, for sure, participated not only in programming conferences, but, probably, in scientific ones either you participated or spoke. , , , - , ?



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



— , , -, , . , .



, , , . , , . . , , , , . - . . .



: ? , , , , , ?



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



, — .







: HolyJS ? , - ? , .



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



, , AppsConf. . . , .



, , , . : « , ?». - , , : , , Twitter , Google . , .



. , , , , , , , .



, , , . — , .







: , . Haskell, Haskell in Depth ?



: , , . « ». , , , . - , , , .



: : , , , , . , , ? , , , ?



: , , , JavaScript — -, . Haskell . .



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



. - - , , . , , - , . , .



, . - , , , , . . , .



- , , . , - , . , , - . , JavaScript. - , point of reference, .



, , Haskell, , . , , .



, . , C++, , . C++ , , , .



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



: , , - . , — Twitter. , Twitter. - , . , Haskell , , .



- Reddit , - , . Twitter , , . , — , .



, - IT, , , , . , , — http://lambda-the-ultimate.org . . must read , .







: , . must have-, , , ? , .



: , , .



, , « » . , . , .



, « » . , , , . .



«Annotated Turing» . : 1936 , , , , . 15. , , . , .



, . , . , , . λ- , , , .



, , « » . , . , , . , .



, , , , . , , , , . .



, Swift, Kotlin, - Java, , - . . , . , , : «, - , -, . , , ».



, , .



: : «Modern Compiler Implementation», — Java , C ML .



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



. - , . , « » — , . , .



Vitaly Bragilevsky will come to the HolyJS 2019 Moscow conference on November 8-9, 2019 with a report “JavaScript in the service of theoretical informatics.” Tickets can be purchased on the official website .



All Articles