undefined

points

[-]

You're not the only one. In college I took a compilers course and we used the dragon book, to me it sucked the joy out of the magical concept of making a compiler.

Some years later I (re-) discovered Forth, and I thought "why not?" and built my own forth in 32-bit Intel assembly, _that_ brought back the wonder and "magical" feeling of compilers again. All in less than 4KB.

I guess I wasn't the right audience for the dragon book.

by pjmlp7 hours ago|

prev|

[-]

It was a product of its time I guess, much better ones from similar vintage,

The Tiger book (with C, Standard ML, and Java variants)

https://www.cs.princeton.edu/~appel/modern/

Compiler Design in C (freely available nowadays, beware this is between K&R C and C89)

https://holub.com/compiler/

lcc, A Retargetable Compiler for ANSI C

https://drh.github.io/lcc/

Or if one wants to go with more clever stuff,

Compiling with Continuations

Lisp in Small Pieces

by drob5186 hours ago|

parent|

[-]

Another vote for Lisp in Small Pieces. Great high level compiler book that teaches you how to build a Lisp and doesn’t get bogged down in lexing and parsing.

by _false8 hours ago|

prev|

[-]

Great thread. If you have 1 hour to get started, I recommend opening Engineering a Compiler and studying Static Single-Assignment (SSA) from ch 9.3.

The book is famous for its SSA treatment. Chapters 1-8 are not required to understand SSA. This allows you to walk away with a clear win. Refer to 9.2 if you're struggling with dominance + liveness.

http://www.r-5.org/files/books/computers/compilers/writing/K...

by unclad59684 hours ago|

parent|

[-]

I bought this book when I was working on a toy language and I think I was too stupid to understand most of it. The first few chapters were great, but it quickly surpassed my capacity to understand. Seeing it mentioned makes me want to revisit.

by randomNumber710 hours ago|

prev|

[-]

Imho the problem is the fixation on parser generators and BNF. It's just a lot easier to write a recursive descent parser than to figure out the correct BNF for anything other than a toy language with horrible syntax.

by microtherion2 hours ago|

parent|

[-]

I would argue the opposite: Being describable in BNF is exactly the hallmark of sensible syntax in a language, and of a language easily amenable to recursive descent parsing. Wirth routinely published (E)BNF for the languages he designed.

by marcosdumay9 hours ago|

parent|

prev|

[-]

The problem with recursive descent parsers is that they don't restrict you into using simple grammars.

But then, pushing regular languages theory into the curriculum, just to rush over it so you can use them for parsing is way worse.

by aleph_minus_one4 hours ago|

parent|

[-]

> But then, pushing regular languages theory into the curriculum, just to rush over it so you can use them for parsing is way worse.

At least in the typical curriculum of German universities, the students already know the whole theory of regular languages from their Theoretical Computer Science lectures quite well, thus in a compiler lecture, the lecturer can indeed rush over this topic because it is just a repetition.

by wglb12 hours ago|

prev|

[-]

When I was professionally writing a compiler professionally (see https://ciex-software.com/intro-to-compilers.html) the Dragon book was the second book that I read. I found it very helpful. That was the first Dragon book. I got the second one later. I would have been ok to start with the Dragon book--the Compiler Generator book was a harder study.

by keyle2 hours ago|

prev|

[-]

     The dragon book almost convinced me never to try to write a compiler.

That was the point. That's why it's not a cute beaver on the cover :)

by saidnooneever12 hours ago|

prev|

[-]

the dragon book is how to write a production grade thing i guess. it has all the interesting concepts very elaborated on which is great but it dives quickly into things that can clutter a project if its just for fun..

by emigre9 hours ago|

parent|

[-]

It’s academic and comprehensive, that’s the issue. It’s not about writing a production grade compiler, though, in my humble opinion. There are more things to learn for that, unfortunately… is just a pretty big topic with lots of stuff to learn.

by saidnooneever5 hours ago|

parent|

[-]

the dragon book is all i have on the topic. it was a big investment for me.

it taught me to think very differently but i am sure i am still not ready to write a compiler :D

by tovej13 hours ago|

prev|

[-]

I started with the dragon book, and I found it to be a good introductory text.

A lot of people say the dragon book is difficult, so I suppose there must be something there. But I don't see what it is, I thought it was quite accessible.

I'm curious, what parts/aspects of the dragon book make it difficult to start with?

by hmry12 hours ago|

parent|

[-]

It's been a few years since I worked with the dragon book, but I think the most common complaint was that it starts with like 350 pages on parser theory: generating bottom-up and top-down parsers from context free grammars, optimizing lexers for systems that don't have enough RAM to store an entire source file, etc... before ever getting to what most people who want to write a compiler care about (implementing type inference, optimizing intermediate representations, generating assembly code). Of course parsing is important, and very interesting to some. But there's a reason most modern resources skip over all of that and just make the reader write a recursive descent parser.

by ablob10 hours ago|

parent|

[-]

I guess "back in the day" you had to be able to write an efficient parser, as no parser generators existed. If you couldn't implement whatever you wanted due to memory shortage at the parser level, then obviously it's gonna be a huge topic. Even now I believe it is good to know about this - if only to avoid pitfalls in your own grammar.

I repeatedly skip parts that are not important to me when reading books like this. I grabbed a book about embedded design and skipped about half of it, which was bus protocols, as I knew I wouldn't need it. There is no need to read the dragon book from front to back.

  > But there's a reason most modern resources skip over all of that and just make the reader write a recursive descent parser.

Unless the reason is explicitly stated there is no way to verify it's any good. There's a reason people use AI to write do their homework - it just doesn't mean it's a good one. I can think of plenty arguments for why you wouldn't look into the pros and cons of different parsing strategies in an introduction to compilers, "everyone is(or isn't) doing it" does not belong to them. In the end, it has to be written down somewhere, and if no other book is doing it for whatever reason, then the dragon book it shall be. You can always recommend skipping that part if someone asks about what book to use.

by markus_zhang8 hours ago|

parent|

prev|

[-]

I actually think the parsing part is more important for laymen. Like, there may be a total of 10K programmers who are interested in learning compiler theories, but maybe 100 of them are ever going to write the backend -- the rest of them are stuck with either toy languages, or use parsing to help with their job. Parsing is definitely more useful for most of us who are not smart enough :D

by hmry7 hours ago|

parent|

[-]

Yeah I agree, that seems vey true. Although the average person probably also benefits more from learning about recursive descent and pratt parsing than LL(k) parser generators, automata, and finding first and follow sets :)