Lambda the Ultimate

True. But if you use google (and who doesn't) you'll find both the wikipedia page and the amazon page for the book, simply by plugging in "dragon book". Such is the power of technology...

I agree that the best way to learn is to start by building a simple intrepeter and continue from there. But a good advice is to keep in mind that your first attempt(s) are likely to be dead-ends. There are many useful patterns used in the design of language processing tools, which you shouldn't rediscover for yourself. After playing a bit with your own design, throw them away happily and go to the litterature (or web sites) to find standard compiler/interpreters designs to copy and modify...

Which is part of the fun!

You are quite right, of course.

There's three of them, all bearing a different-color dragon on the cover.

Principles of Compiler Design, the "green dragon". The first book by the set of authors in question (or a subset thereof--it came out in 1977. Much of the theory is a bit out of date, and I'd recommend one of the successors, but if you can find a used copy cheap, go for it. This one is written by Aho and Ullman.

Compilers: Principles, Techniques, and Tools, aka the "red dragon", by Aho, Ullman, and Ravi Sethi. The second edition of this work adds Monica Lam as a co-author, and is the "purple dragon". The PD contains most (if not all) of the content of the red dragon, plus a lot of new material on modern compiling techniques, such as JIT. The 2nd edition just came out this year, and you should expect to pay near full price (which might be a consideration if you're a Starving College Student--we all were at one point and some of us still are).

The Dragon Books aren't terribly heavy on "programming language" theory--i.e. documenting and classifying the different features and issues with designing a PL or analying an existing one. They instead focus on implementing compilers, with particular focus on compilers which translate from a HLL to machine code. They might not be the best place to start--it's better (an easier!) to write an interpreter for your language at first, and only if you find it useful should you consider writing translators.

One other book I'd recommend, as a bit of a gentler intro to the topic, is Michal Scott's excellent Programming Language Pragmatics (I see someone else has recommended it below). If you have a limited theoretical background in PLT (programming language theory), type theory, or other related topics, this book will help you get your feet wet. PLP is probably my favorite undergraduate-level text which is specific to PLT. One other one I highly recommend is Peter van Roy's Concepts, Techniques, and Models of Computer Programming. Like SICP, this isn't a book on PLT so much is it is a book on programming techniques--but still an important consideration, as a good PL will make the common programming language techniques easily accessable to the programmer.

Finally, a few paradigm-specific works: Bertrand Meyer's Object Oriented Software Construction is still the definitive work on OO (though it tends to beat the Eiffel drum somewhat). Guy and Mauny's The Functional Approach to Programming is a good intro to FP, and you'll never know from reading it that it's a translation of a French work. (Which lazy-FP book is best for beginners?) Oh, and although it isn't a PL work, you should have a few books on your shelf by database guru Chris Date, starting with An Introduction to Database Systems and proceeding to one of the various versions of The Third Manifesto (there are three versions and all can be found at a bookseller near you).

to credit Peter van Roy's co-author, Seif Haridi. PVR, as he's known around these parts, is a regular contributor to LtU.

Regarding the dragon books, I'd recommend the more recent and, to my opinion, easier to access, Appel's series "Modern Compiler Implementation in (your favorite language)".

Why do learners solve tones of tasks which have already been solved by others?

I would venture to suggest this is because the solved tasks are not packaged in a reusable way, and that the task of creating such packaging remains an unsolved problem. Thus people, not just learners, re-solve problems because they must. Of course, there are numerous partial solutions, but a real solution requires popular acceptance as well as the appropriate technical properties.

When it comes to DSELs (domain specific embedded languages), don't forget Prolog. See here for several examples and techniques.

Prolog can itself be a DSEL. Here's a Prolog compiler in Lisp from Norvig's Paradigms of Artificial Intelligence Programming. Then you can write code like this:

(<- (zebra ?h ?w ?z)
       ;; Each house is of the form:
       ;; (house nationality pet cigarette drink house-color)
       (= ?h ((house norwegian ? ? ? ?)	;1,10
	      ? 
	      (house ? ? ? milk ?) ? ?)) ; 9
       (member (house englishman ? ? ? red) ?h)	; 2
       (member (house spaniard dog ? ? ?) ?h) ; 3
       (member (house ? ? ? coffee green) ?h) ; 4
       (member (house ukrainian ? ? tea ?) ?h) ; 5
       (iright (house ? ? ? ? ivory)	; 6
	       (house ? ? ? ? green) ?h)
       (member (house ? snails winston ? ?) ?h)	; 7
       (member (house ? ? kools ? yellow) ?h) ; 8
       (nextto (house ? ? chesterfield ? ?) ;11
	       (house ? fox ? ? ?) ?h)
       (nextto (house ? ? kools ? ?)	;12
	       (house ? horse ? ? ?) ?h)
       (member (house ? ? luckystrike oj ?) ?h)	;13
       (member (house japanese ? parliaments ? ?) ?h) ;14
       (nextto (house norwegian ? ? ? ?) ;15
	       (house ? ? ? ? blue) ?h)
       (member (house ?w ? ? water ?) ?h) ;Q1
       (member (house ?z zebra ? ? ?) ?h))) ;Q2

;; Solve the Zebra problem:
(?- (zebra ?houses ?water-drinker ?zebra-owner))

Interestingly, an optimized version of the code from PAIP can solve this sort of problem much faster than a straightforward Lisp implementation -- thus showing the usefulness of Prolog as an embedded language for logical inference. Here's a comparison backing that up with code and numbers.

You gotta admit that Java has some pretty advanced development environments. Write a nice parser plugin for an IDE.

You have greater chances of starting a garage band and winning a major-label record deal, then the fruits of your labor becoming the next Ruby or Perl.

Except he has an award winning idea that comes out of his studies. Be friendly to a guest, since he could be the mask of a god.

Its true that you may not write the next big thing, but that doesn't mean you can't take what you've learned and contribute to a larger project. The very least you'll take from the experience is a greater understanding of implementation of PLs and of the languages that you use.

That said, a good start would be a tutorial on flex/yacc or related tools in the language of your choice. Then you can pick up a compiler book - both Dragon and 'Modern Compiler Application in *' are very helpful.

None at all. And I don't intend to cast any aspersions at the original poster or his ideas or capabilities.

Simply pointing out that the vast majority of programming language projects fail to become "popular". Heck, the vast majority fail to attract any users beyond their developer(s).

Which is OK--in many cases, popularity is not the intent--the purpose of the language is to demonstrate some principle or otherwise edify the creator.

But if someone is here thinking that they will get to be BDFL for a programming language which gets mentioned on people's resumes, and has an O'Reilly book with a critter on the cover...the line forms on the right. :)

At any rate, welcome to LtU!

...the line forms on the right. :)

And here's some helpful reading material while standing on that line: Some words of advice on language design, by Frank Atanassow. Even though the advice is geared towards someone trying to create an important new language, it may help keep priorities straight even if you're aiming lower.

I second this recommendation of Niklaus Wirth's Compiler Construction, and would like to add that Project Oberon provides an excellent analysis by example of how compilers and language tools tie in with an operating system as a whole (see particularly section 6, The Module Loader).

I have a feeling he left the conversation awhile ago.