57 of 59 people found the following review helpful:
1.0 out of 5 stars
Waste of time, May 20, 2004
By A Customer
This review is from: Build Your Own .NET Language and Compiler (Paperback)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
46 of 50 people found the following review helpful:
2.0 out of 5 stars
Okay for the novice, I guess..., November 9, 2004
This review is from: Build Your Own .NET Language and Compiler (Paperback)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
30 of 33 people found the following review helpful:
3.0 out of 5 stars
Great BNF coverage; but gets off subject too often, July 4, 2005
This review is from: Build Your Own .NET Language and Compiler (Paperback)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No