

DSLs expand the solution space, GUIs limit it to the creator's vision - herdrick
http://www.windley.com/archives/2007/11/domain_specific_language.shtml

======
iigs
The article isn't too controversial, although it's a bit idealistic about DSLs
-- In a previous job I've worked in an environment with a DSL (incidentally,
it was wrapped in a really restrictive GUI that was the first to go) that was
ok in the trivial case but was greatly restricted by the language designer's
lack of forethought. For example, it was not possible to operate on certain
things using the inbuilt looping construct. We ended up replacing the DSL with
Perl for this and performance reasons.

Perhaps slightly off topic but vastly more interesting to me is the root of
the trouble with GUIs. We saw that GUI demo in the 60s, nothing happened for
20 years until PARC and we've spent the next 30 years moving the close button
around and deciding how to word the Save File dialog box. Where is the
innovation here? Why are virtually all languages implemented in 7-bit ASCII
and a monospaced font? Why is programmatic control or recording of GUI actions
almost always an afterthought?

In a former employment life I saw mockups of brainstorming effort to envision
the future of the command line. The team's efforts mostly looked like trivial
window decoration changes -- the terminal window itself was still ASCII (utf8
or whatever probably), 80x25, and monochrome. Why?

Much as mankind's hand has spread invasive plant species to virtually all soil
on the earth, rendering it largely similar on most continents, the curse of
POSIX is that it has choked out a lot of computing/OS design. Mindless (or
unambitious) mimicry of the Mac/Windows in the GUI world has given us beige on
that once beautiful frontier as well.

I guess it's not a bad place to be, but you wonder how else it might have
turned out.

------
compay
DSL's are great as long as you don't take them too far towards the "natural
language" style of coding.

For example, I find RSpec's story runner uncomfortable to work with because of
the overly English-like syntax it uses.

This blog post has some "before and after" code showing the same tests/specs
implemented at unit tests, and as Rspec stories:

[http://evang.eli.st/blog/2007/9/1/user-stories-with-
rspec-s-...](http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-
story-runner)

To me the heavily DSL-oriented story code is easier to read as far as
_intent,_ but as a programmer trying to figure out what the code is actually
doing, it's sort of a big WTF.

Dave Thomas has an interesting writeup on "DSL's going too far" at:

[http://pragdave.blogs.pragprog.com/pragdave/2008/03/the-
lang...](http://pragdave.blogs.pragprog.com/pragdave/2008/03/the-language-
in.html)

~~~
lallysingh
Another example: Applescript

~~~
compay
Bingo.

------
13ren
Just to be pedantic: a GUI can have exactly the same expressive power as a
language, by implementing that language, i.e. allow nesting and iteration. I
realize that by "GUI", the author refers to those GUIs that we usually see,
that are limited to their creator's vision, but I just needed to get that off
my chest. Whew.

~~~
herdrick
Sounds interesting. How?

 _"exactly the same expressive power"_

No, surely it would be less expressive in some cases, more in others.

~~~
13ren
Well, I said " _can_ have exactly the same expressive power", just meaning
that a GUI is not more limited than a language just because it's a GUI.
Perhaps misleadingly stated :-). Specific languages and specific GUIs
naturally will vary in what they can express.

I was thinking mainly of buttons on a window that open instances of a window
corresponding to the non-terminals on the RHS of a CFG production rule. That's
the "nesting" (nesting can also represent iteration, or you can have explicit
iteration in the form of lists). Extra constraints can be imposed on this CFG
just as they are in a language.

Example of simple arithmetic expressions (a DSL): each window has a text
field, and four buttons marked with the operators +,-,* and /. You can type in
a number, or click a button which opens another window with the same format
and labeled with the chosen operator.

------
jacobscott
"When you develop a DSL, you lose the ability to leverage the checkers, IDEs,
and other tools that exist for GPLs."

When I think of "other tools", I think of testing frameworks, remoting layers,
threading, other language libraries, etc. Can anyone give me an example of a
problem domain that is not well suited by a current major programming
language, and yet simple enough that it doesn't require you to implement the
other tools you get for free by using one?

------
jwilliams
Really agree with the substance of this article - I'm always keen to jump to a
DSL when looking at a problem.

Even if thinking about it is as far as I get, it invariably helps me clarify
the solution (more than most techniques I've tried).

------
newt0311
Right on. This is where lisp shines. Since inbuilt special forms and added
libraries are indistinguishable from each other and since advanced
functionality like macros are available, it allows one to write a DSL _in
lisp._

Its very nice.

PS. This is also why GUIs will never beat the terminal. Now if only someone
would apply this to web services. ubiquity et al. are a nice start.

~~~
jrockway
This is why Lisp programmers call "DSLs" libraries. ("And you should too,
kids!")

To authors of DSLs for their special hardware or daemon or whatever -- I don't
want to learn your retarded homegrown programming language. Give me a library
for a language I already know. (Specific gripe -- lighttpd config files. It's
not quite Lisp, it's not quite Perl... It's USELESS. Instead of doing what I
want, I have to work around the author's idea of a programming language. Ick.)

