DSLs expand the solution space, GUIs limit it to the creator's vision | Hacker News Reader

DSLs expand the solution space, GUIs limit it to the creator's vision

windley.com

19 pointsherdrick12 comments

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.

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-...

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...

Another example: Applescript

Bingo.

I agree that using a DSL isn't an automatic thing.

However, I think there would be an equal number of counter-examples - cases where a problem has been shoe-horned into an existing language to the point that it become illegible.

(In fact, you could argue this happens more often than not).

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.

Sounds interesting. How?

"exactly the same expressive power"

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

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.

"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?

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).

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.

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.)

Reply on news.ycombinator.com