Customer Reviews

Build Your Own .NET Language and Compiler

5 star:		(4)
4 star:		(5)
3 star:		(1)
2 star:		(2)
1 star:		(5)

 

 

I have been waiting for a book like this for quite awhile. I've read John Gough's book and although that was too much Pascal for me; it was certainly closer to the topic than this book. This book is both incomplete and off the mark. One of the tools, a BNF Analyzer, is written (poorly) in Visual Basic 6. The downloaded source for the programs don't compile "out of the box" either. This was a rush job or done poorly in someone's spare time. Some of the code is from 1998.

Here's the kicker. The author talks about how to write BNF and analyze it, but he actually doesn't use it in his sample compiler. He wrote the compiler manually "in a few days". Then, he talks about producing MSIL, but doesn't, opting for his own opcode syntax with an interpreter. There is no information in this book about producing a compiler that will create .NET code.

This was a lazy and deceitful attempt and the author should be ashamed for not taking the time to do it properly using BNF to create the compiler engine and then producing MSIL, which is the whole point of the title "Build Your Own .NET Language and Compiler".

He clearly knows what he's talking about, but he tried to throw together a bunch of his compiler knowledge in hopes of making a quick buck. Sadly, I was suckered into it, but hopefully, you'll read this and skip it entirely.

I preordered the book and I forced to admit that I was disappointed in the end product. The title implies that a compiler is created for .NET, but it does not create a MSIL compiler (such as C# or VB.NET). The provided code while it is written in a .NET language does not produce MSIL which is what the title of the book implies, instead the compiler runs it's own p-code. There is no partially correct statement as a previous review states, either it is or it is not and this is *not* a .NET compiler.

The fact that the author writes excuses for the book in his own review of the book should tip you off that something is not what you would think it is at face value. If you read the book you will find that he also makes such a statement that the code may not be what you were expecting in the book itself. Nilges knows that something is wrong.

That being said, if you have no background in writing compilers then this book may be of some value to you as an introductory text on the subject but don't expect to find anything here of any real use to your own work. If you think that you might enjoy the book then buy it used.

The book starts out explaing the standard notational language
used to define the syntax of a language: BNF (and extended BNF).
The authors VB6 EBNF-to-doc compiler "compiles" an EBNF
grammer into a documentation file! This is a novel idea
and it helps to show how EBNF relates to the syntax of the
language in question.

Although his presentation of EBNF is masterful, he didn't
use EBNF to generate the parser for his compiler. I expected
him to use a parser generator like ANTLR or coco/R to generate
a scanner and recursive decent parser automatically from
the grammer. Instead, he chose to "roll his own" scanner
and parser.

His scanner seems very good, and his discussion of
the scanner is thorough.

His parser is harder to judge by reading the book since he
kept getting off the main subject and he didn't really
explain the parsing code.

His code generator discussion has some nuggets of wisdom,
but is poorly organized.

One overriding concern with this author is that he
doesn't use terminology consistant with other
authors. He doesn't use common terms like p-code,
intermediate language, virtual machine, or the like.
His non-standard use of the word "assembling" is really
just a step that removes comments from his p-code!

The authors presentation can get off track frequently.
Its hard to find 5 pages in a row that stay on
subject completely. He also likes to quote famous people,
often out of context to the subject at hand.

His runtime interpreter (which some might call a virtual
machine) is called the "Nutty Professor Interpreter". The
heavy objects used in his design make for a terribly
inefficent runtime. His use of collections to implement
array elements is very elegant, but completely impractical
from a performance standpoint.

I like the author's concept of integrated testing, but
he seems to have left out the most important piece of the
testing architecture - a suite of test programs in the
target language.

I would have preferred these changes to the book:

1) a suite of test programs in basic.

2) compiler should save the pseudo-code into a file on
disk. His runtime "nutty professor" interpreter should
read from that pseudo-code file and execute the
program. This helps to separate the tiers.

3) his runtime architecture should have focused more
on efficiency. It's perhaps 100 times slower than any
other BASIC interpreter (maybe 1000 - I didn't
actually time it). And it should be faster than simple
interpreters because this uses a compiler in the
front-end - the runtime interpreter doesn't need to
analyze the syntax so it should be very fast.

4) he should NOT have implemented variants or user-defined
types. These took a lot of thought and effort which should
have been directed on the first 3 items instead.

This is a mediocre book. I probably would have given it 2.5 stars if it was allowed, but it definitely isn't worth 3.

The issues I have with the book are:

1) It just isn't very good. If you want to develop a compiler/programming language, get: Lex and Yacc (Levine, Mason, Brown), Compiler Construction: Principles and Practice (Louden), and Programming Language Pragmatics (Scott). All of them are excellent books.

2) I'm not sure what to make of the author's incessant injections of political diatribes into the book. He tries to hide it by couching it in sidebars and philosophical quotes but it really sticks out like a sore thumb. There's the quip about Nixon invading Cambodia, the quote from Carl Marx, and then the passage accusing (Dilbert creator) Scott Adams of having "mocked offshore and immigrant developers" and of "essentially exploit[ing] the ordinary working folks he left behind." Is this supposed to be a political book or a book about writing compilers?

3) The writing style is a bit longwinded. For example, take a look at the review he wrote for his own book. Admittedly, the book isn't nearly as unfocused as his rambling review, but it could've been more concise. Luckily, in the book he keeps much of his rambling contained in the footnotes.

