[Confusion]

A parser does not a DSL make. I find this advice, and the advice of the parent, dangerous, as it suggests writing a DSL is just a, relatively simple, technical challenge.

It is like advising the Dragon book and someone replying 'meh, just read SICP'. As in that case, SICP or articles on LR parsers do not even remotely stack up to the Fowler DSL book combined with the ANTLR reference.

[poet]

Two things: (1) classifying Chapter 4 of SICP as a chapter about parsing is just plain wrong and (2) Fowler's DSL book just came out; by definition you simply can't place it in the same class as the Dragon book.

I think if you actually read Chapter 4 you would have a much different opinion. There's nothing "simple" about it. If you actually grok Chapter 4 then you grok Lisp. After that, it becomes apparent that the phrase "Domain Specific Language" is really just unnecessary terminology.

[Confusion]

  classifying Chapter 4 of SICP as a chapter about parsing
  is just plain wrong

I classified my parent as suggesting writing a DSL is mostly writing a parser. I classified your post as saying writing a DSL is mostly a technical challenge, because there are many issues about writing a DSL that SICP doesn't touch upon (or at least, that's mostly what you will get from it on a first reading. See the final paragraph of this reply).

  Fowler's DSL book just came out; by definition you simply 
  can't place it in the same class as the Dragon book.

I didn't place it in 'the same class': I suggested Fowler's book plus the ANTLR reference have many interesting, relevant, even necessary, things to say about the subject of writing DSL's that aren't in SICP (but again: see the final paragraph of this reply), like the Dragon book has many interesting, relevant and necessary things to say about compilers that aren't in SICP.

  After that, it becomes apparent that the phrase "Domain
  Specific Language" is really just unnecessary terminology.

You didn't originally get that just from chapter 4 of SICP. You have much, much more knowledge of all kinds of things relevant to writing DSL's that you didn't learn from chapter 4 of SICP. That it may all be implied in that chapter does not mean it is a useful resource for someone touching the subject of DSL's for the first time, because they won't grasp the implications. Implications may be clear in hindsight, when you apply all your other knowledge to that chapter, but that doesn't mean they were even remotely clear to you in the first place.

  If you actually grok Chapter 4 then you grok Lisp

And you won't grok that chapter until long after you have acquired a vast array of secondary, additional, related knowledge on the subjects the chapter touches upon.

SICP is like a deep philosophical work: you need to study philosophy and read a lot of primary and secondary works to truly understand it's references and implications. To most people, it is not useful as an initial guide to writing DSL's.

[poet]

You didn't originally get that just from chapter 4 of SICP. You have much, much more knowledge of all kinds of things relevant to writing DSL's that you didn't learn from chapter 4 of SICP. That it may all be implied in that chapter does not mean it is a useful resource for someone touching the subject of DSL's for the first time, because they won't grasp the implications. Implications may be clear in hindsight, when you apply all your other knowledge to that chapter, but that doesn't mean they were even remotely clear to you in the first place.

SICP is like a deep philosophical work: you need to study philosophy and read a lot of primary and secondary works to truly understand it's references and implications. To most people, it is not useful as a guide to writing DSL's.

This is a fair point and worth talking about. When I read SICP I already understood Lisp macros, which is a major conceptual leap. So I will admit that I cannot provide a datapoint myself to support the idea that Chapter 4 is stand alone. However, the text itself was used in MIT's first computer science course for many years and they did teach through Chapter 4. Many other schools have used SICP in the past as well (http://mitpress.mit.edu/sicp/adopt-list.html). I think the fact that college freshman are capable of grasping it in a semester provides some evidence against your claim that you need "much, much more knowledge of all kinds of things". Hell, even spending a year to learn it would be fantastic.

Look, I'm with you on the fact that SICP is hard. But let's just reflect on the fact that Chapters 4 and 5 in a book written 26 (or 14) years ago give you a strong foundation in programming languages and compilers. There's tons of stuff you can do with this foundation, including writing DSLs. It's a pet peeve of mine that we seem to be constantly rehashing various ideas in SICP, except that we need to write thousand page books on how to express these ideas in languages like Java or C#. Based on a quick glance of the book draft, this bloat is immediately apparent! For example, the distinction between internel and external DSLs? Completely unnecessary. With an understanding of Lisp the idea of an internal DSL disappears; it's just a natural part of the language. And when you think about it, the idea of external DSLs isn't useful either. If the external DSL is expressive enough, it's just like an internal DSL; simply an extension of the language you implemented it in. If not, well then you're parsing am external file format and not a language.

So yes, to reiterate, teaching SICP is hard. But we'd be better off just biting the bullet to avoid all the bloat and repetition that results from not teaching it.

[Confusion]

  I think the fact that college freshman are capable of
  grasping it in a semester provides some evidence against
  your claim that you need "much, much more knowledge of all
  kinds of things".

I would say they probably grasp it as much as I grasped quantum mechanics after the first course: I was able to go through the motions and explain the concepts involved, but that doesn't mean I actually understood it. I would claim that at some later point, after more courses, labwork and discussions on the subject, I did understand certain parts of it. Much of the additional knowledge and principles I learned are already implied in decent basic texts on the subject, but I simply wasn't in any position to 'expand' those implications.

  There's tons of stuff you can do with this foundation,
  including writing DSLs.

However, writing your first DSL on that foundation requires you to reinvent many wheels, some of which you will reinvent in a square way that first time. Knowing how to write a programming language in Lisp doesn't tell you how to write DSL's, like having a Ph.D. in English means you know how to write a novel, without you actually being capable of writing an good novel. They would still benefit from reading books on 'writing novels' by people that have practical knowledge in writing actually good novels, even if those books were written by authors whose genre they dislike and the style of whom's examples they dislike.

  the distinction between internal and external DSLs?
  Completely unnecessary.

If everyone would program in Lisp: yes. However, people write DSL's in different languages, for all kinds of reasons you may or may not agree with. That means books on writing a DSL in other languages than Lisp simply have their place. And may also be valuable for those writing DSL's in Lisp, for the reasons mentioned above.