6 ms·

Could someone who has taken a decent compiler course and been in the industry a few years comment on how / why this course would be beneficial? There are a lot

Could someone who has taken a decent compiler course and been in the industry a few years comment on how / why this course would be beneficial? There are a lot of things I'd like to look into these days, but only so much time. And I do realize that some courses I took in University a decade ago were far more valuable than others (e.g. learning to program the m68K was extremely useful just to understand how stacks, interrupts, etc. work. OTOH, I haven't used anything from in my programming languages course since then).

adam_gyroscope 9y ago
I took this course a few years back when it was on Coursera and had taken a similar course many years ago in university; I've been a developer of some kind for 20+ years. This course brought together a bunch of stuff I understood but hadn't internalized so didn't use in my day-to-day job. If you've been programming for a few years and take this course, you're going to say "OHHH that explains <some weird thing that happened in your career>" a bunch.
zmodem 9y ago
I can't comment on this course specifically, but the argument for studying compilers, even if you don't end up working in that field, is that learning how programs are translated gives a deepter understanding of how computers are programmed. From a practical view-point, it's useful to know what a compiler can and cannot do with your program. Niklaus Wirth puts it like this: "It is the essence of any academic education that not only knowledge, and, in the case of an engineering education, know-how is transmitted, but also understanding and insight. In particular, knowledge about system surfaces alone is insufficient in computer science; what is needed is an understanding of contents. Every academically educated computer scientist must know how a computer functions, and must understand the ways and methods in which programs are represented and interpreted. Compilers convert program texts into internal code. Hence they constitute the bridge between software and hardware. Now, one may interject that knowledge about the method of translation is unnecessary for an understanding of the relationship between source program and object code, and even much less relevant is knowing how to actually construct a compiler. However, from my experience as a teacher, genuine understanding of a subject is best acquired from an in-depth involvement with both concepts and details. In this case, this involvement is nothing less than the construction of an actual compiler." (From http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf)
mikeurbach 9y ago
I can't comment on this specific course, but I took a compilers course from Tom Cormen that completely changed how I thought about computing. After several years in industry, it's not so much the specific techniques of constructing a compilers that remain useful, but the mode of thinking I learned. I had an AHA moment along the lines of "Wow, the compiler writer is basically God." I had taken courses in software development and hardware architecture, but after writing a compiler I saw first-hand how a program--a description of a solution to a problem in a human readable language--is converted to the same description in a hardware readable language. The meaning of the program must be preserved by the compiler, but otherwise it has the freedom to generate any one of potentially many outputs that preserve the meaning. There is a beauty I realized in the relationship between the programmer, the programming language, the compiler, and the hardware architecture. They are all in cahoots, but the compiler is the cornerstone. That relationship doesn't directly affect my decisions as a professional software engineer, but it forms the backdrop upon which I think about the act of programming and computing in general.
saltcured 9y ago
It's been two decades since I took the origins of this course at UC Berkeley. Understanding the material from this course (and the Dragon Book in general) should change the way you think about many forms of data processing. I think this topic is absolutely foundational to a well-rounded CS education. It's important to understand a little about tool-building rather than just tool-use if you want to master your craft. I haven't reviewed his new syllabus in depth, but even 20 years ago, Alex had reduced the focus on parsing compared to more traditional syllabi based on the Dragon Book. You were expected to do some homework and self-study to learn the basic parsing and lexing concepts. The reason for COOL was to get you into the other compiler-construction topics sooner to get some breadth of exposure to concepts like abstract syntax trees, semantic checking, type systems, intermediate languages, code-generation, and the rough idea of runtime systems and ABIs. Taken together with an operating systems course, these are really two different examples of systems engineering concepts. You should be able to take away not just some vertical silo of knowledge only applicable to "building a compiler" or "writing an OS". You should be able to fuse these concepts into a richer understanding of how to decompose and engineer complex systems given a range of specialized and more general-purpose requirements. Another facet of this can be found in courses focused more on database construction and storage, but this starts to veer out of the introductory space. Unfortunately, most introductory database courses focus too much on using a database and writing applications instead of on understanding how they work and what the engineering tradeoffs actually are.
rifung 9y ago
Recently, a coworker of mine told me how she thought the compiler should catch when you don't give printf the right arguments. Another example is when a coworker said you couldn't define flags in a Go library but she didn't realized you would have to import the package from that library to force the code to run first. In my mind, both of these examples showed a lack of understanding in how the compiler works. I would say learning about compilers should help with being able to make good assumptions of how things work. Whether it's worth the rare times it comes in handy is probably dependent on what else you could learn. Note that I actually didn't take a compilers course myself and said co-workers did, so I can't say for sure even taking a course is sufficient (but I am currently reading a compilers book, though out of enjoyment and not for career skills). I should also say I believe my co-workers are significantly better developers/employees than I am.
- glangdale 9y ago
  > Recently, a coworker of mine told me how she thought the compiler should catch when you don't give printf the right arguments. The fact that you think she's wrong, and that you're right, on this issue, suggests you don't understand how compilers work either. 99% of printf fails are catchable through static analysis, and should be caught that way.
  - jrpelkonen 9y ago
    But is the static analysis of input strings passed to a random library function really a core feature of a compiler, just because the compiler has a switch for such analysis? Yes, it's a feature of modern well-engineered tool, but I would argue it's strictly not part of the compiler.
  - rifung 9y ago
    > The fact that you think she's wrong, and that you're right, on this issue, suggests you don't understand how compilers work either. I'm happy to be proven wrong and certainly know I have much more to learn but I suspect in this case I was not clear in my comment and consequently you made assumptions about what I think is right or not. Feel free to correct me =] Either way I appreciate the response > 99% of printf fails are catchable through static analysis, and should be caught that way. I never said that it wasn't possible! But that would require the compiler have special logic just for printf or in this case the fmt and log packages. Maybe you would think that's the right thing to do, and I can see that point of view, but I suspect you would at least understand why it is a controversial decision and thus not necessarily assume it's there.
