http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Excellent argument! http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment7http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment7Sat, 27 Oct 2007 15:20:10 GMTThanks for the reasoned reply. Based on what you've written, Boo definitely seems to hold some advantages for DSL creation. In terms of your proposed book, I suggest that you flesh out the information outlined above, and investigate F#, IronPython and IronRuby, so that you can clearly make the case for your use of Boo, as it is a language with a lot less mindshare than some of the others. http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment6http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment6Mon, 15 Oct 2007 11:08:39 GMTAyende, Here's a link to F# macro: http://www.strangelights.com/fsharp/wiki/default.aspx/FSharpWiki/Macro.html http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment5http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment5Mon, 15 Oct 2007 01:33:38 GMTDavid, Thanks, I'll be certain to do so. http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment4http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment4Sun, 14 Oct 2007 16:31:38 GMTAlexey, do you have a link to the F# macros? I am familiar with Nemerle http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment3http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment3Sun, 14 Oct 2007 15:13:53 GMTI used to be a huge fan of the lispy/schemey languages. Both have a very good DSL story - essentially, that's the main model in those languages for getting things done – iteratively build a tower of increasingly domain specific languages using the very powerful sexp based macro systems that those languages have. They also coalsece a fairly large body of software practice and experience to the extent that Greenspun's Tenth Rule of Programming cautions us: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp". My heart belongs to Haskell now, rather than lisp and has done so for the last few years. A great deal of research into DSL’s has gone on in the Haskell community. Since the Haskell community is pretty strong within MS I’ve not been so surprised to see a glimmer of this work reappear c# 3.0 in the guise of Linq (thanks to Erik Meijer, who is continuing his good deeds with Volta). Anyway, the point of this longish rambling post, such as it has one, is to encourage you to look at Haskell (and perhaps lisp or scheme) with a view to seeing how these communities tackle DSLs. The downside of looking so far outside the box is that the box begins to seem very, very small. http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment2http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment2Sun, 14 Oct 2007 13:15:28 GMTBoth F# and Nemerle have macros (code transformation at compile time). http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment1http://ayende.com/2867/evaluating-languages-for-building-internal-dsls#comment1Sun, 14 Oct 2007 12:48:16 GMT