Posts: 2020
Threads: 133
Joined: July 26, 2017
Reputation:
5
Compiler Theory
October 23, 2020 at 6:38 am
(This post was last modified: October 23, 2020 at 6:40 am by FlatAssembler.
Edit Reason: The quotes are now in italic.
)
Yesterday evening, I've published a video in which I try to explain the basic concepts of the compiler theory: https://youtu.be/Br6Zh3Rczig
What do you think about it?
Also, what do you think, does studying compiler theory help with programming in general? If you asked me this a year ago, I would say it certainly does. Now I am not so sure. I see that many people, most of which haven't studied the compiler theory, learn programming a lot faster than I do. I sometimes ask myself if it is because I've studied some compiler theory, rather than in spite of it. When trying to learn a programming language (such as MatLab or VHDL), I often find myself thinking " Wait, that seems impossible. How can that possibly be implemented in the compiler? I must have misunderstood something.", only to find that I didn't misunderstand it, and that the compiler somehow manages to compile that (even though I have no idea how I'd implement something like that in my compiler). Maybe I waste a lot of time on that and maybe I somehow need to turn off that kind of thinking in order to be a good programmer?
For example, I recently tried to learn some ReactJS and, of course, some advanced JavaScript. I thought it would be relatively easy, because I already knew some JavaScript, I've made a PacMan in JavaScript and a compiler for my language targeting x86 in JavaScript. But it wasn't easy for me. Soon after starting learning ReactJS, I bumped into something like this:
Code: const header=<h1>Hello world!</h1>;
I thought " Aha, that's some new syntax in JavaScript.". So I tried typing that into NodeJS, only to get a bunch of syntax errors. So I was thinking " What? If JavaScript engines can't parse the code when the ReactJS framework is not included, how can they possibly parse it when it is included? A framework can't possibly modify how the parser behaves, it starts executing only after the parsing phase has long passed. I don't get it.". Then came some importing CSS into JavaScript. I thought " What? How can that possibly work? JavaScript engines don't know anything about CSS. If you include a CSS file in JavaScript, it won't even tokenize (an identifier can't contain a '#' in JavaScript, but it can do so in CSS), yet alone parse and semantically analyze. I don't get it.". Then I saw the syntax for declaring properties of classes in JavaScript. In the example I saw, the declarations are separated with nothing but a new-line character. I thought: " What? But JavaScript is not a whitespace-sensitive language. How could this possibly work? How can the parser know where one declaration ends and where another declaration starts if they are not separated by a semicolon or a comma?". I thought it was too much for me, so I gave up.
So, maybe thinking about compiler theory is a very wrong way to think about the programming language you are studying. I was wondering what you thought about it.
Posts: 1664
Threads: 5
Joined: September 26, 2018
Reputation:
12
RE: Compiler Theory
October 23, 2020 at 4:36 pm
(October 23, 2020 at 6:38 am)FlatAssembler Wrote: But it wasn't easy for me. Soon after starting learning ReactJS, I bumped into something like this:
Code: const header=<h1>Hello world!</h1>;
I thought "Aha, that's some new syntax in JavaScript.". So I tried typing that into NodeJS, only to get a bunch of syntax errors. So I was thinking "What? If JavaScript engines can't parse the code when the ReactJS framework is not included, how can they possibly parse it when it is included? A framework can't possibly modify how the parser behaves, it starts executing only after the parsing phase has long passed. I don't get it.". Then came some importing CSS into JavaScript. I thought "What? How can that possibly work? JavaScript engines don't know anything about CSS. If you include a CSS file in JavaScript, it won't even tokenize (an identifier can't contain a '#' in JavaScript, but it can do so in CSS), yet alone parse and semantically analyze. I don't get it.". Then I saw the syntax for declaring properties of classes in JavaScript. In the example I saw, the declarations are separated with nothing but a new-line character. I thought: "What? But JavaScript is not a whitespace-sensitive language. How could this possibly work? How can the parser know where one declaration ends and where another declaration starts if they are not separated by a semicolon or a comma?". I thought it was too much for me, so I gave up.
So, maybe thinking about compiler theory is a very wrong way to think about the programming language you are studying. I was wondering what you thought about it.
That code was JSX, not Javascript. It needs to be compiled by Babel into Javascript React.createElement() calls.
And, Javascript now has optional semicolons at the end of lines, in circumastances where the parser can figure out that the semicolon should've been there. I think that's just lazy coding, but some people absolutely hate semicolons if they've never used a language that needs them (i.e. Python).
Real-world Javascript programs use a kitchen sink of tools these days. It is the most confusing way to learn programming.
Posts: 2020
Threads: 133
Joined: July 26, 2017
Reputation:
5
RE: Compiler Theory
October 24, 2020 at 4:20 am
(October 23, 2020 at 4:36 pm)HappySkeptic Wrote: (October 23, 2020 at 6:38 am)FlatAssembler Wrote: But it wasn't easy for me. Soon after starting learning ReactJS, I bumped into something like this:
Code: const header=<h1>Hello world!</h1>;
I thought "Aha, that's some new syntax in JavaScript.". So I tried typing that into NodeJS, only to get a bunch of syntax errors. So I was thinking "What? If JavaScript engines can't parse the code when the ReactJS framework is not included, how can they possibly parse it when it is included? A framework can't possibly modify how the parser behaves, it starts executing only after the parsing phase has long passed. I don't get it.". Then came some importing CSS into JavaScript. I thought "What? How can that possibly work? JavaScript engines don't know anything about CSS. If you include a CSS file in JavaScript, it won't even tokenize (an identifier can't contain a '#' in JavaScript, but it can do so in CSS), yet alone parse and semantically analyze. I don't get it.". Then I saw the syntax for declaring properties of classes in JavaScript. In the example I saw, the declarations are separated with nothing but a new-line character. I thought: "What? But JavaScript is not a whitespace-sensitive language. How could this possibly work? How can the parser know where one declaration ends and where another declaration starts if they are not separated by a semicolon or a comma?". I thought it was too much for me, so I gave up.
So, maybe thinking about compiler theory is a very wrong way to think about the programming language you are studying. I was wondering what you thought about it.
That code was JSX, not Javascript. It needs to be compiled by Babel into Javascript React.createElement() calls.
And, Javascript now has optional semicolons at the end of lines, in circumastances where the parser can figure out that the semicolon should've been there. I think that's just lazy coding, but some people absolutely hate semicolons if they've never used a language that needs them (i.e. Python).
Real-world Javascript programs use a kitchen sink of tools these days. It is the most confusing way to learn programming.
So, what do you think, is making compilers for your programming language (like I did) likely to make you a better programmer? Or is it likely to make you worse?
Posts: 1664
Threads: 5
Joined: September 26, 2018
Reputation:
12
RE: Compiler Theory
October 26, 2020 at 11:18 am
(October 24, 2020 at 4:20 am)FlatAssembler Wrote: So, what do you think, is making compilers for your programming language (like I did) likely to make you a better programmer? Or is it likely to make you worse?
I think it should make you better, if it helps you understand how the syntax is formed. Just try not to focus too much on HOW the parser does its work
Posts: 2020
Threads: 133
Joined: July 26, 2017
Reputation:
5
RE: Compiler Theory
October 26, 2020 at 3:40 pm
(October 26, 2020 at 11:18 am)HappySkeptic Wrote: (October 24, 2020 at 4:20 am)FlatAssembler Wrote: So, what do you think, is making compilers for your programming language (like I did) likely to make you a better programmer? Or is it likely to make you worse?
I think it should make you better, if it helps you understand how the syntax is formed. Just try not to focus too much on HOW the parser does its work
Maybe that's the problem. I've written the parser for my programming language by hand. And somehow I usually assume that's how it's done. But usually it isn't. Usually, the parsers are written using tools such as YACC or BISON, which, as far as I understand it, make it easy to write complicated grammar rules which are not at all obvious how to implement in a hand-written parser.
Posts: 29715
Threads: 116
Joined: February 22, 2011
Reputation:
159
RE: Compiler Theory
October 27, 2020 at 10:48 am
When I was in school, compiler theory was a favorite topic of mine. I couldn't get enough of it. Nowadays, the idea of watching a video about it just leaves me cold.
|