alexashka 9y ago
It's beneficial if it's an itch that you want to scratch. For me, compilers, operating systems, databases, networks, processors are foundations upon which everything else is built. I'd like to know a little bit about the foundation upon which I'm making a living. Some folks just want to get things done. I think it's just a personality thing.
keithnz 9y ago
I haven't been on a decent compiler course, for the most, I taught myself. I find that I constantly invent mini languages. For instance, I do a lot with timeseries data, and do a lot with bringing in all kinds of external sources of data in many weird formats, so I have a simple data transfomation language that deals with 90% of the scenarios I encouter. Also have a various device simulation languages for describing various sensors and their interfaces, eg SDI12 with it's various timing constraints and sequences. As part of a broader embedded board based testing system the mini language is used to say how you want a sensor to be simulated and then you can execute tests to ensure things work
sn9 9y ago
If you want an entertaining if opinionated defense for studying compilers, Steve Yegge's got ya covered: https://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html https://steve-yegge.blogspot.com/2007/06/rich-programmer-foo...

adam_gyroscope 9y ago

I took this course a few years back when it was on Coursera and had taken a similar course many years ago in university; I've been a developer of some kind for 20+ years. This course brought together a bunch of stuff I understood but hadn't internalized so didn't use in my day-to-day job. If you've been programming for a few years and take this course, you're going to say "OHHH that explains <some weird thing that happened in your career>" a bunch.

zmodem 9y ago

I can't comment on this course specifically, but the argument for studying compilers, even if you don't end up working in that field, is that learning how programs are translated gives a deepter understanding of how computers are programmed. From a practical view-point, it's useful to know what a compiler can and cannot do with your program. Niklaus Wirth puts it like this: "It is the essence of any academic education that not only knowledge, and, in the case of an engineering education, know-how is transmitted, but also understanding and insight. In particular, knowledge about system surfaces alone is insufficient in computer science; what is needed is an understanding of contents. Every academically educated computer scientist must know how a computer functions, and must understand the ways and methods in which programs are represented and interpreted. Compilers convert program texts into internal code. Hence they constitute the bridge between software and hardware. Now, one may interject that knowledge about the method of translation is unnecessary for an understanding of the relationship between source program and object code, and even much less relevant is knowing how to actually construct a compiler. However, from my experience as a teacher, genuine understanding of a subject is best acquired from an in-depth involvement with both concepts and details. In this case, this involvement is nothing less than the construction of an actual compiler." (From http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf)

mikeurbach 9y ago

I can't comment on this specific course, but I took a compilers course from Tom Cormen that completely changed how I thought about computing. After several years in industry, it's not so much the specific techniques of constructing a compilers that remain useful, but the mode of thinking I learned. I had an AHA moment along the lines of "Wow, the compiler writer is basically God." I had taken courses in software development and hardware architecture, but after writing a compiler I saw first-hand how a program--a description of a solution to a problem in a human readable language--is converted to the same description in a hardware readable language. The meaning of the program must be preserved by the compiler, but otherwise it has the freedom to generate any one of potentially many outputs that preserve the meaning. There is a beauty I realized in the relationship between the programmer, the programming language, the compiler, and the hardware architecture. They are all in cahoots, but the compiler is the cornerstone. That relationship doesn't directly affect my decisions as a professional software engineer, but it forms the backdrop upon which I think about the act of programming and computing in general.

