A little while ago, I interviewed Robert Glass and something he said struck a chord.
I do think, however, that in the ancient past, when COBOL and Fortran (which are the original domain-specific languages) were in full flower, we understood the role of languages vs. applications better. You may wonder why COBOL, for example, has survived all this time when almost everyone says it’s a very bad language. It’s because it has business-domain-specific capabilities that today’s languages still don’t offer, like decimal arithmetic and heterogeneous data/file manipulation. I think one should start with the dominant domains, then figure out what language features they need, rather than start with neat language features or compiler tweaks, and see who they should be good for.
If COBOL and Fortran are DSLs (a categorization I’m not sure I agree with, but won’t discount either), what place does Ruby play in the programming world? It’s not really systems programming languages (the counterpoint to what I think Robert is calling a DSL), but is it a DSL?
Shortly after I posted my the interview with Robert, I posted a rant about people mis-categorizing Ruby as a web programming language. It certainly hosts some nice web programming frameworks, but it’s a lot more than that. There’s Rake, Ruport, and a variety of other frameworks/tools/DSLs that make different tasks much easier to do.
Perhaps part of Ruby’s allure is that it’s a DSL (in the Robert Glass sense) for building frameworks/tools/DSLs. LISP is sometimes called the programmable programming language. Should we say this about Ruby as well?
Should we say this about Ruby as well?
Only if you don't mind extending that to every other language with metaprogramming and run-time code evaluation: Perl, Python, Smalltalk, C....
Hi Chromatic,
sure. I wasn't trying to exclude Perl, Python, etc. I was only considering Ruby since this is a Ruby blog.
Including C makes me think I'm either cutting too broadly, or along the wrong seam though.
I don't think Ruby really qualifies as a "programmable language" in the same way as Lisp, given that you can't hook into the runtime and change things like evaluation order. For example, you can't really implement a fair number of alternate control structures in DSLs, since you can only pass a single block to a method. Adding 'proc' or 'lambda' calls everywhere make for considerably more cluttered code, which is pretty much anathema to a good DSL.
As far as comparing other dynamic languages, I'd say that most either have a much more restrictive syntax (Python, Smalltalk) or tend to push you into a "string filter" model of building DSLs (C preprocessor, Perl source filters).
What Ruby really seems to have going for it is a sufficiently dynamic runtime environment and un-obtrusive syntax, making minor surface customizations of the language possible. Basically, you get pretty good "80%" solutions for building DSLs, as long as you don't mind being stuck with those few inherent limitations.
The underlying language seems simple enough for developers (experienced or not) to begin stretching out into the rest of the language once they've exhausted the capabilities of their "gateway" DSL, as well, as evidenced by the number of entirely capable Ruby developers whose first exposure to the language was via Rails.
Robert
I'd agree with Robert Glass (how's that for sticking my neck out) that Fortran certainly is a DSL. Look at the domain of scientific number-crunching on a large scale, and Fortran is stuck in there and prospering.
And considering the situation of Fortran in a domain I know well, I wonder whether the domain you identify for Ruby isn't really a meta-domain. No end user gives a fig for frameworks, tools or DSLs, they want applications for their domains -- scientific number-crunching, web-enabled business, payroll processing, logistics, etc.
Regards
Mark