Cassius Rosenthal on 23 Apr 2006 04:40:33 -0000

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PhillyOnRails] help me customize my talk on DSLs in Ruby and Rails Enterprise adoption

Dear Aaron,

If we do decide to go with queueing theory, I think we should post relevant links to the wiki immediately so we can all read up before the next meeting.

This is a good suggestion, and perhaps it implies that a queue system wouldn't be a good example. I don't suggest a detour into queue theory; it's a matter in Statistics. I was only suggesting that queues are interesting, have a proven track record with DSLs, multiple applications (kernel programming, manufacturing, online commerce, etc.), and have real world analogies that we can all readily relate to. Everyone understands a line to the cashier at a store, and it's easy to visualize. Sales commission might be a little more remote for some of us lifelong programmers.

There wasn't much of a response from the list. I take that as a sign of indifference to my suggestion. Perhaps that is also an indication that a queue system wouldn't make a good example. Not exciting enough?

In this case, it's a question of what level of domain-specific knowledge detail is appropriate for Obie's talk. I'm hoping that Obie will be able to clear this up?


In light of Jamis Buck's recent post ( ) via, i'd like to focus on using ruby's great language features as they pertain to creation of a DSL. Buck leaves this as an excersize to the reader. I'd like to see some basic code as examples of "proper use" of the following in DSLs:

procs, modules, eval, instance_eval and class_eval, define_method, Module#included, and method_missing


Aaron Blohowiak

On Apr 21, 2006, at 10:56 AM, Cassius Rosenthal wrote:

Hello Obie,

My impression of DSLs has been that, as I develop a specific type of application for years -- say an online CMS -- a form of DSL evolves on its own. My (or my team's) object abstractions become convention and eventually take on a life of their own, with an associated mini-API.

At that point, creating a new application reusing the same code, or the same mini-API at least, is a productive leap. Making that happen in reverse strikes me as terribly difficult, because it requires so much domain-specific knowledge that a programmer might not have prior to getting his/her hands dirty within the domain. It's a chicken~egg problem for me. So in your talk, I'll be looking for advice on design as much as on implementation.

The sales commission example sounds complex enough to be interesting. In the interest of getting the online discussion going, maybe we could also look at some sort of system queue. This could apply to anything from kernel task execution to a retail cashier check-out simulation. We could look at a general case, like G/G/3/infinite/fifo/infinite in Kendall notation <>.

Let's take the retail check-out example. Roughly, this would be a system where customers arrived in a general distributed arrival times, say 10 customers per hour; the service time is generally distributed, say 4 minutes per customer; there are three cashiers; there is infinite space for a waiting line; customers are served on a first-in/first-out basis; and the number of potential customers is infinite.

For those who don't work with simulations, there are many, many simulation DSLs. The more well-known ones:

I'll be interested to see how the list responds.

talk mailing list

_______________________________________________ talk mailing list

_______________________________________________ talk mailing list