I hate to give any book a 1 star rating, as it's obvious that the author put a lot of work in this book. But I have to. This book is so full of technical errors and false assumptions I don't understand how it passed a technical review (and Lead Editor was Dan Appleman, so I assumed it would be good). I read this book on my commute to work and I have set up an almost daily mail for my colleagues where I tell them what I read and we all make fun of it. But sometimes it's downright depressing. I don't care if the guy has continuity problems with his writing that make him go to completely unrelated political and historical events (and he does that a lot), but the antipatterns he uses (using a collection instead of an object because "it is unnecesary to go crazy and develop a full-dress object for each and every potential object", the IsUsable pattern where he inspects objects on dispose to see if their status is consistent instead of proper testing, which "creates logistical problems in that it doubles the count of overall projects", thinking that AndAlso is something that exists at IL level, stating that declaring variables inside of a For loop has some sort of performance penalty, a naming convention where "all members that are called exclusively by a higher procedure (...) are prefixed by the name of the caller" and many, many more). I'm still not very deep in his compiler practices. What I have seen so far I didn't like, but I don't know if I'm a very good judge of that (and that's why I'm reading these books). Based on his misconceptions on much about anything else, I'm not giving him a lot of credit. Buy Gough's book. It's still the best around.

I don't write many book reviews for Amazon, but this book was so terrible I figured I had to. If you want to build your own .Net language and Compiler then you must have some understanding of the theoretical underpinnings of compilers - scanners, parsers, intermediate representation, etc.

This book not only skips the required theory, but avoids any technical depth to the degree of being nothing more than 400-page description of a crappy BASIC interpreter the author wrote.

Even if you want some lightweight reading on the subject of compilers or .Net in general, there just isn't enough meat here to justify picking this book up off the shelf.

I have to agree with the "waste of time" review below. This book reads like a C-student's CS notes on compiler technology. Having created compilers for other platforms, I hoped that this book would shed some light on compiling to MSIL. Unfortunately, coverage on this and other key topics is quite sparse.

In the book, the author refers to Aho, Sethi and Ullman's classic - "Compilers: Principles, Techniques and Tools" (The "dragon book"). Especially if you're new to compilers, do yourself a favor - forget this second-rate knockoff and get the real thing.

Shame on APress's editors and reviewers for letting this one out the door. Shame on me for per-ordering this mess.

First, some clear demarcation about what this book isn't: if you want a book with a really strong theoretical background in compiler design, this isn't it. I have Programming Language Pragmatics by Scott, and I recommend it.

Second, if you want a book about compiling to IL for direct execution, this isn't that book either. Frankly, this book is poorly titled in that respect. I don't yet have Compiling for the .NET Common Language Runtime by Gough, but it supposedly focuses specifically on this topic.

So what is this book? It's a practical, highly readable book about how to build a scripting language interpreter in VB.Net. A compiler theory textbook can teach you the principles involved in scanning and parsing, but it's likely to leave you wondering how you actually put any of that to use in real code. This book fills in enough theory to have an idea of what you're doing (with a little to spare), and lets you dive right in and work with practical real-world algorithms and code for actually doing it.

If you are a working programmer and you want to add a scripting language to an application you've written, it's easy to conclude that it's way too complicated to do all that stuff. This book is a fantastic antidote for that. It goes through things like tokenization, formal grammars, and recursive descent parsing in plenty of detail, any anyone who understands the basic CS building blocks of data structures and algorithms should find the coverage easy to follow. The text sometimes meanders a little too much, but it's still far more readable than anything else on the topic that I've run across.

My main criticism of this book is that it's a lot better about how to read in a language than how to do something with the result once you've read it in. The included interpreter operates on top of its own limited stack-based virtual machine, and the parser emits opcodes for it. This isn't covered in nearly enough detail, and my sense is that it's because the author isn't really thrilled with his interpreter. My gut feel is that this is kind of a neither-fish-nor-foul solution. A powerful solution for emitting opcodes would generate legitimate IL for the CLR, which the author gives a brief overview of, but doesn't follow through enough to produce real-world code. By contrast, I think a simpler solution for purely interpreted code would produce directly evaluatable function, statement, and operator objects, and not worry about emitting a language or dropping variables on a stack. The author's solution would seem to lack either the performance advantage of the former solution, or the simplicity and conceptual clarity of the latter. The only advantage I can see is pedagogical: it teaches you how to generate opcodes from a parse tree without wading through the complexity of a real-world imtermediate form like IL, GNU RTL, or Java bytecode.

Still, as long as performance isn't paramount, this is a solution that will actually work as an interpreter for a scripting language in the real world. This book covers a lot of ground, without ever completely losing its practical approach. Even though there are some flaws, and some areas I would have loved to see covered in greater detail, this is a tremendously useful book for the right audience.

One of the most difficult things to do is to take a heady subject such as compiler development and break it into simple components and explain it without academic baggage. Nilges succeeded at this admirably. I have attempted to read several of the traditional books on compiler theory only to find myself dazed, confused, or bored to tears by the tedium. That Nilges succeeds in making this book so absorbing, readable, and incredibly mind-opening is amazing.

I now understand the purpose of lex/yacc/bison and I can read any advanced book on compiler development and have a much better understanding of the theory.

In addition, I can and have written my own domain-specific language based on his instruction. I couldn't ask for more. Thanks so much for such a wonderful book.

I really thought this book was going to help me learn more about the subject, but it's really a fairly transparent attempt by the author to make a quick buck or two off of the .NET mania. The writing is painful, to say the least, with a heavy dose of hand-waving thrown in. A lot of claims about proper compiler development which are not followed up in the so-called compiler he developed. It doesn't actually generate proper .NET code, so the whole thing is a fraud, and should be recalled. Don't waste your money on this thing, it should be recalled. Apress used to have a reputation for doing better than this charlatan.