Summary
In both Ruby and DITA, domain specific languages make elegance possible. More importantly, each is producing an ecosystem of domain specific languages (aka "power tools") that is making it more powerful as time goes on.
Advertisement
I just blogged about something that Ruby and DITA have in common--Domain Specific Languages (DSLs), and the productivity ecosystem they create. Here is an excerpt of the stuff that is pertinent to Ruby....
The term domain-specific is unfortunately inaccurate in one important respect: It brings to mind highly specific problems, like those encountered in a shoe store, for example. In that sense, "domain-specific" tends to make you think of highly targeted IT applications--all very important, but unless you have such an application in mind, and can think of a language you might want, the concept of a DSL tends to remain an interesting abstraction with little practical value.
But there is a middle ground of DSLs that is highly general. That middle ground consists of general purpose languages that help you tackle a specific problem you face every day in the same way that others do, even though they are working in different areas. In Ruby, such languages help developers perform programming tasks. In DITA, they help writers provide information artifacts that technology users need.
The languages that live in that that middle ground might be called "general purpose domain specific languages", but that's pretty much a contradiction in terms. And it's a mouthful. So maybe we would be better served by calling them something else, like "empowerment languages" (ELs) or better, "PowerTools". Because what they do, first and foremost, is give you powerful tools you can use to help you build whatever it is you're constructing.
Ruby
In Ruby Rocks!, I wrote about the intrinsic aspects of the language that makes development a pleasure. But the ecosystem of DSLs that is growing up around Ruby is perhaps it's greatest long-term asset.
Interestingly, the categorized list of Ruby gems at RubyForge shows some 800 projects devoted to software development. Some of the most powerful are DSL power tools. On the other hand, there are DSLs that aren't Ruby gems at all. Here is a list of "world-changing" DSLs:
Rake is a fantastic build language that provides a lot of power with simple, clean syntax. For more on Rake, see Rake Rocks.
Ruby on Rails is a well-known DSL that is designed for building web applications.
RSpec is a tool for writing unit tests that are both readable and executable. Because they specify behavior in a readable way, they are more like specifications--hence the name: R(uby)Spec. Of course, as one blogger rightly pointed out, an RSpec files isn't really a specification, because it doesn't declare abstractions like "returns n**2 for all integers greater than zero". [I've lost that link! If anyone finds, please send it to me so II can point to it. --thanks, eric] What Rspec does in reality is to produce a "specification by example" that can be executed as a series of tests. But those comments do lead to an interesting extension to consider for RSpec:
The capacity to randomly generate one of two specific elements that match a pattern like "an integer greater than zero", or "an integer less than zero", so that different aspects of the abstraction can be tested in a way that tends to ensure the abstraction is implemented, rather than a case statement that satisfies the tests, and only the tests. (Of course, the test harness could only generate random input values. Generated output values would require another implementation of the algorithm, which would itself be subject to testing--a never-ending loop. But the problem can be finessed with data hiding. If some external entity like the quality control group creates a table of test values, and the developer doesn't know which values will be used, then a general implementation is required to ensure success.)
Martin Fowler's XSL in Ruby is described in what will probably turn out to be a seminal paper: Moving Away From XSLT. It combines the declarative power of XSL with the capacity for loops, conditionals, and functional coding whenever you need it.
OptiFlag is a DSL for processing command-line options.
Here are a couple of Ruby gems that sound interesting. I don't know much about them, as yet, but I'd love to find the time to explore them further:
> I don't quite see how DSL is a good replacement for > framework or library. Whats the difference?
I think one aspect is: who is the audience? If it is a bunch of programmers, perhaps a library is fine. If it is a bunch of less-than-full-time-super-nerdy people (e.g. some scientists or business people or whomever, who want to put things together w/out having to fully know how to code) then a (good) DSL can be worth a lot.
> > I don't quite see how DSL is a good replacement for > > framework or library. Whats the difference? > > I think one aspect is: who is the audience? If it is a > bunch of programmers, perhaps a library is fine. If it is > a bunch of less-than-full-time-super-nerdy people (e.g. > some scientists or business people or whomever, who want > to put things together w/out having to fully know how to > code) then a (good) DSL can be worth a lot.
Thank You! I'm accustomed to thinking of a DSL as something very geeky like regex. Hence, I find the newfangled "DSLs" and accompanying buzz rather loony. But if the purpose of a newfangled DSL is to enable a non-geek to accomplish a task, then I'm all for it.
> Thank You! I'm accustomed to thinking of a DSL as > something very geeky like regex. Hence, I find the > newfangled "DSLs" and accompanying buzz rather loony. But > if the purpose of a newfangled DSL is to enable a non-geek > to accomplish a task, then I'm all for it.
You can also think of a DSL as a way to allow non-technical people to understand what something does if not actually write it themselves.
One of the things I find weirdest about the cult of Ruby is how Ruby fans imagine that things like DSL's are somehow unique to Ruby, or new and interesting in some way. Isn't JSP a DSL for creating web pages? Isn't Java FX Script a DSL for creating Swing GUI's with lots of gratuitous animation? What about Facelets? Ant? Junit? Or how about SQL if you want a real world-changing DSL. Or ASP, or CFL....
> > Thank You! I'm accustomed to thinking of a DSL as > > something very geeky like regex. Hence, I find the > > newfangled "DSLs" and accompanying buzz rather loony. > But > > if the purpose of a newfangled DSL is to enable a > non-geek > > to accomplish a task, then I'm all for it. > > You can also think of a DSL as a way to allow > non-technical people to understand what something does if > not actually write it themselves.
I still don't see why I need "DSL" for that. The best example of non-programmers, very often designers, being able to do things otherwise only programmers do, is the JavaScript library jQuery. Noone bothered calling it a DSL, though it definitely fits the description of enabling non-programmers understanding and writing stuff written with it.
> One of the things I find weirdest about the cult of Ruby > is how Ruby fans imagine that things like DSL's are > somehow unique to Ruby, or new and interesting in some > way. Isn't JSP a DSL for creating web pages? Isn't Java > FX Script a DSL for creating Swing GUI's with lots of > gratuitous animation? What about Facelets? Ant? Junit? > Or how about SQL if you want a real world-changing DSL. > L. Or ASP, or CFL....
The difference here is how the domain-specific language is embedded into another language. For example, SQL and regular expressions are usually embedded as Strings. A framework (aka DSL) that is embedded using native language contructs gains a lot via language support, eg. it can be much easier to extend it.
In that regard, Ruby's expressiveness helps making embedded languages more natural. So does any other language that gives you more freedom on expressions, eg. allowing you to use infix syntax on method calls like Scala does.
I'm inclined to discard this entry as mere fanboyism for several reasons, the most persuasive of which is the way he abuses the term "DSL" to mean something it doesn't mean at all.
As a refresher: The "L" in "DSL" stands for "language." RoR is not a language. Call it what you like (a "library," but you could be wrong, or a "framework," and you'd probably be right), but it isn't a language.
I wouldn't even bother posting about this except for the disservice this sort of smudging of meaning does to those who are interested in the topic of DSLs, real home-made DSLs, as an elegant way to solve their problems. To you I say, keep going! You're on the edge of discovering fascinating things about both computer languages and your problem.
> > > Thank You! I'm accustomed to thinking of a DSL as > > > something very geeky like regex. Hence, I find the > > > newfangled "DSLs" and accompanying buzz rather loony. > > But > > > if the purpose of a newfangled DSL is to enable a > > non-geek > > > to accomplish a task, then I'm all for it. > > > > You can also think of a DSL as a way to allow > > non-technical people to understand what something does > if > > not actually write it themselves. > > I still don't see why I need "DSL" for that. The best > example of non-programmers, very often designers, being > able to do things otherwise only programmers do, is the > JavaScript library jQuery. Noone bothered calling it a > DSL, though it definitely fits the description of enabling > non-programmers understanding and writing stuff written > with it.
I don't know anything about jQuery but a DSL (to me) isn't just about making programs easier to read.
A Domain Specific Language is just that, specific to a domain. In my mind a domain isn't web-programming or database-querying. A domain is finance, insurance, retailing...
With DSL you can program in the terms of the users. Then the users can read the program in the same terms that they think in.
> A Domain Specific Language is just > that, specific to a domain. In my mind a domain isn't > web-programming or database-querying. A domain is > finance, insurance, retailing... > > With DSL you can program in the terms of the users. Then > the users can read the program in the same terms that they > think in.
FORmula TRANslator: the original DSL ;-)
Integer variables are INTEGER type. Floating-point variables are REAL type. Variables starting with I, J, K, L, M, or N are automatically INTEGERS because I, J, K, L, M, and N are the conventional names for subscripts, series counters, etc. in standard math and science textbooks.
Array subscripts begin with 1, perhaps because that's what matrix and tensor subscripts in math books begin with. (But, schoolbook subscripts for infinite series begin with 0. Oh, well.) Matrix notation, even in several dimensions, is straightforward, and Fortran matrices are easy to slice & dice.
I learned F77 forever ago when I was an engineering student, and have since then written/tweaked programs modeling continuum mechanics and meteorology in Fortran. It's quite a natural for scientists and engineers.
I don't know FORTRAN but I can kind of buy that. The idea behind COBOL was also similar to the concept of a DSL but in my personal opinion, it fails in that regard.
> > The idea > > behind COBOL was also similar to the concept of a DSL > but > > in my personal opinion, it fails in that regard. > > It must be twenty five years since I used it but I still > love the way you could say: > > IF X IS NOT GREATER THAN OR EQUAL TO Y THEN > > It was much closer to English than most languages but it > was still only accessable to programmers, so yes as a DSL > it was a failure.
The problem with it is that there's this idea of using English words but often the words are unintuitive or arcane. For example:
PROCEDURE DIVISION USING TARGET-QUEUE, QUEUE-MANAGER.
Just being in plain English isn't enough. The words must be meaningful and the syntax intuitive. Sometimes 'plain' English isn't even what you want, as Elizabeth pointed out. I for one would not want to try to convert complex mathematical formulas to be like the example you gave.
Flat View: This topic has 29 replies
on 2 pages
[
12
|
»
]
Previous Topic