saltcured 9y ago

It's been two decades since I took the origins of this course at UC Berkeley. Understanding the material from this course (and the Dragon Book in general) should change the way you think about many forms of data processing. I think this topic is absolutely foundational to a well-rounded CS education. It's important to understand a little about tool-building rather than just tool-use if you want to master your craft. I haven't reviewed his new syllabus in depth, but even 20 years ago, Alex had reduced the focus on parsing compared to more traditional syllabi based on the Dragon Book. You were expected to do some homework and self-study to learn the basic parsing and lexing concepts. The reason for COOL was to get you into the other compiler-construction topics sooner to get some breadth of exposure to concepts like abstract syntax trees, semantic checking, type systems, intermediate languages, code-generation, and the rough idea of runtime systems and ABIs. Taken together with an operating systems course, these are really two different examples of systems engineering concepts. You should be able to take away not just some vertical silo of knowledge only applicable to "building a compiler" or "writing an OS". You should be able to fuse these concepts into a richer understanding of how to decompose and engineer complex systems given a range of specialized and more general-purpose requirements. Another facet of this can be found in courses focused more on database construction and storage, but this starts to veer out of the introductory space. Unfortunately, most introductory database courses focus too much on using a database and writing applications instead of on understanding how they work and what the engineering tradeoffs actually are.

rifung 9y ago

Recently, a coworker of mine told me how she thought the compiler should catch when you don't give printf the right arguments. Another example is when a coworker said you couldn't define flags in a Go library but she didn't realized you would have to import the package from that library to force the code to run first. In my mind, both of these examples showed a lack of understanding in how the compiler works. I would say learning about compilers should help with being able to make good assumptions of how things work. Whether it's worth the rare times it comes in handy is probably dependent on what else you could learn. Note that I actually didn't take a compilers course myself and said co-workers did, so I can't say for sure even taking a course is sufficient (but I am currently reading a compilers book, though out of enjoyment and not for career skills). I should also say I believe my co-workers are significantly better developers/employees than I am.

glangdale 9y ago
> Recently, a coworker of mine told me how she thought the compiler should catch when you don't give printf the right arguments. The fact that you think she's wrong, and that you're right, on this issue, suggests you don't understand how compilers work either. 99% of printf fails are catchable through static analysis, and should be caught that way.
- jrpelkonen 9y ago
  But is the static analysis of input strings passed to a random library function really a core feature of a compiler, just because the compiler has a switch for such analysis? Yes, it's a feature of modern well-engineered tool, but I would argue it's strictly not part of the compiler.
- rifung 9y ago
  > The fact that you think she's wrong, and that you're right, on this issue, suggests you don't understand how compilers work either. I'm happy to be proven wrong and certainly know I have much more to learn but I suspect in this case I was not clear in my comment and consequently you made assumptions about what I think is right or not. Feel free to correct me =] Either way I appreciate the response > 99% of printf fails are catchable through static analysis, and should be caught that way. I never said that it wasn't possible! But that would require the compiler have special logic just for printf or in this case the fmt and log packages. Maybe you would think that's the right thing to do, and I can see that point of view, but I suspect you would at least understand why it is a controversial decision and thus not necessarily assume it's there.

alexashka 9y ago

It's beneficial if it's an itch that you want to scratch. For me, compilers, operating systems, databases, networks, processors are foundations upon which everything else is built. I'd like to know a little bit about the foundation upon which I'm making a living. Some folks just want to get things done. I think it's just a personality thing.

keithnz 9y ago

I haven't been on a decent compiler course, for the most, I taught myself. I find that I constantly invent mini languages. For instance, I do a lot with timeseries data, and do a lot with bringing in all kinds of external sources of data in many weird formats, so I have a simple data transfomation language that deals with 90% of the scenarios I encouter. Also have a various device simulation languages for describing various sensors and their interfaces, eg SDI12 with it's various timing constraints and sequences. As part of a broader embedded board based testing system the mini language is used to say how you want a sensor to be simulated and then you can execute tests to ensure things work

sn9 9y ago

If you want an entertaining if opinionated defense for studying compilers, Steve Yegge's got ya covered: https://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html https://steve-yegge.blogspot.com/2007/06/rich-programmer-foo...