Interview with Ryan Dahl. Part one
This interview was conducted by Oleg Podsechin with Ryan Dahl on July 8, 2010, shortly after reading Ryan in Cologne. Oleg is a JavaScript enthusiast who manages Ionsquare Ltd, which specializes in IT consulting.
OP: The first question is really introductory. How did you come to Node.JS? Have you had any previous JavaScript experience? When did you start working with javascript? Also with event-driven software?
RD: I worked on a contract, and did various small C projects, usually server-based event-driven software, and I realized that I was writing the same code over and over again. C is a great language for work, but I wanted something that allows me to write scripts in the same style in which I usually program server software.
')
O. P .: Have you done anything for the client side using JavaScript?
RD: A little. I worked a lot with Ruby on Rails - so I often dealt with the front end. Then I wrote a small Ruby web server called Ebb, which should have been faster than Mongrel. This code was the starting point for Node.
OP: Ebb is mostly written in C? So you first wrote it in Ruby, then rewrote it in C, and now you end up rewriting it in JavaScript?
RD: Right. So it was originally Ruby, then C. For some time I was playing with the idea of ​​having a small C library for creating web servers, but in C it’s hard to do something like that. One day, an insight came upon me: "JavaScript is the language that is suitable for this application." This happened shortly after the V8 was released.
OP: You said that there are two languages ​​that will always be around us: C and JavaScript. So, what do you think about javascript as a common programming language?
RD: JavaScript has certain characteristics that make it very different from other dynamic languages, namely that it has no idea about the execution threads (threads). His concurrency model is completely event based. This makes it somewhat different from other dynamic general purpose programming languages ​​such as Ruby and Python. At least for certain classes of tasks, I found that it is much easier to program in JavaScript, for example, when writing an IRC server.
O. P .: How do you see the future of JavaScript? Do you think that JavaScript is becoming more common, and not only on servers, but also on desktop computers?
RD: JavaScript is already doing a great job creating GUIs. I think with a familiar browser-like API, JavaScript can also be a good language for desktop applications.
O. P .: JavaScript is weakly structured, so people just copy and paste JavaScript code ...
RD: Yes, the lack of infrastructure of the modules interferes. JavaScript really makes people keep everything in global variables. This is a real disaster for JavaScript, but in the end, best practices can overcome these kinds of problems.
OP: Yes, are you watching the discussion regarding ECMAScript 4 and ECMAScript 5?
RD: I agree with Crockford that the language should be simple. One of the best qualities in javascript is its simplicity. It defines not so many concepts on how to do certain things, in particular, regarding input / output. Although ECMAScript 4 does not define any I / O APIs, it defines many more. She identified many crucial changes. However, I would like ECMAScript 5 to have some more features.
O. P .: What exactly are the possibilities you mean?
RD: What is it called? Destructive assignment? If you have an array on the right and a list of variables on the left, and they can be defined this way. That would be good.
OP: This is included in the Rhino, but not in the V8.
O. P .: So, let's go to Node. What is the most difficult architectural decision that you have made in relation to the project?
RD: What turned out to be the most difficult for me ... My initial idea was that it would be a purely non-blocking system, and I had to abandon it in many ways, in the module system and in some other areas. In browsers, loading JavaScript via a script tag is a non-blocking operation. You really do not know when the scripts are fully executed, until OnLoad is called. Initially, Node worked similarly. You could load a bunch of module files, and you didn't know that they were already fully interpreted until the loaded event was generated. It made everything a bit more complicated. You could not just execute “require” and start using that code right after this operation; you had to wait for the callback before you started using the downloaded code.
OP: The application “Hello, world!” Took another indent.
RD: Right.
OP: But this is funny because people say that one of the advantages offered by JavaScript is that you can use it everywhere as well as in the browser. You can use the same data validation logic as on the server as in the browser, but the CommonJS module specification does not work in the browser, so there are attempts to create libraries with asynchronous module loading.
RD: Yes, so from the point of view of the complexity of choosing architectural solutions, I wanted Node to be similar to the browser environment. Maybe he does not use the same methods, but the same structures can easily be ported if you create methods with similar names. Initially, Node achieved what was completely browser-like. In the first versions, he even defined the “window” object. Over time, I deleted this API, as it turned out that it was not necessary that the server environment was exactly the same as the browser environment. So I chose the CommonJS module system, which is very reasonable; The guys from the CommonJS group paid a lot of attention to the system of modules, and I really didn’t want to spend too much time thinking through my own version. So yes, require is a blocking operation, and there are some other minor operations that use locking in Node. In general, this pragmatic approach, to perform non-blocking operations 99% of the time, but allowing several simultaneous operations, works well. The fact that you load modules synchronously probably does not matter for the server program.
OP: The first question is really introductory. How did you come to Node.JS? Have you had any previous JavaScript experience? When did you start working with javascript? Also with event-driven software?
RD: I worked on a contract, and did various small C projects, usually server-based event-driven software, and I realized that I was writing the same code over and over again. C is a great language for work, but I wanted something that allows me to write scripts in the same style in which I usually program server software.
')
O. P .: Have you done anything for the client side using JavaScript?
RD: A little. I worked a lot with Ruby on Rails - so I often dealt with the front end. Then I wrote a small Ruby web server called Ebb, which should have been faster than Mongrel. This code was the starting point for Node.
OP: Ebb is mostly written in C? So you first wrote it in Ruby, then rewrote it in C, and now you end up rewriting it in JavaScript?
RD: Right. So it was originally Ruby, then C. For some time I was playing with the idea of ​​having a small C library for creating web servers, but in C it’s hard to do something like that. One day, an insight came upon me: "JavaScript is the language that is suitable for this application." This happened shortly after the V8 was released.
OP: You said that there are two languages ​​that will always be around us: C and JavaScript. So, what do you think about javascript as a common programming language?
RD: JavaScript has certain characteristics that make it very different from other dynamic languages, namely that it has no idea about the execution threads (threads). His concurrency model is completely event based. This makes it somewhat different from other dynamic general purpose programming languages ​​such as Ruby and Python. At least for certain classes of tasks, I found that it is much easier to program in JavaScript, for example, when writing an IRC server.
O. P .: How do you see the future of JavaScript? Do you think that JavaScript is becoming more common, and not only on servers, but also on desktop computers?
RD: JavaScript is already doing a great job creating GUIs. I think with a familiar browser-like API, JavaScript can also be a good language for desktop applications.
O. P .: JavaScript is weakly structured, so people just copy and paste JavaScript code ...
RD: Yes, the lack of infrastructure of the modules interferes. JavaScript really makes people keep everything in global variables. This is a real disaster for JavaScript, but in the end, best practices can overcome these kinds of problems.
OP: Yes, are you watching the discussion regarding ECMAScript 4 and ECMAScript 5?
RD: I agree with Crockford that the language should be simple. One of the best qualities in javascript is its simplicity. It defines not so many concepts on how to do certain things, in particular, regarding input / output. Although ECMAScript 4 does not define any I / O APIs, it defines many more. She identified many crucial changes. However, I would like ECMAScript 5 to have some more features.
O. P .: What exactly are the possibilities you mean?
RD: What is it called? Destructive assignment? If you have an array on the right and a list of variables on the left, and they can be defined this way. That would be good.
OP: This is included in the Rhino, but not in the V8.
O. P .: So, let's go to Node. What is the most difficult architectural decision that you have made in relation to the project?
RD: What turned out to be the most difficult for me ... My initial idea was that it would be a purely non-blocking system, and I had to abandon it in many ways, in the module system and in some other areas. In browsers, loading JavaScript via a script tag is a non-blocking operation. You really do not know when the scripts are fully executed, until OnLoad is called. Initially, Node worked similarly. You could load a bunch of module files, and you didn't know that they were already fully interpreted until the loaded event was generated. It made everything a bit more complicated. You could not just execute “require” and start using that code right after this operation; you had to wait for the callback before you started using the downloaded code.
OP: The application “Hello, world!” Took another indent.
RD: Right.
OP: But this is funny because people say that one of the advantages offered by JavaScript is that you can use it everywhere as well as in the browser. You can use the same data validation logic as on the server as in the browser, but the CommonJS module specification does not work in the browser, so there are attempts to create libraries with asynchronous module loading.
RD: Yes, so from the point of view of the complexity of choosing architectural solutions, I wanted Node to be similar to the browser environment. Maybe he does not use the same methods, but the same structures can easily be ported if you create methods with similar names. Initially, Node achieved what was completely browser-like. In the first versions, he even defined the “window” object. Over time, I deleted this API, as it turned out that it was not necessary that the server environment was exactly the same as the browser environment. So I chose the CommonJS module system, which is very reasonable; The guys from the CommonJS group paid a lot of attention to the system of modules, and I really didn’t want to spend too much time thinking through my own version. So yes, require is a blocking operation, and there are some other minor operations that use locking in Node. In general, this pragmatic approach, to perform non-blocking operations 99% of the time, but allowing several simultaneous operations, works well. The fact that you load modules synchronously probably does not matter for the server program.
Source: https://habr.com/ru/post/127216/
All Articles